Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.1.0
-
None
-
None
Description
Link routing from router A through router B to a 'broker', and closing and opening two receivers causes a segfault.
==25674== Thread 4: ==25674== Invalid read of size 8 ==25674== at 0x4E77EEF: qdr_link_second_attach (connections.c:474) ==25674== by 0x4E87142: AMQP_link_attach_handler (router_node.c:680) ==25674== by 0x4E8BF2B: handle (server.c:940) ==25674== by 0x4E8CBA7: thread_run (server.c:958) ==25674== by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so) ==25674== by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so) ==25674== Address 0x10 is not stack'd, malloc'd or (recently) free'd ==25674== ==25674== ==25674== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==25674== Access not within mapped region at address 0x10 ==25674== at 0x4E77EEF: qdr_link_second_attach (connections.c:474) ==25674== by 0x4E87142: AMQP_link_attach_handler (router_node.c:680) ==25674== by 0x4E8BF2B: handle (server.c:940) ==25674== by 0x4E8CBA7: thread_run (server.c:958) ==25674== by 0x54FA739: start_thread (in /usr/lib64/libpthread-2.24.so) ==25674== by 0x6288E7E: clone (in /usr/lib64/libc-2.24.so) ==25674== If you believe this happened as a result of a stack ==25674== overflow in your program's main thread (unlikely but ==25674== possible), you can try to increase the size of the ==25674== main thread stack using the --main-stacksize= flag. ==25674== The main thread stack size used in this run was 8388608
To reproduce, start three routers with the attached config files, then run the attached python test program.
Attachments
Attachments
Issue Links
- is caused by
-
PROTON-1845 [c] Treat attach received after detach as implying new link
- Closed
- links to