hello Daniel we have had another core
#0 0x00007fa0db0799b0 in ?? ()
#1 0x00007fa10d780741 in run_trans_callbacks_internal (cb_lst=0x7fa0b54752f0, type=131072, trans=0x7fa0b5475278, params=0x7ffdfb6b4d90) at t_hooks.c:258
#2 0x00007fa10d780871 in run_trans_callbacks (type=131072, trans=0x7fa0b5475278, req=0x0, rpl=0x0, code=0) at t_hooks.c:285
#3 0x00007fa10d72a79c in free_cell_helper (dead_cell=0x7fa0b5475278, silent=0, fname=0x7fa10d83bd72 "timer.c", fline=648) at h_table.c:165
#4 0x00007fa10d787036 in wait_handler (ti=1120415570, wait_tl=0x7fa0b5475300, data=0x7fa0b5475278) at timer.c:648
#5 0x000056079079f21a in timer_list_expire (t=1120415570, h=0x7fa08dc4b360, slow_l=0x7fa08dc4e2d8, slow_mark=45780) at core/timer.c:857
#6 0x000056079079f724 in timer_handler () at core/timer.c:922
#7 0x000056079079fc27 in timer_main () at core/timer.c:961
#8 0x00005607904e76cf in main_loop () at main.c:1839
#9 0x00005607904f22e9 in main (argc=15, argv=0x7ffdfb6b57d8) at main.c:3061
I saw that the process which had the SIGSEV was handling all cancel requests it seems.
Maybe this can be related with the memory management when releasing transactions?
thanks a lot and regards
david
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.