Zigbee stack assertion failed common/zb_bufpool_mult.c:1183 (TZ-729)

Answers checklist.

[X] I have read the documentation ESP Zigbee SDK Programming Guide and tried the debugging tips, the issue is not addressed there.
[X] I have updated ESP Zigbee libs (esp-zboss-lib and esp-zigbee-lib) to the latest version, with corresponding IDF version, and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
v5.3-dev-2320-ge4f167df25
esp-zigbee-lib version.
1.2.1
esp-zboss-lib version.
1.2.1
Espressif SoC revision.
ESP32-C6
What is the expected behavior?
Does not crash
What is the actual behavior?
Zigbee stack assertion failed common/zb_bufpool_mult.c:1183
Steps to reproduce.
Unknown
More Information.
Source: https://github.com/nomis/candle-dribbler/tree/0.7.2
Binary: candle-dribbler.elf.gz
Core dump: core-dump-2024-04-02.txt
Log: log-2024-04-02.txt (all except the last two switch changes have been omitted)
Zigbee stack assertion failed common/zb_bufpool_mult.c:1183

abort() was called at PC 0x4202dde3 on core 0
Core  0 register dump:
MEPC    : 0x40800774  RA      : 0x40808c2c  SP      : 0x4082d690  GP      : 0x40811690
TP      : 0x4082d890  T0      : 0x37363534  T1      : 0x7271706f  T2      : 0x33323130
S0/FP   : 0x4082d6bc  S1      : 0x4082d6bc  A0      : 0x4082d6c8  A1      : 0x4082d6aa
A2      : 0x00000000  A3      : 0x4082d6f5  A4      : 0x00000001  A5      : 0x4081f000
A6      : 0x00000000  A7      : 0x76757473  S2      : 0x00000098  S3      : 0x0000000d
S4      : 0x00000008  S5      : 0x0000000d  S6      : 0x00000000  S7      : 0x00000000
S8      : 0x00000000  S9      : 0x00000000  S10     : 0x00000000  S11     : 0x00000000
T3      : 0x6e6d6c6b  T4      : 0x6a696867  T5      : 0x66656463  T6      : 0x62613938
MSTATUS : 0x00001881  MTVEC   : 0x40800001  MCAUSE  : 0x00000007  MTVAL   : 0x00000000
MHARTID : 0x00000000

Stack memory:
4082d690: 0x00000000 0x00000000 0x4082d6a8 0x4080fcba 0x00000000 0x0000000d 0x00000030 0x40811dec
4082d6b0: 0x4082d6bc 0x40811e08 0x4082d6a8 0x32303234 0x33656464 0x00000000 0x726f6261 0x20292874
4082d6d0: 0x20736177 0x6c6c6163 0x61206465 0x43502074 0x34783020 0x64323032 0x20336564 0x63206e6f
4082d6f0: 0x2065726f 0x00000030 0x00000000 0x64f7aefa 0x0000002f 0x0000049f 0x4209ab06 0x4202dde6
4082d710: 0x1d25d205 0x00000008 0x40815304 0x4202cf24 0x4082d780 0x00000000 0x408153a3 0x4081b898
4082d730: 0x40815310 0x408153a4 0x4081d418 0x4202d0d4 0x00000000 0x00000095 0x4081d418 0x420604ce
4082d750: 0x00000000 0x0000004c 0x0000098f 0x00000000 0x00000000 0x4082d780 0x4082628c 0x4206142e
4082d770: 0x00000000 0x00000733 0x00000001 0x42060cda 0x00000010 0x00000000 0x00000000 0x00000000
4082d790: 0x00000000 0x00000000 0x00000004 0x420608f0 0x00000001 0x00000000 0x000cdcf8 0x42031eaa
4082d7b0: 0x00000000 0x00000000 0x022c02c2 0x42032b16 0x00000000 0x00000000 0x022c02c2 0x42032f4c
4082d7d0: 0x00000000 0xffffffff 0x40825f04 0x40809bc4 0x00000000 0x00000000 0x00000000 0x00000000
4082d7f0: 0x00000000 0x00000000 0x4082b850 0x42050042 0x00000040 0x00000000 0x4082632c 0x420217f6
4082d810: 0x00000000 0x00000000 0x00000000 0x42010456 0x00000000 0x00000000 0x00000000 0x42076d4a
4082d830: 0x00000000 0x00000000 0x00000000 0x4082b380 0x00000000 0x00000000 0x4082b850 0x42004e22
4082d850: 0x00000000 0x00000000 0x00000000 0x40809e1c 0x00000000 0x00000000 0x00000000 0x00000000
4082d870: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
4082d890: 0xa5a5a5a5 0x0000015c 0x4082d640 0x0356090d 0x40812e90 0x40812e90 0x4082d898 0x40812e88
4082d8b0: 0x00000014 0x40827504 0x40827504 0x4082d898 0x00000000 0x00000005 0x4082b894 0x6267697a
4082d8d0: 0x6d5f6565 0x006e6961 0x00000000 0x4082d890 0x00000005 0x00000000 0x00000005 0x00000001
4082d8f0: 0x00000000 0x00000000 0x25837c76 0x00000009 0x40820168 0x408201d0 0x40820238 0x00000000
4082d910: 0x00000000 0x00000001 0x00000000 0x00000000 0x00000000 0x42004166 0x00000000 0x00000000
4082d930: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
4082d950: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
4082d970: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
4082d990: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
4082d9b0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
4082d9d0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
4082d9f0: 0x00000000 0x00000028 0x00000000 0x4081f684 0x0000000e 0x0000002b 0x00000000 0x4082da48
4082da10: 0x4082da68 0x4082da68 0x00000000 0x00000000 0x00000020 0x00000000 0x4082fe28 0x00000000
4082da30: 0x00000000 0x2a0bebd0 0x0001fec7 0x4082644c 0x4082643c 0x00000020 0x00000000 0x00000abe
4082da50: 0x0029f630 0x00000000 0x0000ff00 0x000000fa 0x0003d090 0x00000000 0x0000005c 0x00000000
4082da70: 0x4082da6c 0x00000000 0x00000000 0x00000000 0x4082da84 0xffffffff 0x4082da84 0x4082da84

===============================================================
==================== ESP32 CORE DUMP START ====================

Crashed task handle: 0x4082d898, name: 'zigbee_main', GDB name: 'process<PHONE_NUMBER>'
Crashed task is not in the interrupt context
Panic reason: abort() was called at PC 0x4202dde3 on core 0

================== CURRENT THREAD REGISTERS ===================
ra             0x40808c2c	0x40808c2c <__ubsan_include>
sp             0x4082d690	0x4082d690
gp             0x40811690	0x40811690 <_impure_data+136>
tp             0x4082d890	0x4082d890
t0             0x37363534	926299444
t1             0x7271706f<PHONE_NUMBER>
t2             0x33323130	858927408
fp             0x4082d6bc	0x4082d6bc
s1             0x4082d6bc<PHONE_NUMBER>
a0             0x4082d6c8<PHONE_NUMBER>
a1             0x4082d6aa<PHONE_NUMBER>
a2             0x0	0
a3             0x4082d6f5<PHONE_NUMBER>
a4             0x1	1
a5             0x4081f000<PHONE_NUMBER>
a6             0x0	0
a7             0x76757473<PHONE_NUMBER>
s2             0x98	152
s3             0xd	13
s4             0x8	8
s5             0xd	13
s6             0x0	0
s7             0x0	0
s8             0x0	0
s9             0x0	0
s10            0x0	0
s11            0x0	0
t3             0x6e6d6c6b<PHONE_NUMBER>
t4             0x6a696867<PHONE_NUMBER>
t5             0x66656463<PHONE_NUMBER>
t6             0x62613938<PHONE_NUMBER>
pc             0x40800774	0x40800774 <panic_abort+18>

==================== CURRENT THREAD STACK =====================
#0  panic_abort (details=details@entry=0x4082d6c8 "abort() was called at PC 0x4202dde3 on core 0") at /home/simon/src/esp-idf/components/esp_system/panic.c:469
#1  0x40808c2c in esp_system_abort (details=details@entry=0x4082d6c8 "abort() was called at PC 0x4202dde3 on core 0") at /home/simon/src/esp-idf/components/esp_system/port/esp_system_chip.c:92
#2  0x4080fcba in abort () at /home/simon/src/esp-idf/components/newlib/abort.c:38
#3  0x4202dde6 in ?? ()

======================== THREADS INFO =========================
  Id   Target Id          Frame
* 1    process<PHONE_NUMBER> panic_abort (details=details@entry=0x4082d6c8 "abort() was called at PC 0x4202dde3 on core 0") at /home/simon/src/esp-idf/components/esp_system/panic.c:469
  2    process<PHONE_NUMBER> 0x40806032 in esp_cpu_wait_for_intr () at /home/simon/src/esp-idf/components/esp_hw_support/cpu.c:150
  3    process<PHONE_NUMBER> 0x40809fdc in vPortYield () at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:622
  4    process<PHONE_NUMBER> 0x40809fdc in vPortYield () at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:622
  5    process<PHONE_NUMBER> vPortClearInterruptMaskFromISR (prev_int_level=1) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:496
  6    process<PHONE_NUMBER> 0x40809fdc in vPortYield () at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:622
  7    process<PHONE_NUMBER> 0x40809fe0 in vPortYield () at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:622
  8    process<PHONE_NUMBER> vPortClearInterruptMaskFromISR (prev_int_level=1) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:496

       TCB             NAME PRIO C/B  STACK USED/FREE
---------- ---------------- -------- ----------------
0x4082d898      zigbee_main      5/5         592/7596
0x408239ac             IDLE      0/0         208/1320
0x4082fc08      zigbee_task      5/5         528/7660
0x40824310          Tmr Svc      1/1         272/1764
0x40833a34          ui_uart      1/1         464/5664
0x40832078          ui_main      2/2         336/3756
0x40830ea8      device_main    19/19         336/3756
0x4082056c        esp_timer    22/22         240/3840

==================== THREAD 1 (TCB: 0x4082d898, name: 'zigbee_main') =====================
#0  panic_abort (details=details@entry=0x4082d6c8 "abort() was called at PC 0x4202dde3 on core 0") at /home/simon/src/esp-idf/components/esp_system/panic.c:469
#1  0x40808c2c in esp_system_abort (details=details@entry=0x4082d6c8 "abort() was called at PC 0x4202dde3 on core 0") at /home/simon/src/esp-idf/components/esp_system/port/esp_system_chip.c:92
#2  0x4080fcba in abort () at /home/simon/src/esp-idf/components/newlib/abort.c:38
#3  0x4202dde6 in ?? ()

==================== THREAD 2 (TCB: 0x408239ac, name: 'IDLE') =====================
#0  0x40806032 in esp_cpu_wait_for_intr () at /home/simon/src/esp-idf/components/esp_hw_support/cpu.c:150
#1  0x42069286 in esp_vApplicationIdleHook () at /home/simon/src/esp-idf/components/esp_system/freertos_hooks.c:58
#2  0x4080adb0 in prvIdleTask (pvParameters=<error reading variable: value has been optimized out>) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:4310
#3  0x40809e1c in vPortTaskWrapper (pxCode=<optimized out>, pvParameters=<optimized out>) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:229

==================== THREAD 3 (TCB: 0x4082fc08, name: 'zigbee_task') =====================
#0  0x40809fdc in vPortYield () at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:622
#1  vPortYield () at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:604
#2  0x40809af4 in xQueueSemaphoreTake (xQueue=0x4082fad0, xTicksToWait=<optimized out>, xTicksToWait@entry=6001) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1901
#3  0x42005140 in pthread_cond_timedwait (mut=0x40825bb8, to=<optimized out>, cv=<optimized out>) at /home/simon/src/esp-idf/components/pthread/pthread_cond_var.c:163
#4  0x42010f28 in __gthread_cond_timedwait (__abs_timeout=0x4082fb60, __mutex=<optimized out>, __cond=0x40825bbc) at /home/simon/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20230928/riscv32-esp-elf/riscv32-esp-elf/include/c++/13.2.0/riscv32-esp-elf/rv32imac_zicsr_zifencei/ilp32/no-rtti/bits/gthr-default.h:872
#5  std::__condvar::wait_until (__abs_time=..., __m=..., this=0x40825bbc) at /home/simon/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20230928/riscv32-esp-elf/riscv32-esp-elf/include/c++/13.2.0/bits/std_mutex.h:178
#6  std::condition_variable::__wait_until_impl<std::chrono::duration<long long, std::ratio<1ll,<PHONE_NUMBER>ll> > > (__lock=..., __atime=<synthetic pointer>..., this=0x40825bbc) at /home/simon/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20230928/riscv32-esp-elf/riscv32-esp-elf/include/c++/13.2.0/condition_variable:224
#7  std::condition_variable::wait_until<std::chrono::_V2::steady_clock, std::chrono::duration<long long, std::ratio<1ll,<PHONE_NUMBER>ll> > > (__atime=..., __lock=..., this=0x40825bbc) at /home/simon/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20230928/riscv32-esp-elf/riscv32-esp-elf/include/c++/13.2.0/condition_variable:137
#8  nutt::ZigbeeDevice::run_tasks (this=0x40825bb8) at /home/simon/build/candle-dribbler-0.7.2/src/zigbee.cpp:157
#9  0x42076d4a in std::execute_native_thread_routine (__p=<optimized out>) at /builds/idf/crosstool-NG/.build/riscv32-esp-elf/src/gcc/libstdc++-v3/src/c++11/thread.cc:104
#10 0x42004e22 in pthread_task_func (arg=0x4082dbc0, arg@entry=<error reading variable: value has been optimized out>) at /home/simon/src/esp-idf/components/pthread/pthread.c:222
#11 0x40809e1c in vPortTaskWrapper (pxCode=<optimized out>, pvParameters=<optimized out>) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:229

==================== THREAD 4 (TCB: 0x40824310, name: 'Tmr Svc') =====================
#0  0x40809fdc in vPortYield () at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:622
#1  vPortYield () at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:604
#2  0x4080a95a in prvProcessTimerOrBlockTask (xListWasEmpty=<optimized out>, xNextExpireTime=<optimized out>) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/timers.c:739
#3  prvTimerTask (pvParameters=<error reading variable: value has been optimized out>) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/timers.c:685
#4  0x40809e1c in vPortTaskWrapper (pxCode=<optimized out>, pvParameters=<optimized out>) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:229

==================== THREAD 5 (TCB: 0x40833a34, name: 'ui_uart') =====================
#0  vPortClearInterruptMaskFromISR (prev_int_level=1) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:496
#1  vPortExitCritical () at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:597
#2  0x408081de in prvReceiveGeneric (pxRingbuffer=0x40825688, pvItem1=pvItem1@entry=0x4083392c, pvItem2=pvItem2@entry=0x0, xItemSize1=xItemSize1@entry=0x4083394c, xItemSize2=xItemSize2@entry=0x0, xMaxSize=xMaxSize@entry=1, xTicksToWait=<optimized out>, xTicksToWait@entry=4294967295) at /home/simon/src/esp-idf/components/esp_ringbuf/ringbuf.c:876
#3  0x40808622 in xRingbufferReceiveUpTo (xRingbuffer=<optimized out>, pxItemSize=pxItemSize@entry=0x4083394c, xTicksToWait=xTicksToWait@entry=4294967295, xMaxSize=xMaxSize@entry=1) at /home/simon/src/esp-idf/components/esp_ringbuf/ringbuf.c:1178
#4  0x42008fdc in uart_read_bytes (uart_num=UART_NUM_0, buf=0x4083398c, length=1, ticks_to_wait=4294967295) at /home/simon/src/esp-idf/components/esp_driver_uart/src/uart.c:1404
#5  0x4200eb3e in __GNU_EH_FRAME_HDR ()
#6  0x42076d4a in std::execute_native_thread_routine (__p=<optimized out>) at /builds/idf/crosstool-NG/.build/riscv32-esp-elf/src/gcc/libstdc++-v3/src/c++11/thread.cc:104
#7  0x42004e22 in pthread_task_func (arg=0x408321ec, arg@entry=<error reading variable: value has been optimized out>) at /home/simon/src/esp-idf/components/pthread/pthread.c:222
#8  0x40809e1c in vPortTaskWrapper (pxCode=<optimized out>, pvParameters=<optimized out>) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:229

==================== THREAD 6 (TCB: 0x40832078, name: 'ui_main') =====================
#0  0x40809fdc in vPortYield () at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:622
#1  vPortYield () at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:604
#2  0x40809af4 in xQueueSemaphoreTake (xQueue=0x40824e20, xTicksToWait=<optimized out>) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1901
#3  0x4201a088 in nutt::WakeupThread::run_loop (this=0x40824d9c) at /home/simon/build/candle-dribbler-0.7.2/src/thread.cpp:64
#4  0x42076d4a in std::execute_native_thread_routine (__p=<optimized out>) at /builds/idf/crosstool-NG/.build/riscv32-esp-elf/src/gcc/libstdc++-v3/src/c++11/thread.cc:104
#5  0x42004e22 in pthread_task_func (arg=0x40831030, arg@entry=<error reading variable: value has been optimized out>) at /home/simon/src/esp-idf/components/pthread/pthread.c:222
#6  0x40809e1c in vPortTaskWrapper (pxCode=<optimized out>, pvParameters=<optimized out>) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:229

==================== THREAD 7 (TCB: 0x40830ea8, name: 'device_main') =====================
#0  0x40809fe0 in vPortYield () at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:622
#1  vPortYield () at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:604
#2  0x40809af4 in xQueueSemaphoreTake (xQueue=0x40825b34, xTicksToWait=<optimized out>) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/queue.c:1901
#3  0x4201a088 in nutt::WakeupThread::run_loop (this=0x408259b0) at /home/simon/build/candle-dribbler-0.7.2/src/thread.cpp:64
#4  0x42076d4a in std::execute_native_thread_routine (__p=<optimized out>) at /builds/idf/crosstool-NG/.build/riscv32-esp-elf/src/gcc/libstdc++-v3/src/c++11/thread.cc:104
#5  0x42004e22 in pthread_task_func (arg=0x4082fe60, arg@entry=<error reading variable: value has been optimized out>) at /home/simon/src/esp-idf/components/pthread/pthread.c:222
#6  0x40809e1c in vPortTaskWrapper (pxCode=<optimized out>, pvParameters=<optimized out>) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:229

==================== THREAD 8 (TCB: 0x4082056c, name: 'esp_timer') =====================
#0  vPortClearInterruptMaskFromISR (prev_int_level=1) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:496
#1  vPortExitCritical () at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:597
#2  0x4080c49e in ulTaskGenericNotifyTake (uxIndexToWait=uxIndexToWait@entry=0, xClearCountOnExit=xClearCountOnExit@entry=1, xTicksToWait=xTicksToWait@entry=4294967295) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/tasks.c:5722
#3  0x4206bf62 in timer_task (arg=<error reading variable: value has been optimized out>) at /home/simon/src/esp-idf/components/esp_timer/src/esp_timer.c:477
#4  0x40809e1c in vPortTaskWrapper (pxCode=<optimized out>, pvParameters=<optimized out>) at /home/simon/src/esp-idf/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:229

======================= ALL MEMORY REGIONS ========================
Name   Address   Size   Attrs
.rtc.text 0x50000000 0x0 RW
.rtc.force_fast 0x50000000 0x0 RW
.rtc.force_slow 0x50000010 0x0 RW
.iram0.text 0x40800000 0x10e88 R XA
.iram0.text_end 0x40810e88 0x0 RW
.iram0.bss 0x40810e90 0x0 RW
.dram0.data 0x40810e90 0x1d84 RW A
.flash.text 0x42000020 0x80908 R XA
.flash.appdesc 0x42090020 0x100 R  A
.flash.rodata 0x42090120 0x1afe0 RW A
.flash.tls 0x420ab100 0x0 RW
.eh_frame 0x420ab100 0x10d8 R  A
.flash.rodata_noload 0x420ac1d8 0x0 RW
.coredump.tasks.data 0x4082d898 0x15c RW
.coredump.tasks.data 0x4082d5f0 0x2a0 RW
.coredump.tasks.data 0x408239ac 0x15c RW
.coredump.tasks.data 0x408238d0 0xd0 RW
.coredump.tasks.data 0x4082fc08 0x15c RW
.coredump.tasks.data 0x4082f9f0 0x210 RW
.coredump.tasks.data 0x40824310 0x15c RW
.coredump.tasks.data 0x408241f0 0x110 RW
.coredump.tasks.data 0x40833a34 0x15c RW
.coredump.tasks.data 0x40833850 0x1d0 RW
.coredump.tasks.data 0x40832078 0x15c RW
.coredump.tasks.data 0x40831f20 0x150 RW
.coredump.tasks.data 0x40830ea8 0x15c RW
.coredump.tasks.data 0x40830d50 0x150 RW
.coredump.tasks.data 0x4082056c 0x15c RW
.coredump.tasks.data 0x40821e10 0xf0 RW

===================== ESP32 CORE DUMP END =====================
===============================================================

4202cf24: zb_bufpool_mult.c.obj:? <zb_get_buf_tail_ptr>
4202dde6: zb_init_common.c.obj:? <zb_assert>
42031eaa: zb_scheduler.c.obj:? <sched_is_cb_q_empty>
42032b16: zb_scheduler.c.obj:? <zb_sched_mac_transport_iteration>

The last communication was about 3 minutes before the crash:
2024-04-02 17:28:53.050 DEBUG (MainThread) [zigpy.zcl] [0x78C0:11:0x0006] Attribute report received: on_off=<Bool.false: 0>

2024-04-02 17:28:53.157 DEBUG (MainThread) [zigpy.zcl] [0x78C0:61:0x000f] Attribute report received: present_value=<Bool.false: 0>

2024-04-02 17:28:56.381 DEBUG (MainThread) [zigpy.zcl] [0x78C0:1:0x000c] Attribute report received: present_value=6.453306198120117

2024-04-02 17:29:57.461 DEBUG (MainThread) [zigpy.zcl] [0x78C0:1:0x000c] Attribute report received: status_flags=<bitmap8.0: 0>

2024-04-02 17:31:42.396 DEBUG (MainThread) [zigpy.zcl] [0x78C0:34:0x0006] Sending request: Read_Attributes(attribute_ids=[0])
2024-04-02 17:31:42.484 DEBUG (MainThread) [zigpy.zcl] [0x78C0:34:0x0006] Decoded ZCL frame: OnOff:Read_Attributes_rsp(status_records=[ReadAttributeRecord(attrid=0x0000, status=<Status.SUCCESS: 0>, value=TypeValue(type=Bool, value=<Bool.false: 0>))])

@nomis ,
Is it possible to enable the trace log mode for debugging this issue? The trace mode will generate more log for you.

You're going to need to elaborate on which trace mode and logging build options should be used.
When I tried this previously all I got was so much output to the UART that no lower priority task could run, which I could work around but it implies that there's going to be more output than the maximum speed of my UART receiver at 115200bps.

Could you not instrument the library to provide more detail on the current state when the error occurs?

@nomis, I have the same panic during call to esp_zb_scheduler_alarm, as a workaround I rolled back to prev version of library (in idf_component.yml):
espressif/esp-zboss-lib: "<=1.2.1"

@nomis ,

Source: https://github.com/nomis/candle-dribbler/tree/0.7.2
Binary: core-dump-2024-04-02.txt
Core dump: core-dump-2024-04-02.txt
Log: log-2024-04-02.txt (all except the last two switch changes have been omitted)

Please also provide the .elf file.

@nomis ,

Source: https://github.com/nomis/candle-dribbler/tree/0.7.2
Binary: core-dump-2024-04-02.txt
Core dump: core-dump-2024-04-02.txt
Log: log-2024-04-02.txt (all except the last two switch changes have been omitted)

Please also provide the .elf file.

I've fixed the attachment in the description: candle-dribbler.elf.gz

@nomis ,
We've debugged some detailed issues based on the information you provided and made some fixes, but I cannot guarantee they are the root cause of this issue. The fixes will be released in the next version. Before that, could you replace this function  the code below with the belowed code and test again?
static void ieee802154_receive_done(uint8_t *data, esp_ieee802154_frame_info_t *frame_info)
{
    // If the RX done packet is written in the stub buffer, drop it silently.
    if (s_rx_index == CONFIG_IEEE802154_RX_BUFFER_SIZE) {
        esp_rom_printf("receive buffer full, drop the current frame.\n");
    } else {
        // Otherwise, post it to the upper layer.
        frame_info->process = true;
        if (data[0] > 127) {
            esp_rom_printf("ovesized frame: %d\n", data[0]);
        }
        esp_ieee802154_receive_done(data, frame_info);
    }
}

@nomis ,
Could you please test the issue again using the latest version of the esp-zigbee-sdk? We have made some updates that may be helpful in resolving it.

Ok, but you really need to stop making changes where it loses configuration on upgrade:
2024-04-12 12:17:24.561647 ZBOSS: common/zb_nvram.c:3189   ds_ver == 2
2024-04-12 12:17:24.561700 ZBOSS: common/zb_nvram.c:3072   ERROR: unexpected binding dataset length; size from nvram 576, expected size 576
2024-04-12 12:17:24.577870 ZBOSS: common/zb_nvram.c:3237   ERROR: could not read the APS binding table from NVRAM, page 1 pos 1328, ds_ver 2

Do you still want me to call esp_zb_set_trace_level_mask(ESP_ZB_TRACE_LEVEL_CRITICAL, 0); or should that be omitted? It looks like there's a bit more debug output without it.

But then it's apparently invalid so I can't read it back:
2024-04-12 12:39:39.489545 I (65) esp_core_dump_flash: Init core dump to flash
2024-04-12 12:39:39.489597 I (66) esp_core_dump_flash: Found partition 'coredump' @ 40000 262144 bytes
2024-04-12 12:39:39.489614 D (77) esp_core_dump_crc: Total length of hashed data: 11904
2024-04-12 12:39:39.489627 E (77) esp_core_dump_flash: Core dump data check failed:
2024-04-12 12:39:39.493498 Calculated checksum='2c9a2b2f'
2024-04-12 12:39:39.493542 Image checksum='00f3106d'

It then crashes with an invalid read, repeatedly:
2024-04-12 13:02:47.829205 Guru Meditation Error: Core  0 panic'ed (Load access fault).  Exception was unhandled.
2024-04-12 13:32:50.357563 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 13:47:51.626877 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 14:02:52.894122 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 14:17:54.167366 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 14:32:55.443358 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 14:47:56.634586 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 15:02:57.910721 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 15:17:59.194935 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 15:33:00.484131 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 15:48:01.769565 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 16:03:03.084696 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 16:18:04.382838 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 16:33:05.680234 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 16:48:06.984327 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 17:03:08.292488 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 17:18:09.612808 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 17:33:10.926938 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 17:48:12.242206 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 18:03:16.579405 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.
2024-04-12 18:18:20.806673 Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.

The first error happened again trying to rejoin the network after erasing the flash:
2024-04-12 18:53:53.957550 D (541) nutt.ZigbeeDevice: Zigbee stack initialized
2024-04-12 18:53:53.957605 I (541) nutt.ZigbeeDevice: Device address: 40:4c:ca:ff:fe:43:0b:d0/0xffff (network not configured)
2024-04-12 18:53:53.957621 I (541) nutt.ZigbeeDevice: Waiting for pairing button press (ZDO Skip Start Up)
2024-04-12 18:53:53.979518 ZBOSS: zcl/zcl_main.c:357   zb_zcl_get_cluster_check_value: cluster_id 12 cluster_role 1
2024-04-12 18:53:53.979570 ZBOSS: zcl/zcl_main.c:382   zb_zcl_get_cluster_write_attr_hook: cluster_id 12 cluster_role 1
2024-04-12 18:53:53.979586 ZBOSS: zcl/zcl_main.c:357   zb_zcl_get_cluster_check_value: cluster_id 12 cluster_role 1
2024-04-12 18:53:54.001622 ZBOSS: zcl/zcl_main.c:382   zb_zcl_get_cluster_write_attr_hook: cluster_id 12 cluster_role 1
2024-04-12 18:53:54.001676 ZBOSS: zcl/zcl_main.c:357   zb_zcl_get_cluster_check_value: cluster_id 12 cluster_role 1
2024-04-12 18:53:54.005711 ZBOSS: zcl/zcl_main.c:382   zb_zcl_get_cluster_write_attr_hook: cluster_id 12 cluster_role 1
2024-04-12 18:53:54.005759 D (591) nutt: Free stack: 1208
2024-04-12 18:53:56.763092 D (3361) nutt.ZigbeeDevice: Connecting (join network)
2024-04-12 18:54:00.004792 I (6601) nutt.ZigbeeDevice: Joined network successfully (6f:06:fc:4a:5b:92:dd:9c/0x8813@26 as 0x78c0)
2024-04-12 18:54:00.702054 ZBOSS: nwk/nwk_nlme.c:794   OOM state is detected.  We added a double filter in the software in the 1.2.3 release.
If the issue still happens, we assume it's caused by some overflow issue, the buffer was overwritten due to some unexpected operation. Could you please share us the steps to reproduce the issue, we will debug it locally.

Could you please share us the steps to reproduce the issue, we will debug it locally.

I don't have a way to reproduce it. I just run it on my Zigbee network with ZHA and wait for it to crash.

The last communication was about 3 minutes before the crash

That's not strictly true... I was looking at a log filtered for communication with the device (0x78C0, via router 0x97F6). I hadn't looked at the log for communication with other devices. There was a request/response with another device (0xEB07, direct) at the time but it's not an abnormal message:
2024-04-02 17:34:30.858 DEBUG (MainThread) [zigpy.zcl] [0xEB07:1:0x0000] Sending request header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=False, direction=<Direction.Server_to_Client: 0>, disable_default_response=0, reserved=0, *is_cluster=False, *is_general=True, *is_reply=False), tsn=119, command_id=<GeneralCommand.Read_Attributes: 0>, *direction=<Direction.Server_to_Client: 0>, *is_reply=False)
2024-04-02 17:34:30.858 DEBUG (MainThread) [zigpy.zcl] [0xEB07:1:0x0000] Sending request: Read_Attributes(attribute_ids=[4])
2024-04-02 17:34:30.859 DEBUG (MainThread) [bellows.zigbee.application] Sending packet ZigbeePacket(src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0xEB07), dst_ep=1, source_route=[], extended_timeout=False, tsn=119, profile_id=260, cluster_id=0, data=Serialized[b'\x00w\x00\x04\x00'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=None, rssi=None)
2024-04-02 17:34:30.883 DEBUG (MainThread) [bellows.zigbee.application] Received messageSentHandler frame with [<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 60167, EmberApsFrame(profileId=260, clusterId=0, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_NONE: 0>, groupId=0, sequence=7), 120, <EmberStatus.SUCCESS: 0>, b'']

2024-04-02 17:34:30.887654 Zigbee stack assertion failed common/zb_bufpool_mult.c:1183

2024-04-02 17:34:30.890 DEBUG (MainThread) [bellows.zigbee.application] Received incomingRouteRecordHandler frame with [0xeb07, 00:12:4b:00:24:c5:95:a7, 104, -74, []]
2024-04-02 17:34:30.890 DEBUG (MainThread) [bellows.zigbee.application] Processing route record request: (0xeb07, 00:12:4b:00:24:c5:95:a7, 104, -74, [])
2024-04-02 17:34:30.901 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=0, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_NONE: 0>, groupId=0, sequence=127), 104, -74, 0xeb07, 255, 255, b'\x18w\x01\x04\x00\x00B\x06SONOFF']
2024-04-02 17:34:30.901 DEBUG (MainThread) [zigpy.application] Received a packet: ZigbeePacket(src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0xEB07), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=1, source_route=None, extended_timeout=False, tsn=127, profile_id=260, cluster_id=0, data=Serialized[b'\x18w\x01\x04\x00\x00B\x06SONOFF'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=104, rssi=-74)
2024-04-02 17:34:30.901 DEBUG (MainThread) [zigpy.zcl] [0xEB07:1:0x0000] Received ZCL frame: b'\x18w\x01\x04\x00\x00B\x06SONOFF'
2024-04-02 17:34:30.902 DEBUG (MainThread) [zigpy.zcl] [0xEB07:1:0x0000] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Client_to_Server: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True, *is_reply=True), tsn=119, command_id=1, *direction=<Direction.Client_to_Server: 1>, *is_reply=True)
2024-04-02 17:34:30.902 DEBUG (MainThread) [zigpy.zcl] [0xEB07:1:0x0000] Decoded ZCL frame: Basic:Read_Attributes_rsp(status_records=[ReadAttributeRecord(attrid=0x0004, status=<Status.SUCCESS: 0>, value=TypeValue(type=CharacterString, value='SONOFF'))])

@nomis ,

Ok, but you really need to stop making changes where it loses configuration on upgrade:

Regarding the issue, we have marked it in the release notes.

Source: https://github.com/nomis/candle-dribbler/tree/0.7.3 Binary: candle-dribbler.elf.gz
This has been crashing all day:

The crashing may be triggered by too many stack logs. Could you use the esp-zigbee-sdk v1.2.3, which includes optimizations for this issue, to test the problem in release mode?

Ok, but you really need to stop making changes where it loses configuration on upgrade:
Regarding the issue, we have marked it in the release notes.

No, you have not done this. You've noted that some sizes are configurable, but not that there are critical bugs in the library when the sizes change that require the zb_storage partition to be erased to fix.

The crashing may be triggered by too many stack logs. Could you use the esp-zigbee-sdk v1.2.3, which includes optimizations for this issue, to test the problem in release mode?

The crashing is caused by the aforementioned bug where the zboss library calls zb_zcl_get_attr_desc_manuf_a() with rep_info->manuf_code of 0 instead of ZB_ZCL_MANUFACTURER_WILDCARD_ID because the configuration is not initialised correctly.

We've debugged some detailed issues based on the information you provided and made some fixes, but I cannot guarantee they are the root cause of this issue. The fixes will be released in the next version. Before that, could you replace this function the code below with the belowed code and test again?

This has happened once with 1.2.3 and it didn't result in a crash:
2024-04-20 01:42:50.956834 ZBOSS: zcl/zcl_main.c:357   zb_zcl_get_cluster_check_value: cluster_id 12 cluster_role 1
2024-04-20 01:42:50.957000 ZBOSS: zcl/zcl_main.c:382   zb_zcl_get_cluster_write_attr_hook: cluster_id 12 cluster_role 1
2024-04-20 01:42:51.885534 ZBOSS: zcl/zcl_main.c:357   zb_zcl_get_cluster_check_value: cluster_id 12 cluster_role 1
2024-04-20 01:42:51.885690 ZBOSS: zcl/zcl_main.c:382   zb_zcl_get_cluster_write_attr_hook: cluster_id 12 cluster_role 1
2024-04-20 01:42:52.096456 W (10806022) nutt.ZigbeeDevice: NLME status indication: 09 0x97f6 00
2024-04-20 01:45:00.529011 ovesized frame: 158
2024-04-20 01:47:51.018197 ZBOSS: zcl/zcl_main.c:357   zb_zcl_get_cluster_check_value: cluster_id 12 cluster_role 1
2024-04-20 01:47:51.018351 ZBOSS: zcl/zcl_main.c:382   zb_zcl_get_cluster_write_attr_hook: cluster_id 12 cluster_role 1
2024-04-20 01:51:51.061893 ZBOSS: zcl/zcl_main.c:357   zb_zcl_get_cluster_check_value: cluster_id 12 cluster_role 1
2024-04-20 01:51:51.062046 ZBOSS: zcl/zcl_main.c:382   zb_zcl_get_cluster_write_attr_hook: cluster_id 12 cluster_role 1
2024-04-20 01:55:51.101273 ZBOSS: zcl/zcl_main.c:357   zb_zcl_get_cluster_check_value: cluster_id 12 cluster_role 1

Of course, that doesn't prove that this was the cause if you've changed 1.2.3 to silently filter those messages out...

Hi, @nomis After discussing with the HW design team, we confirm that our ESP board can not receive any packets which the length is larger than 127. So we doubt that there might be some out-of-bound memory issues. The Rx frame buffer memory might be written by accident.
So, could you please help us to debug this issue? Let's set a watchpoint to monitor the Rx frame buffer.
First set the 154 rx frame buffer to 4

And then add these codes:
esp_cpu_set_watchpoint(0, s_rx_frame[0], 4, ESP_CPU_WATCHPOINT_STORE);
esp_cpu_set_watchpoint(1, s_rx_frame[1], 4, ESP_CPU_WATCHPOINT_STORE);
esp_cpu_set_watchpoint(2, s_rx_frame[2], 4, ESP_CPU_WATCHPOINT_STORE);
esp_cpu_set_watchpoint(3, s_rx_frame[3], 4, ESP_CPU_WATCHPOINT_STORE);

to the end of the function ieee802154_mac_init
If the watchpoint triggered, you will get a crash log,  please share the crash logs to us.

Ok. I will also have the changes for #326 applied.
I've previously been using IEEE802154_RX_BUFFER_SIZE=100 (because I have a lot of endpoints/clusters) and IEEE802154_TIMING_OPTIMIZATION=y.

Ok. I will also have the changes for #326 applied.
I've previously been using IEEE802154_RX_BUFFER_SIZE=100 (because I have a lot of endpoints/clusters) and IEEE802154_TIMING_OPTIMIZATION=y.

Ok，Refer to 154 Spec, the transmission speed is 250Kbps(32us for 1byte), maybe 1ms for receiving a 30-length packet. This time is enough for the SW to process this packet. Based our test in the high-traffice scenario, 20 is sufficient, so no need for using the size 100 for this buffer.
The reason why I told you to set the buffer size 4 is that C6 only support 4 watchpoints at the same time.

There's no documentation for IEEE802154 in the TRM, so I can't check how dma_rx_addr is supposed to work but can receive happen into the buffer at any time?
What would happen if the dma_rx_addr is set while a packet is being received - could a packet be split across two buffers or the middle of a packet be written to the start of a buffer? Either of those could result in a packet with the wrong length.
There's an inconsistency in the order of IEEE802154_SET_TXRX_PTI() and set_next_rx_buffer() here:
esp_err_t ieee802154_receive_at(uint32_t time)
{
...
    IEEE802154_SET_TXRX_PTI(IEEE802154_SCENE_RX_AT);
    set_next_rx_buffer();

Everything else sets the next buffer first.
(I'm not doing Zigbee and WiFi co-existence but it looks like the handling for it can't be disabled.)

The reason why I told you to set the buffer size 4 is that C6 only support 4 watchpoints at the same time.

SOC_CPU_WATCHPOINT_MAX_REGION_SIZE is 0x80000000 on the ESP32-C6, so I could set a watchpoint on the entire s_rx_frame array, regardless of how many receive buffers are configured?

The ieee802154_receive_at() function also needs to call ieee802154_enter_critical() earlier. Otherwise it's calling stop_current_operation() (via rx_init()) and set_next_rx_buffer() with interrupts enabled.
This function isn't used by the Zigbee libraries.

But per docs of ``

The ieee802154_receive_at() function also needs to call ieee802154_enter_critical() earlier. Otherwise it's calling stop_current_operation() (via rx_init()) and set_next_rx_buffer() with interrupts enabled.
This function isn't used by the Zigbee libraries.

Thanks for catching this risk, this API is not used in Zigbee stack so this risk might not be related to this crash issue. For fixing this risk, we will fix it right now.

The ieee802154_receive_at() function also needs to call ieee802154_enter_critical() earlier. Otherwise it's calling stop_current_operation() (via rx_init()) and set_next_rx_buffer() with interrupts enabled.
This function isn't used by the Zigbee libraries.

Also welcome PRs to fix it :)

This is in zb_zcl_get_next_reporting_info() which has just called zb_zcl_get_attr_desc_manuf_a() with manuf_code of 0 (a4) and received NULL back (a0) so it crashes when it dereferences it:

Hello, I have a similar problem.
When between boot, I change the number of registered clusters/attributes, and the zb lib crash.
A simple flash erase fixes the problem.
An example of how the bug appears:

Boot, register 15 attributes and join a zb network
Reboot --> all work fine
On my project, the user can change to the "advanced mode" and after a reboot register more clusters and attributes (around 30 attributes)
After reboot, the firmware will crash after that the zb stack starts like this:

Can you fix this bug ?
Thanks
....
I (6446) ZIGBEE: Device started up in non factory-reset mode
I (6447) ZIGBEE: Device rebooted
Guru Meditation Error: Core  0 panic'ed (Load access fault). Exception was unhandled.

Core  0 register dump:
MEPC    : 0x4205a8f8  RA      : 0x4205a8f4  SP      : 0x40841bf0  GP      : 0x4081e504
0x4205a8f8: zb_zcl_get_next_reporting_info at ??:?
0x4205a8f4: zb_zcl_get_next_reporting_info at ??:?

MHARTID : 0x00000000

Stack memory:
40841bf0: 0x4205a224 0x00000017 0x0000004a 0x40848eec 0x40848eb4 0x40848a80 0x40842ec9 0x42054c5e
0x4205a224: zb_zcl_reporting_timer_handler at ??:?
0x42054c5e: zb_zcl_send_report_attr_command at ??:?

40841c10: 0x0000000f 0x40841c30 0x00000003 0x4206a394 0x0000000f 0x00000000 0x7fffffff 0x00000002
0x4206a394: zb_osif_scheduler_event at ??:?

40841c30: 0x0000000f 0x00000000 0x00000042 0x00000000 0x00000000 0x4205a3e8 0x00000006 0x00000000
0x4205a3e8: zb_zcl_report_attr at ??:?

40841c50: 0x00000002 0x00000052 0x40848eb4 0x4205a4d8 0x0000000f 0x4205a3e8 0x7fffffff 0x000000ff
0x4205a4d8: zb_zcl_report_attr at ??:?
0x4205a3e8: zb_zcl_report_attr at ??:?

40841c70: 0x0000000f 0x00000000 0x40828ba0 0x42044f14 0x0000007f 0x0000000f 0x40841dd8 0x00000000
0x42044f14: zb_sched_loop_iteration at ??:?

40841c90: 0x40848808 0x00000000 0x40846f48 0x40831000 0x00000000 0x0000ff42 0x00000b04 0x00000004
40841cb0: 0x0000007f 0x0000000f 0x40841dd8 0x40847aa0 0x40848808 0x408480fc 0x42158000 0x420364fe
0x420364fe: esp_zb_main_loop_iteration at ??:?

40841cd0: 0x42157ce8 0x00000394 0x00000007 0x42010b8a 0x00000025 0x40841dd8 0xa5a5a5a5 0xa5a5a5a5
0x42010b8a: zigbee_task at D:/08-LocalRepos/TICMeter/firmware/main/zigbee.c:635

40841cf0: 0xa5a5a5a5 0xa5a5a5a5 0x40847888 0x42150030 0x40847c08 0x40847d70 0x40847d04 0x40847a34
40841d10: 0x0000007f 0x0000ff42 0x0000002d 0x00000025 0xa5a5a5a5 0xa5a5a5a5 0xfb010101 0xa5a50008
40841d30: 0x00010000 0x000003e8 0x00000004 0x030205a0 0xa5a50040 0x00000000 0x00000000 0xa5a500fb
40841d50: 0x00000002 0x00000000 0x00000006 0x00000fa0 0x00030202 0x00c8ffff 0x00000000 0x00000000
40841d70: 0x00030202 0x00000000 0x00000000 0x00000000 0x2e335617 0x2d322e32 0x34672d31 0x30623832
40841d90: 0x642d3762 0x79747269 0xa5a5a500 0xa5a5a5a5 0xa5a5a5a5 0x32303213 0x34302d34 0x2038322d
40841db0: 0x333a3131 0x35303a37 0xa5a5a500 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
40841dd0: 0xa5a5a5a5 0xa5a5a5a5 0x30000030 0x00003030 0x32333935 0xa5a5a500 0xa5a5a5a5 0xa5a5a5a5
40841df0: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
40841e10: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
40841e30: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0x53010401 0x00303200 0x33393500 0xa5000032 0xa5a5a5a5
40841e50: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0x4201041c 0x00000000 0x00000000 0x4081e504
0x4201041c: zigbee_task at D:/08-LocalRepos/TICMeter/firmware/main/zigbee.c:319

40841e70: 0x407f886c 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
40841e90: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
40841eb0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
40841ed0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
40841ef0: 0x00000000 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5
40841f10: 0x00000150 0x40841af0 0x0000336d 0x408221cc 0x408221cc 0x40841f14 0x408221c4 0x00000014
40841f30: 0x40848834 0x40848834 0x40841f14 0x00000000 0x00000005 0x4083ff10 0x6267695a 0x6d5f6565
40841f50: 0x006e6961 0x00000000 0x40841f00 0x00000005 0x00000001 0x00000000 0x00000000 0x00000009
40841f70: 0x408327cc 0x40832834 0x4083289c 0x00000000 0x00000000 0x00000001 0x00000000 0x00000000
40841f90: 0x00000000 0x42006116 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
0x42006116: esp_cleanup_r at C:/Espressif/frameworks/esp-idf-v5.2.1/components/newlib/newlib_init.c:60

40841fb0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000
40841fd0: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000

ELF file SHA256: ff35324e1e01a5c8

Rebooting in  2 seconds...```

@xmow49 ，

Hello, I have a similar problem.
When between boot, I change the number of registered clusters/attributes, and the zb lib crash.
A simple flash erase fixes the problem.

Regarding another issue, I suspect it's related to the binding table size. By default, the binding table size is set to 16 in the esp-zigbee-sdk. Could you try adjusting the size by calling esp_zb_aps_src_binding_table_size_set() with your desired value? Keep in mind that this function needs to be called before esp_zb_init() for it to take effect.

This is in zb_zcl_get_next_reporting_info() which has just called zb_zcl_get_attr_desc_manuf_a() with manuf_code of 0 (a4) and received NULL back (a0) so it crashes when it dereferences it:

Hello, I have a similar problem. When between boot, I change the number of registered clusters/attributes, and the zb lib crash. A simple flash erase fixes the problem.

It looks like a different issue from the original problem described in this issue, could you please raise another issue so that we can discuss them separately? You could also share the elf file or example code in that ticket if possible.

@xmow49 ，

Hello, I have a similar problem.
When between boot, I change the number of registered clusters/attributes, and the zb lib crash.
A simple flash erase fixes the problem.

Regarding another issue, I suspect it's related to the binding table size. By default, the binding table size is set to 16 in the esp-zigbee-sdk. Could you try adjusting the size by calling esp_zb_aps_src_binding_table_size_set() with your desired value? Keep in mind that this function needs to be called before esp_zb_init() for it to take effect.

Many thanks,
Im not able to reproduce the bug.
I set the value to 64 and all works great !
Thanks

After discussing with the HW design team, we confirm that our ESP board can not receive any packets which the length is larger than 127. So we doubt that there might be some out-of-bound memory issues. The Rx frame buffer memory might be written by accident.
So, could you please help us to debug this issue? Let's set a watchpoint to monitor the Rx frame buffer.

This has finally logged a frame length over 127 bytes without a crash:
2024-05-02 12:40:55.056673 ZBOSS: zcl/zcl_main.c:357   zb_zcl_get_cluster_check_value: cluster_id 12 cluster_role 1
2024-05-02 12:40:55.056724 ZBOSS: zcl/zcl_main.c:382   zb_zcl_get_cluster_write_attr_hook: cluster_id 12 cluster_role 1
2024-05-02 12:41:10.723378 E (777449843) ieee802154 frame: ieee802154_frame_get_src_addr(339): invalid frame type
2024-05-02 12:41:10.723430 oversized frame: 0x40817921 150
2024-05-02 12:41:55.067166 ZBOSS: zcl/zcl_main.c:357   zb_zcl_get_cluster_check_value: cluster_id 12 cluster_role 1
2024-05-02 12:41:55.067216 ZBOSS: zcl/zcl_main.c:382   zb_zcl_get_cluster_write_attr_hook: cluster_id 12 cluster_role 1

I'll modify it to log the contents of s_rx_frame when this happens because I suspect it involves writing parts of a normal size frame across two buffers.
There are also some places in the code where the frame data is read without checking that the frame is it at least a certain minimum length too.

Hi, sorry for the delay, how many IEEE802154_RX_BUFFER_SIZE did you used? I see your code, and for double confirm that did you use the size 4 for IEEE802154_RX_BUFFER_SIZE?
For your final code:
   esp_cpu_set_watchpoint(0, s_rx_frame[0], 4, ESP_CPU_WATCHPOINT_STORE);
   esp_cpu_set_watchpoint(1, s_rx_frame[1], 4, ESP_CPU_WATCHPOINT_STORE);
   esp_cpu_set_watchpoint(2, s_rx_frame[2], 4, ESP_CPU_WATCHPOINT_STORE);
   esp_cpu_set_watchpoint(3, s_rx_frame[3], 4, ESP_CPU_WATCHPOINT_STORE);

The watchpoint can only monitor the length of the first 4 of s_rx_frame buffer...

Yes, it's set to 4. I'm now waiting for it to happen again with extra logging.

Yes, it's set to 4. I'm now waiting for it to happen again with extra logging.

Ok, so there will be no OOB issues for the Rx frame buffer in your programe based your test. I discuss this issue with the HW design team, and they said it will be a corner case. The HW will use the frame[0] & 0x7f as the frame length, and calculate the CRC from frame[1] to frame[frame[0] & 0x7f] to make sure the payload is received correctly. So juts no check for the bit8 of the frame[0]. In some cases this bit will be wrong due to PHY decoding wrong under some noise env(very very low probability). We don't think it is a malignant bug, we will add some check in the driver to make sure the length of the packet is less than 127.
Thanks for your patience and hardwork on debugging this issue.

Yes, it's set to 4. I'm now waiting for it to happen again with extra logging.

Ok, so there will be no OOB issues for the Rx frame buffer in your programe based your test. I discuss this issue with the HW design team, and they said it will be a corner case. The HW will use the frame[0] & 0x7f as the frame length, and calculate the CRC from frame[1] to frame[frame[0] & 0x7f] to make sure the payload is received correctly. So just no check for the bit8 of the frame[0]. In some cases this bit will be wrong due to PHY decoding wrong under some noise env(very very low probability). We don't think it is a malignant bug, we will add some check in the driver to make sure the length of the packet is less than 127.
Thanks for your patience and hardwork on debugging this issue.

It's indeed a corner case, the fix has been merged to IDF: https://github.com/espressif/esp-idf/commit/17eb2dcce33e65efb4b1fa98e3b9ed90aa9debff, and will be included in the future IDF releases. Closing this issue.

It has taken 76 days uptime but I've finally had another instance of an oversized frame.
The first rx buffer changed from: 444188BC1388FFFF92790912FCFF92790135E75EB826004B1200286AAB3700E75EB826004B12000034E25CD9F29517536E2D94C5A3A80FD3BDE9D95640DA577A092036B00B5D5A6BD0A38E94B809F86C51EF59E22E02795C2228B1827D404E673C167B6A885021DF33540DC5D56FE59F5AC92F79177D7BE2000000000000000000
to: EE47B266D8976D327B7D66D006B0C1E70E1401331237026004C214E2300000C0301E5227311361102E320700F00670101F4066A31E200041008C3177234E3027D61E010003600C0C6D000603270100EFB000154866016000026202C4394004F402011D6AC40007F2620752F3C993FC9F5AC92F79177D7BE2000000000000000000
The number of bytes overwritten is consistent with a 7-bit length of 0xAE (110 bytes) but the content looks like noise or a message from a different PAN.


No HTML formatting  Rails 4.x Windows 7.

I installed awesome print but it doesn't seem to be formatting.
Gemfile
gem 'awesome_print', require: 'ap'
in my html.erb
<% require "awesome_print" %>
<%= ap @observation.inspect.html_safe %>

<%=  @observation.inspect %>

<%= ap Observation %>

What I see (removed middle part for readability)

"#<Observation id: 344, employee_id: nil, supervisor_last_name: \"Smith\", supervisor_first_name: \"Greg\", department_id: 2, team_id: nil, . . .  updated_at: \"2016-06-27 17:15:39\", date_discussed: \"2016-06-13\", reason: nil, points: nil, point_value_id: nil, supervisor_id: 117, employee_raw: \"[\\\"Chris Jones\\\"]\", supervisor_raw: nil, user_id: 87, testchk: nil>"

`#<Observation id: 344, employee_id: nil, supervisor_last_name: "Smith", supervisor_first_name: "Bob", . . .  ., supervisor_id: 117, employee_raw: "[\"Chris Jones\"]", supervisor_raw: nil, user_id: 87, testchk: nil>`
. . .

class Observation < ActiveRecord::Base { :id => :integer, :employee_id /kbd>:integer, :testchk => :boolean }

If I try using ap from the console, I get
> require "ap"
=> true
>> ap @observation
nil
=> nil
>> require "awesome_print"
=> false
>> ap @users
nil
=> nil

I did run bundle install and it seems to be installed

Using auto-session-timeout 0.9.2
Using awesome_print 1.7.0
Using debug_inspector 0.0.2

My environment is

win 7 pro 64 bit
Ruby Information :  ruby 2.2.4p230 (2015-12-16 revision 53155) [i386-mingw32]
Rails Environment :  development ( development/test/production)

Other things I use with html_safe such as ckeditor do show up in an html format.

Hi @cmendla-cct
I don't think it's anything to do with the environment. ap takes an object and pretty prints it. In your case you are passing it a string so there is not much for it to do other than putting some quotes around it.
When you call @observation.inspect you transform your observation variable into a string. You don't need inspect when using awesome print as that's essentially what we are doing: http://ruby-doc.org/core-2.3.3/Object.html#method-i-inspect
What you probably want to do is ap(@observation), or in your case because you want to then convert it to be a html safe string you will instead want to use the ai (stands for Awesome Inspect) method. So instead of:
<%= ap @observation.inspect.html_safe %>
you can write:
<%= @observation.ai.html_safe %>
I'm guessing in your console example the instance variables were not available in that context and so they defaulted to nil (which I agree is unintuitive, but this is just what Ruby does).
With your:
>> require "awesome_print"
=> false

again this is just another strange Ruby thing that catches out a lot of people. false just means it's already been loaded. https://ruby-doc.org/core-2.3.3/Kernel.html#method-i-require If it can't require at all, it actually throws a https://ruby-doc.org/core-2.3.3/LoadError.html.
Hope that helps :)

It is working well now.

What you probably want to do is ap(@observation),

was the key.
Thanks


Bump Android SDK & Set Native/Android SDK Name on crashes

This PR Bumps Android SDK to version 6.19. Additionally, it also sets the native and android SDK names as
sentry.java.android.capacitor
sentry.native.android.capacitor
sentry.cocoa.capacitor
And by changing the SdkInfo, I also added tests for the sdkinfo logic since it was missing.
Sample events:
android
https://sentry-sdks.sentry.io/issues/4278229145/events/9e681ea435654a4ca16cae8e47134ff0/
ios
https://sentry-sdks.sentry.io/issues/4297593626/events/b30ea4807af54e67aff20fef5b0a30e3
Close #379

It looks good, but I've noticed some differences between how metadata are handled on RN and here in Capacitor. We will have to adjust the implementation to work the same in Capacitor.


Error when migrate using pg_dump-generated .sql file

Setup
Versions

Rust: 1.43.1
Diesel: 1.4.4
Database: postgresql
Operating System ubuntu 18.04

Problem Description
This is my first time using diesel. I used embed_migrations! on my rust code in /bin to migrate .sql file generated from pg_dump. I copied the content and put into migrations/_data/up.sql and then run it. Process returned error because of COPY () FROM stdin;
I've searched on diesel documentation related to this, but what i found was example case where .sql file was generated by diesel itself (or maybe i missed some info).
What are you trying to accomplish?
Migrate .sql to new database. (expected to similar with pg_restore).
What is the expected output?
migration succeed without error
What is the actual output?
QueryError(DatabaseError(__Unknown, "syntax error at or near \"1\""))
Steps to reproduce
up.sql
--
-- PostgreSQL database dump
--
-- Dumped from database version 10.1
-- Dumped by pg_dump version 10.12 (Ubuntu 10.12-0ubuntu<IP_ADDRESS>)

SET statement_timeout = 0;

SET lock_timeout = 0;

SET idle_in_transaction_session_timeout = 0;

SET client_encoding = 'UTF8';

SET standard_conforming_strings = ON;

SELECT
    pg_catalog.set_config('search_path', '', FALSE);

SET check_function_bodies = FALSE;

SET xmloption = content;

SET client_min_messages = warning;

SET row_security = OFF;

--
-- Data for Name: credentials; Type: TABLE DATA; Schema: public; Owner: usertest1
--

COPY public.credentials (database_pid, pseudo_id, shared_use, internal_hosts, external_hosts, username, PASSWORD, DATABASE, replica_set, deployment_method, datacenter_code, status)
FROM
    stdin;

1 1 f test test USER pass dbauth test test dc test
-- PostgreSQL database dump complete
--

Checklist

[X] I have already looked over the issue tracker for similar issues.
[X] This issue can be reproduced on Rust's stable channel. (Your issue will be
closed if this is not the case)

First of all a up.sql file is never generated by diesel itself (only an empty file is created by diesel migration generate). It is expected that the user writes/provides those files.
For your error message: COPY … FROM stdin; is designed to be executed via the psql command line tool. Diesel cannot support such constructs easily because libpq (the official postgres client library we use below) does not allow mixing such constructs with ordinary sql.
COPY … FROM stdin; expressions are normally used to insert large amounts of data into a database, while migrations are normally used to instance the schema itself (and not to insert actual data). So I see a few possible workarounds here:

Check if you really want to import the actual data, or only recreate the schema. If so use a dump generated with --schema-only
If you really want to import the data use a dump generated with --inserts

(See the postgres documentation for details)
I'm closing this issue as I'm considering this question answered.


fix Blackberry errors on proxyPromise

experiencing issues (500 error) w/ proxyPromise on Blackberry 10. it seems that, when xhr.readyState is 0 or 1, accessing xhr.status and xhr.statusText throws an exception

Is there a way we can guard against this without silently swallowing any errors? I feel like this may cause more troubles around other props in the future.
Maybe we can console.log that there's been an error?

yeah, I was thinking that might be better too. added

Great, thanks.

@akre54 thank you!


[extractor/common] simplify using data, headers and query params with download* methods

I have a different idea: if url_or_request is a Request object, ignore data, headers and query fields (or raise an ExtractorError if anyone if given). I guess it simplifies the codes and is suitable for current use cases.

I have a different idea: if url_or_request is a Request object, ignore data, headers and query fields (or raise an ExtractorError if anyone if given). I guess it simplifies the codes and is suitable for current use cases.

thanks for the idea done in 8b9da7408eaee3d3497e4a069b4b953ae93865fb.
after making the first changes i forget at all why i started this change and tried to make it compatible with both types.
the initial idea was to avoid creating Request objects manually in the extractors as most the times we're creating the Request objects mostly for passing headers or data to the urllib.

Looks good. Could you squash commits and add documentation for the new behavior of _request_webpage?

i will squash the commit.
and about the documentation, the headers and data params are named with the same names used by Request so the python documentation has details on this params.

Sorry for misleading. I was talking about the behavor "data, headers and query are ignored if url_or_request is already a Request object".

like adding a comment like this above the code or after function description:
# data, headers and query params will be ignored for `Request` objects

is this enough?

That's fine. Just for unneeded confusion in case of an extractor fails silently.

may be it's better add this part directly to sanitized_Request(add query param to sanitized_Request):
if query:
                url_or_request = update_url_query(url_or_request, query)

and for optimization. will it be better to create a Request object when the function receive query without headers and data.

If you're going yo do that, chage the name of sanitized_Request. The original name should do nothing except making the request sane. Another option: just merge the functionality of sanitized_Request into _request_webpage?

for this PR, i will merge only the changes made to download* method.


[SPARK-48774][SQL] Use SparkSession in SQLImplicits

What changes were proposed in this pull request?
This PR proposes to use SparkSession at SQLImplicits.
Why are the changes needed?
To use SparkSsession that is encouraged over SQLContext.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
CI in this PR should test them out.
Was this patch authored or co-authored using generative AI tooling?
No.

What do you think about this one? https://github.com/apache/spark/pull/45727#issuecomment-2164670064

I think we can add a new API, and deprecate old ones

I think we can add a new API, and deprecate old ones

To clarify, SPARK-46575 applies to 4.0, so it can be changed directly.

API seems from 3.5.2 https://github.com/apache/spark/pull/45727? I think it's safer to just deprecate and add a new one in 4.0

API seems from 3.5.2 #45727? I think it's safer to just deprecate and add a new one in 4.0

Only 4.0.0, see https://github.com/apache/spark/pull/45737

We could add. What I am not sure is that this is matched with exiting API startWithContext, and this adds an overloaded one. Why don't we just add a new one?

For STS SQLContext replacement, I opened https://github.com/apache/spark/pull/47176, let's discuss there.

Merged to master.


Socket recv should return the number of bytes read rather than the buffer

One of the advantages of socket_recv is it returns the length of the data for you.  I believe that method should take the $buffer parameter by ref and return the length as the php function does.

This would also apply to the function socket_recvfrom

@mrrsm Thanks for your suggestion and the accompanying PR!
Changing the public interface like this introduces a BC break, so we should consider this thoroughly.
Admittedly, the current implement differs from what the underlying function returns, so this is very well worth discussing!

One of the advantages of socket_recv is it returns the length of the data for you. I believe that method should take the $buffer parameter by ref and return the length as the php function does.

Personally, I consider the current behavior to be a convenient feature. Also, this happens to be in line with how socket_read() and fread() etc. work. Having used this library is several projects, it also never occurred to me (so far).
Judging from your wording, I'm assuming you have a particular use case in mind which would benefit from this? Perhaps you can elaborate on this use case and how you think the updated API is advantageous? Thanks!

If you are doing a socket_recv it is taking the liberty of getting my the length of the data it read (which may not be a full read to the length I asked for).   This means that when I get my data back I need to verify that the appropriate amount of data has been received.
The project I am working on requires us to send a large amount of data around which can end up in partial reads requiring us to validate the return data's length.
This is more of a convenience for me as it reduces a second call I would have to make but this also brings the Socket.php class more inline with the underlying functions, like you said already.

Also the amount of data we end up sending makes the second call for length add up over time.
I'm porting legacy code and updating it to use classes FYI.

validate the return data's length

Sounds like a sane approach either way :-)

reduces a second call

I'm not sure how relevant this is for PHP for the following reasons:
The underlying socket functions operate on buffers of individual bytes (usually represented as a char * in C). Because the buffer may contain any binary data (including NULL bytes) it's impossible to reliably determine the buffer size in C (C's strlen() only counts until encountering the first NULL byte, with O(n)). Hence, the socket API also returns the buffer size.
However, this doesn't really apply to PHP at all: PHP represents the received buffer as a string which in turn happen to be a data structure which also stores the string length. As such, PHP's strings are binary safe and offer a reliable way to determine its size.
Also, this means that calling PHP's strlen() function happens to be O(1) (aka. rather fast). I'd be surprised if this turns out to be major performance issue in your code.

inline with the underlying functions […] porting legacy code

I agree that this might be an issue, albeit a smaller one: Porting legacy code requires effort for porting to the OOP API and Exception handling anyway, so I'm not sure this is really that relevant either.
Personally, I'd rather offer a consistent API surface: read(), recv(), recvFrom() all work very similar – which IMHO is a valid reason to break 1:1 relationship with the underlying socket API.

Also, this means that calling PHP's strlen() function happens to be O(1) (aka. rather fast). I'd be surprised if this turns out to be major performance issue in your code.

I agree that it is fast, however it is a call that I shouldn't have to make as that data was already available to me if I used socket_recv which you already have as you checked in

Personally, I'd rather offer a consistent API surface: read(), recv(), recvFrom() all work very similar – which IMHO is a valid reason to break 1:1 relationship with the underlying socket API.

I can understand wanting to have that common interface between them. It is abstracting away part of the way php decided to implement the function which is what have grown used to using I guess.
Another option, which wouldn't disregard that data, would be to add the length as the data passed by reference rather than the buffer data.
I just feel that I am doing something wrong if I am making another function call to get the length even though we have already got that info and stored it in memory once.
Any thoughts on that?

Another option, which wouldn't disregard that data, would be to add the length as the data passed by reference rather than the buffer data.

I agree that this might make this more likely to get in as it does not involve a BC break.
Adding an optional reference parameter for the string length only will result in some added runtime complexity.
If we were talking about some computationally expensive operation (like a cryptographic checksum e.g.), then I'd probably agree that we should indeed add this.
However, for the string length only, I still fail to see the broad applicability of this approach. Checking for the availability of the additional parameter could easily outweigh just invoking strlen() if desired.
Would you care to file a (new) PR so we can see how this works out? :+1:

I just feel that I am doing something wrong if I am making another function call to get the length even though we have already got that info and stored it in memory once.

I absolute agree that things should be kept in memory: calling strlen() essentially just returns a value that is already held in memory :-)

No further input so far, so I'm closing this via #23.


Why creates two LTs when use launch template with managed node groups?

Description
When I run the example launch_templates_with_managed_node_groups, I found two launch template are created. I do not know why? And which LT will be used when new nodes added
Versions

Terraform: v0.15.1

providers:
provider "registry.terraform.io/hashicorp/aws" {
version     = "3.38.0"
constraints = ">= 2.70.0, >= 3.22.0, >= 3.35.0"
hashes = [
"h1:qKEjN/EM56XT46vGY33eoq7nD6JuGqRqFp7tkzTrRM0=",
]
}

provider "registry.terraform.io/hashicorp/cloudinit" {
version = "2.2.0"
hashes = [
"h1:siiI0wK6/jUDdA5P8ifTO0yc9YmXHml4hz5K9I9N+MA=",
]
}
provider "registry.terraform.io/hashicorp/kubernetes" {
version     = "1.13.3"
constraints = "~> 1.11, >= 1.11.1"
hashes = [
"h1:iV0RArGM0KJ3n0ctwpNzcTkTAnx5G4wV3V3kYkRpJXU=",
]
}
provider "registry.terraform.io/hashicorp/local" {
version     = "2.1.0"
constraints = ">= 1.4.0"
hashes = [
"h1:KfieWtVyGWwplSoLIB5usKAUnrIkDQBkWaR5TI+4WYg=",
]
}
provider "registry.terraform.io/hashicorp/null" {
version     = "3.1.0"
constraints = ">= 2.1.0"
hashes = [
"h1:xhbHC6in3nQryvTQBWKxebi3inG5OCgHgc4fRxL0ymc=",
]
}
provider "registry.terraform.io/hashicorp/random" {
version     = "3.1.0"
constraints = ">= 2.1.0"
hashes = [
"h1:rKYu5ZUbXwrLG1w81k7H3nce/Ys6yAxXhWcbtk36HjY=",
]
}
provider "registry.terraform.io/hashicorp/template" {
version     = "2.2.0"
constraints = ">= 2.1.0"
hashes = [
"h1:0wlehNaxBX7GJQnPfQwTNvvAf38Jm0Nv7ssKGMaG6Og=",
]
}

Module:   terraform-aws-eks 15.2.0

Reproduction

remove line “instance_type = var.instance_type”   in launchtemplate.tf
terraform init
terraform apply

Can you please share your configuration ?

In examples folder:  launch_templates_with_managed_node_groups.
I changed the file launchtemplate.tf.  I deleted line instance_type = var.instance_type and open the user_data
data "template_file" "launch_template_userdata" {
  template = file("${path.module}/templates/userdata.sh.tpl")

  vars = {
    cluster_name        = local.cluster_name
    endpoint            = module.eks.cluster_endpoint
    cluster_auth_base64 = module.eks.cluster_certificate_authority_data

    bootstrap_extra_args = ""
    kubelet_extra_args   = ""
  }
}

# This is based on the LT that EKS would create if no custom one is specified (aws ec2 describe-launch-template-versions --launch-template-id xxx)
# there are several more options one could set but you probably dont need to modify them
# you can take the default and add your custom AMI and/or custom tags
#
# Trivia: AWS transparently creates a copy of your LaunchTemplate and actually uses that copy then for the node group. If you DONT use a custom AMI,
# then the default user-data for bootstrapping a cluster is merged in the copy.
resource "aws_launch_template" "default" {
  name_prefix            = "eks-example-"
  description            = "Default Launch-Template"
  update_default_version = true

  block_device_mappings {
    device_name = "/dev/xvda"

    ebs {
      volume_size           = 60
      volume_type           = "gp3"
      delete_on_termination = true
      # encrypted             = true

      # Enable this if you want to encrypt your node root volumes with a KMS/CMK. encryption of PVCs is handled via k8s StorageClass tho
      # you also need to attach data.aws_iam_policy_document.ebs_decryption.json from the disk_encryption_policy.tf to the KMS/CMK key then !!
      # kms_key_id            = var.kms_key_arn
    }
  }

  #instance_type = var.instance_type

  monitoring {
    enabled = true
  }

  network_interfaces {
    associate_public_ip_address = false
    delete_on_termination       = true
    security_groups             = [module.eks.worker_security_group_id]
  }

  # if you want to use a custom AMI
  # image_id      = var.ami_id

  # If you use a custom AMI, you need to supply via user-data, the bootstrap script as EKS DOESNT merge its managed user-data then
  # you can add more than the minimum code you see in the template, e.g. install SSM agent, see https://github.com/aws/containers-roadmap/issues/593#issuecomment-577181345
  #
  # (optionally you can use https://registry.terraform.io/providers/hashicorp/cloudinit/latest/docs/data-sources/cloudinit_config to render the script, example: https://github.com/terraform-aws-modules/terraform-aws-eks/pull/997#issuecomment-705286151)

  user_data = base64encode(
    data.template_file.launch_template_userdata.rendered,
  )

  # Supplying custom tags to EKS instances is another use-case for LaunchTemplates
  tag_specifications {
    resource_type = "instance"

    tags = {
      CustomTag = "EKS example"
    }
  }

  # Supplying custom tags to EKS instances root volumes is another use-case for LaunchTemplates. (doesnt add tags to dynamically provisioned volumes via PVC tho)
  tag_specifications {
    resource_type = "volume"

    tags = {
      CustomTag = "EKS example"
    }
  }

  # Tag the LT itself
  tags = {
    CustomTag = "EKS example"
  }

  lifecycle {
    create_before_destroy = true
  }
}

This code doesn't create 2 LT. It this related to the following (taken from the LT comment).
# Trivia: AWS transparently creates a copy of your LaunchTemplate and actually uses that copy then for the node group. If you DONT use a custom AMI,
# then the default user-data for bootstrapping a cluster is merged in the copy.
resource "aws_launch_template" "default" {
  # ...
}

Oh, Thanks. I did not see that message.


ipsec: Fix packet mark for FWD XFRM policy

First commit fixes https://github.com/cilium/cilium/issues/23090; second extends the existing test. See commits for details.

/test

This PR was never actually backported to v1.12. Remarding.


Add script to install all requirements from CLI

We should come up with a full list of all the required Android tools so we could prepare a CLI command to install all of the requirements at once without the need to go through the Android Studio UI.

Or provide a docker image as mentioned in #12.


Performance issue?

I have created a code that should be quite good at reproducing the performance issue
    private static function createMultipleImages(UploadedFile &$uploadedFile, string $outputFormat='webp') {
        $filename = 'myOutputImage';
        for($i = 1; $i< 6; $i++) {
            $width = 200 * $i;
            $image = Image::make($uploadedFile->getRealPath())->encode($outputFormat);
            if($image->width() >= $width) {
                $image->resize($width, null, function ($constraint) {
                    $constraint->aspectRatio();
                    $constraint->upsize();
                });
                $image->save(__DIR__.'/'.$filename.'_'.$width.'.'.$outputFormat);
            }
            $image->destroy();
            $image = null;
        }
    }

Didn't run it, but the concept is the same.
The input on which I do test that function is some image from unsplashd with 6000x4000 dimension and around 3MB in size;
Execution time is calculated in like half a minute, maybe more, it is just highlt noticeable and I may just do something wrong there.
Maybe the webp is the reason why, or I should compile my alpine docker image with some extra settings

I think this is not related to this library but to the performance of GD or Imagick in general.


Adjust activation text if pdf was opened without installed app

Is your feature request related to a problem? Please describe.
Currently we show an activation route with information if someone opens the HTTP_SCHEME deeplink on the pdf without having the app installed
Describe the solution you'd like

adjust the activationText.tsx template with the information that koblenz wants to display

Describe alternatives you've considered

use one general template for all projects and move activationText.tsx to a common folder

@dkehne can you check this with koblenz
Here you can find a example of the route (card data invalid)
https://staging.bayern.ehrenamtskarte.app/activation/code#sdjaksdbjk3232

we decided on reusing the bavaria template and use it as a common template. so please move the template to a common folder and use it for both projects


1.6 Monster Importer's parsing of spell ranges is not very robust

The monster importer is able to interpret spell ranges from the description in some cases, but not all.
		// Take a chance at finding the range in the description
		if (descStr.includes(" self.")) {
			spellObj.system.range = "self";
		}
		else if (descStr.includes(" close.")) {
			spellObj.system.range = "close";
		}
		else if (descStr.includes(" near ") || descStr.includes(" near.") || descStr.includes(" near-sized ")) {
			spellObj.system.range = "near";
		}
		else if (descStr.includes(" far ") || descStr.includes(" far.")) {
			spellObj.system.range = "far";
		}

The SD texts are inconsistent about whether to use periods or commas in the range description. This block of text could use a few more cases to include all possibilities. I will try to find cases that cover all the published monsters adequately.

Yeah, these statements are low effort tries for the range. Would welcome approves, but you're right that there's isn't a strong convention for this, even within the core rules.


ImportError: No module named adversarial

Hello,I attempt to reproduce your adversarial net , but there is something wrong as the tittle mentioned.
I noticed that I should set the "adversarial" directory in my PYTHONPATH environment variable.
I am puzzled,however ,what does the "adversarial" directory meani? I tried to set  directory of the
project into the PYTHONPATH but failed with the "ImportError: No module named adversarial".
I wish you could Solve my doubts.Thanks a lot.

Hi Soloman1588, I am having the issue. Did you figure out what the problem was?

You should set your PYTHONPATH environment variable to be equal to the directory that contains your cloned version of this repo.  For instance, if you cloned this repo into a folder called "git", then in your .bashrc file:  export PYTHONPATH=$HOME/git.
The PYTHONPATH variable tells python where to look for modules (aside from the default locations).  By setting it to the parent directory of this repo, it will find the "adversarial" folder and look within it for the module files.

@Solomon1588 did you solve the problem？I'm having the issue too.
@zjost It's comes "No module named adversarial" after I add the PYTHONPATH in .bashrc.what should i do ?

This question is better for Stack Overflow, as it isn't specific to this code, it is a general Python question.  To make sure your changes took effect, you can echo $PYTHONPATH and verify it is as expected.  If it's still not there, perhaps you forgot to actually run your .bashrc.  You can either log off and on again or simply source ~/.bashrc.

@zjost thank you very much,I imported the adversarial in python ,but there's  output  "warnings.warn(warn)"
how should I config the path of the mnist or other datasets?


If there is no posts, the function should return empty

I want to hide the text "Related Posts" if no posts are returned.
When there is no posts matched, popular_posts( {} , page )  returns

It makes me impossible to write if statement to judge whether there exists at least related post  or not.
I think popular_posts( {} , page ) should return empty string or any value equivalent to empty if no posts are related to the current post.

@huyingjie  I see . Which theme do you use ?
Also, could you avoid this issue temporarily with the popular_posts_json() tag ?

https://github.com/huyingjie/hexo-theme-A-RSnippet

@huyingjie
Have you confirmed that the same problem will occur with default theme ?


Unable to Create File

Before Submitting: Double-check that you are running the latest version of the plugin. The bug might have already been fixed 😄

Describe the bug
New since installing version 1.4.16 of Obsidian I can no longer click on the calendar to create a daily note. I get an "Unable to create new file." error. But I can create a new note in the vault using the normal Obsidian create note options.
Steps to reproduce

Go to the calendar view.
Click on any date for which a new note does not exist.
See error "Unable to create new file" and the note is not created.

Expected behavior
New note created using my template as it was done for the previous year+.
Screenshots
If applicable, add screenshots to help explain your problem.
OS
Macintosh Ventura 13.6
Obsidian Version (e.g. v0.10.6)
1.4.16
Theme (if applicable):
If the bug is visual, please provide the name of the Community Theme you're using.

Do not use "yyyyMMDD" for the date format of the "Diary" plugin.

I don't use the diary plugin.
But I should have come back and indicated that after a while there was a new version of Obsidian out with a new Installer and after doing that re-install the bug is gone and I do get my proper template and file created.

The "Diary" plugin is the core plugin that comes with Obsidian. I had the same problem as you, then I changed the date format of the "Diary" plugin, and the problem didn't occur anymore. Sorry, I'm a Chinese user and I use Chinese.

Ah, on my system it's called daily notes and I never had that as my date format anyway. Mine looks like this

I don't use the diary plugin.
But I should have come back and indicated that after a while there was a new version of Obsidian out with a new Installer and after doing that re-install the bug is gone and I do get my proper template and file created.

Uh-huh. I mean, you could try changing your date format until the plugin can create or recognize the journal file properly. The reason? I checked the history of issue submissions and realized that the developer has not responded to this issue - which implies that, in the short term, the developer won't be able to resolve this issue for you.

The developer doesn't have to respond. The issue is gone, done fixed. My solution was described in the message you responded to. If youa re still having problems with the date formats then I suggest you re-install Obsidian using a new Installer version like I did and see if that fixes it for you.


Find an alternative to JsonConvert.DefaultSettings

In the static constructor for KeycloakClient, a method is assigned to JsonConvert.DefaultSettings that sets the contract resolver to CamelCasePropertyNamesContractResolver. When using this library in a project that is already using Json.Net (Newtonsoft.Json), this will overwrite the default settings across the entire project.
As an example, I have a project that frequently serializes to/deserializes from JSON. Until an instance of KeycloakClient is created Json.Net's default TitleCasing is used, and after the instantiation occurs all of the objects that I've previously serialized can no longer be deserialized.
What makes this worse is that the serialization/deserialization happens in 2 separate services, one that has a reference to Keycloak.Net and one that doesn't. The end result is that while the service that uses Keycloak.Net would be able to deserialize the object correctly, the one that doesn't is still expecting the serialized object to be TitleCased.
I'm definitely planning on putting in the time to work on this and create a PR, but I'm curious about the original motivations to put this in place so I'm not causing a regression.

Hi Nathan,
The original motivation was: apply CamelCase. :-) If you find a better way, I'll be interested to look at your PR!
Regards,
Luk

Fixed in release 1.0.11


ext/lib/mgmt/mcumgr/cmd/log_mgmt/Kconfig references MDLOG, but MDLOG doesn't exist

We have depends on MDLOG but MDLOG doesn't exist anywhere.

fixed already.


Add language field to CompletionContext

Problem
For file types with embedded language, such as jsx, html, and php, it is sometimes useful to know the embedded language from which completions have been requested. I believe that https://github.com/Microsoft/vscode/issues/40539 for example depends on this functionality
Proposal
Add a new language field to the CompletionContext:
export interface CompletionContext {
    ...

    readonly languageId?: string
}

Alternative Design
Expose a API that allows extensions to determine the embedded language at a given position in a file. Something like:
export interface TextDocument {
     ...

     languageIdAt(position: Position): string
}

// cc @ramya-rao-a for emmet, @roblourens for php, and @aeschli for html

Giving out the language id in a competition context is, IMO, a fair request. But I'm not sure how useful it is as one often needs more context (am I in a tag, attribute, in a string, in a comment...) to really do something.
The second suggestion, being able to query for the language id of every offset, with a sync call is costlier: It would require tokenizing the document. This likely has to happen on the extension host as syncing that information over from the renderer is expensive. Also, the renderer doesn't have the tokens all the time (typically only for to the visible lines).
A bigger problem, however, is that the language information is TextMate grammar based. TextMate tokenization has its limits, due to the fact that grammars are regexp based and the text mate engine only see a line at a time and can make changes to already emitted scopes.
However, language servers have precise scanners and parsers and also get the corner case right.
I had many discussions with @alexandrudima on this topic and I often lobbied to give out the embedded language id, but we always came to the conclusion that it will lead down a problematic path, putting more pressure on text mate grammars (that we don't control) and ending up with plenty of bugs due to corner cases that can't be fixed due to TextMates limitations.
Our investments should go into language servers and language servers extensibility.

Yes, we've discussed a generic "inspect token" api a few times previously and I believe we've always settled on it being potentially too expensive
Making the language servers smarter is always an option but it would be overkill for features like #40539, especially if VS Code already has the language info internally. #40539 tracks making < a suggest trigger character for JSX code. The challenge is that we don't want to trigger suggestions after you type a normal, javascript, less-than operator, only when you are in jsx and are starting a tag. A few ways this could be implemented:
Using this proposal

Add < as suggest trigger character for js.
Only actually trigger suggestions if the embedded language is jsx-tags

Smarter TS (hacky)

Add < as suggest trigger character for js.
Make TS only return suggestions immediately after a < when in jsx

Smarter TS (better)

Add < as suggest trigger character for js.
Add API to TS to check if we are in jsx at a given position
When triggering on <, query TS Server and only return suggestions when we know we are in jsx

Embedded language aware trigger characters

Allow extensions to register embedded language specific completion trigger characters
Use this API to register < as a trigger character for the jsx-tags language

@ramya-rao-a Weren't you running into a some limitations around embedded languages for emmet, or have those been worked around?

For Smarter TS (better)

When triggering on <, query TS Server and only return suggestions when we know we are in jsx

Can't TS server just return empty CompletionItem[] when triggering on < outside JSX?
It seems paradoxical to me -- if a server can support embedded language, it would already have the languageId info, which would be more correct than the one generated from TM, if the server has a proper parser.
I agree with @aeschli making LS behavior dependent on TM grammar doesn't sound right.

TM grammar can often be wrong with scopes when program is invalid (a natural state of writing code)
TM scopes are expensive to re-generate on each file change
There are a lot of not-so-good TM grammars there due to its under-documentedness.

But I get the overkill argument. One way might be making vscode-textmate easily consumable by LS, so people can write simple JSX LS that inefficiently do some simple completion for the easy of development.

The TS server has no knowledge of what triggered completions. We do the gating on the extension side
On the second point: we already use the embedded language id for computing snippet completions, so I don't think  this proposal will add very much overhead. If there are problems with the grammars, we should look into fixing these since some of our other basic language features depend on embedded language information already


Jesse: Watch codelaravel.com

Jesse requests the watch of the watch_keyword codelaravel\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

codelaravel\.com has been seen in 2 true positives, 0 false positives, and 0 NAAs.

Approved by Mast in Charcoal HQ


Error while natural = require('natural')

Hi
I am getting error while I require natural as below.
var natural = require('natural');
Error :
TypeError: word.trim is not a function
at loadDictionary (\node_modules\natural\lib\natural\stemm
ers\indonesian\stemmer_id.js:136:21)
In file stemmer_id.js
function loadDictionary(){
var fs = require('fs');
var dirname = __dirname + "/../../../../data/kata-dasar.txt";
var fin = fs.readFileSync(dirname).toString().split("\n");
for(var i in fin){
var word = fin[i];
word = word.trim();
dictionary.push(word);
}
}
error is => word = word.trim();
correction is =>
if (typeof word !== 'string') {
word = word .toString();
}
So that the function becomes
function loadDictionary(){
var fs = require('fs');
var dirname = __dirname + "/../../../../data/kata-dasar.txt";
var fin = fs.readFileSync(dirname).toString().split("\n");
for(var i in fin){
var word = fin[i];
if (typeof word !== 'string') {
word = word .toString();
}
word = word.trim();
dictionary.push(word);
}
}
Similar issue in file prefix_rules.js at line number 36

I installed natural through npn install and then used natural as bellow. I have not cloned the code from github repo manually.
var natural = require('natural');
Pravesh

I installed natural from npm and did this:
hugo@hugo-Z97-D3H:~/Workspace/test_natural_from_npm$ cat testNatural.js
var natural = require('natural');
console.log('hello');
hugo@hugo-Z97-D3H:~/Workspace/test_natural_from_npm$ nodejs testNatural.js
hello
hugo@hugo-Z97-D3H:~/Workspace/test_natural_from_npm$ nodejs -v
v9.11.1
hugo@hugo-Z97-D3H:~/Workspace/test_natural_from_npm$

What version is your nodejs?
Hugo

I'm sorry. I ran the version from NPM with node version v6.14.1 and could succesfully require natural. Could you give me more details about what you did exactly so I can reproduce? So a step-by-step description leading to the error you described. Thanks!
Hugo

Hi @Hugo-ter-Doest , I'm having the same problem for prefix_rules.js. I recalled that I used to face this same error in stemmer_id.js in past versions, and the error has been patched for that file.
So I managed to hack the error away by replicating the solution that patched stemmer_id.js in commit https://github.com/NaturalNode/natural/commit/0ce591f751e5b5b8839127977137e294eb06c770 on prefix_rules.js. I'm on node version v8.7.0.

It seems to be related to the use of for-in to loop through an array. If the array is out-of-the box, there is no problem, but if you extend the array's prototype, I get the same error as you have. That is why the use of for-in for array is considered bad-practice by some. The following sample illustrates what is going on:
var natural = require('natural');

Array.prototype.someExtension = function() {};
var dictionary = [];
function loadDictionary() {
    var fs = require('fs');
    var dirname = "./node_modules/natural/data/kata-dasar.txt";
    var fin = fs.readFileSync(dirname).toString().split("\n");
    for(var i in fin){
      if (typeof fin[i] != "string") {
        console.log("Alarm, index + " + i + " is not a string: " + fin[i])
      }
      var word = fin[i];
      word = word.trim();
      dictionary.push(word);
    }
}

loadDictionary();

When I run this I get:
Alarm, index someExtension is not a string: function () {}
/home/hugo/Workspace/testNpmNatural/testNatural.js:14
      word = word.trim();
                  ^

TypeError: word.trim is not a function
    at loadDictionary (/home/hugo/Workspace/testNpmNatural/testNatural.js:14:19)
    at Object.<anonymous> (/home/hugo/Workspace/testNpmNatural/testNatural.js:19:1)
    at Module._compile (module.js:649:30)
    at Object.Module._extensions..js (module.js:660:10)
    at Module.load (module.js:561:32)
    at tryModuleLoad (module.js:501:12)
    at Function.Module._load (module.js:493:3)
    at Function.Module.runMain (module.js:690:10)
    at startup (bootstrap_node.js:194:16)
    at bootstrap_node.js:666:3

![](https://user-images.githubusercontent.com/25717886/39592706-386aa568-4f25-11e8-9d82-e3b8a74eb8d5.png)

So, I think your array's prototype is somewhere extended, and the for-in construct tries to process this element as a word. To repair this you have to replace the for-in constructs in prefix_rules.js and stemmer_id.js by a forEach or a simple for (var i = 0; i < fin.length; i++) construct.
I will repair the version here in Github, because the prefix_rules.js still uses the for-in construct.
Hugo

Repaired prefix_rules.js in commit https://github.com/NaturalNode/natural/commit/bee0421ed4f568bd7824fea882dcfd0995d8dd20
Hugo

Please comment if this did not fix your problem.
Hugo

I think you need to use browserify or webpack to convert the calls to the filesystem to something that can work in de browser.

Okay, the issue is the path being used in readFileSync here:
function loadDictionary(){
    var fs = require('fs');
    var dirname = __dirname + "/../../../../data/kata-dasar.txt";
    var fin = fs.readFileSync(dirname).toString().split("\n");
    fin.forEach(function (word) {
        if (word) {
          dictionary.push(word.trim());
        }
    });
}

While building with webpack if you console.log the path you get //../../../../data/kata-dasar.txt which fails to resolve. Webpack __dirname defaults to / unless configured otherwise. Can read about this issue in depth here: https://github.com/webpack/webpack/issues/1599.
After messing with this for a few hours, the fix went with was:

Convert ./data/kata-dasar.txt to JSON.
Replace loadDictionary in ./lib/natural/stemmers/indonesian/prefix_rules.js and ./lib/natural/stemmers/indonesian/stemmer_id.js with:

function loadDictionary(){
    dictionary = dictionary.concat(require("./../../../../data/kata-dasar.json"));
}

As of node 0.5 there is a native loader for JSON. Might as well take advantage of that and not read file then split newlines over 30K lines, then trim each word (why are we trimming clean data?). Can take advantage of the native loader and JSON format to speed things up quite a bit. Napkin math benchmark tests showed a decrease in start time of about 600ms. This also makes the project work on docker -- presently read file sync (as is) is breaking in these environments like AWS SAM Local (aka AWS Lambda Emulator/Serverless).

Did some repairs to fix your issues with kata-dasar.txt:

Removed line 19362 with oper "v,"
Moved the file to lib/natural/stemmers/indonesian/data
Converted it to JSON
Made the stemmer work with the new JSON file in the new location

Will upload a new version to NPM soon.


Should we reduce Agda closure size by 4.4 GiB by unbundling libHSAgda.a and GHC?

With the standard library, cubical and categories, agdaWithPackages has a closure size of about 4.9 GiB (full closure info here):
$ nix path-info --size --closure-size --recursive /nix/store/jnniclsy557w9n0lnj8vdbpysagkfqsc-agdaWithPackages-<IP_ADDRESS>
[...]
/nix/store/jnniclsy557w9n0lnj8vdbpysagkfqsc-agdaWithPackages-<IP_ADDRESS> 1080<PHONE_NUMBER>

Among the larger culprits are 600 MiB of libHSAgda-[...].a and GHC itself.
Personally I'm using https://github.com/iblech/agdapad/blob/master/backend/slim-agda.nix where I zero out the dependence on GHC and just fetch the Agda binary. I've been using this for years and never encountered any problems.
Should we incorporate something like this in nixpkgs?

I currently have a number of parallel installations of Agda on my machines, and I'd like to see a reduction of closure size. I think there are two separate space hogs, each with diff

The Agda Haskell library.  The manual mentions two helpers to reduce closure size: justStaticExecutables (removes references to libraries and docs) and enableSeparateBinOutput (installs binaries in a separate bin output). I tried setting enableSeparateBinOutput, but it breaks agda-mode.See below
The ghc attribute passed to agda.withPackages: I don't use Agda's GHC backend, so I provide a "fake GHC" to reduce closure size:# Use with callPackage:
{
  agda,
  writeShellApplication,
}: let
  fake-ghc = writeShellApplication {
    name = "ghc";
    text = ''
      echo "Compiling Agda via GHC has been disabled" 1>&2
      exit 2
    '';
  };
in
agda.withPackages {
  pkgs = p: [
    p.standard-library
    p.cubical
  ];
  ghc = fake-ghc;
}

Maybe agda.withPackages could be changed so that agda.withPackages { ghc = null; } disables compilation via GCH. E.g. we could pass --with-compiler=<GHC stub> and --ghc-dont-call-ghc to the wrapped agda binary.

Applying enableSeparateBinOutput to haskellPackages.Agda and running nixpkgs-review results in the following output:
Result of nixpkgs-review run on x86_64-linux 1

2 packages marked as broken and skipped:

cedille
emacsPackages.cedille

1 package failed to build:

emacsPackages.agda2-mode

Build log of emacsPackages.agda2-mode
@nix { "action": "setPhase", "phase": "patchPhase" }
Running phase: patchPhase
@nix { "action": "setPhase", "phase": "updateAutotoolsGnuConfigScriptsPhase" }
Running phase: updateAutotoolsGnuConfigScriptsPhase
@nix { "action": "setPhase", "phase": "configurePhase" }
Running phase: configurePhase
no configure script, doing nothing
@nix { "action": "setPhase", "phase": "buildPhase" }
Running phase: buildPhase
/nix/store/v5lsd029lz5lfhamivbgqyp3zdv94ah2-stdenv-linux/setup: line 1578: /nix/store/4lni1yr0lcdylwlrv52cl1gn92sgnpsj-Agda-<IP_ADDRESS>/bin/agda-mode: No such file or directory


Fix issue where Marathon ports are not mapped correctly

The mapped.docker.port.XXXX sensors were not being populated, due to a delay in setting the location on entities.

fyi @neykov


Using ES6 def. values for React component gives type error

React defaultProps will be deprecated in future releases (see PR). Therefore I want to use es6 default values.

TypeScript Version:  3.7.0-dev.20190822

Search Terms:

Use es6 default values in React functional component instead of defaultProps

Code
The React component
import React from "react";

MyComponentProps {
  name: string;
}

export const MyComponent = ({
  name = "Jack"
}: MyComponentProps) => (

      Hello {name}

)

The place where I use it
import React from "react";
import { MyComponent } from "./components"

const MyApp = () => <MyComponent />

TS2741: Property 'name' is missing in type '{}' but required in type 'MyComponentProps'

Expected behavior:
No type error as the default value is already defined
Actual behavior:
Typescript says that property is missing.

You declared the property as required, so it's required. If you want the property to be optional, mark it optional:
interface MyComponentProps {
  name?: string;
}

TypeScript will understand that the name parameter is always not undefined in the body of the function.

Of course, that does make sense indeed. The strange thing however is that TypeScript doesn't complain when you use Component.defaultProps and leave the the name property in the interface required. That confused me.


Step 10 should be more descriptive to explain how renaming the public key certificate file of the private_key_jwt issuer can be done

Step 10 should be more descriptive to explain how renaming the public key certificate file of the private_key_jwt issuer can be done in this [1] doc step 10
[1] https://docs.wso2.com/display/IS550/Private+Key+JWT+Client+Authentication+for+OIDC

This issue is valid for IS5.5.0/Alpha3 as well need to fix this under step 11 in the current doc [1]
[1]. https://docs.wso2.com/display/IS550/Private+Key+JWT+Client+Authentication+for+OIDC

Updated the doc [1] with the command to rename.
[1] https://docs.wso2.com/display/IS550/Private+Key+JWT+Client+Authentication+for+OIDC