[jira] [Commented] (DISPATCH-994) segfault in qdr_link_second_attach
[ https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503610#comment-16503610 ] Ganesh Murthy commented on DISPATCH-994: Marking as Wont Fix as this problem was fixed in Proton > segfault in qdr_link_second_attach > -- > > Key: DISPATCH-994 > URL: https://issues.apache.org/jira/browse/DISPATCH-994 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Gordon Sim >Priority: Major > Attachments: router-a.conf, router-b.conf, router-c.conf, > topic_test.py, topic_test_v2.py > > > Link routing from router A through router B to a 'broker', and closing and > opening two receivers causes a segfault. > {noformat} > ==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 > {noformat} > To reproduce, start three routers with the attached config files, then run > the attached python test program. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-994) segfault in qdr_link_second_attach
[ https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16478091#comment-16478091 ] ASF GitHub Bot commented on DISPATCH-994: - Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/303 > segfault in qdr_link_second_attach > -- > > Key: DISPATCH-994 > URL: https://issues.apache.org/jira/browse/DISPATCH-994 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Gordon Sim >Priority: Major > Attachments: router-a.conf, router-b.conf, router-c.conf, > topic_test.py, topic_test_v2.py > > > Link routing from router A through router B to a 'broker', and closing and > opening two receivers causes a segfault. > {noformat} > ==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 > {noformat} > To reproduce, start three routers with the attached config files, then run > the attached python test program. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-994) segfault in qdr_link_second_attach
[ https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476363#comment-16476363 ] Gordon Sim commented on DISPATCH-994: - I think this is fixed by https://issues.apache.org/jira/browse/PROTON-1845 > segfault in qdr_link_second_attach > -- > > Key: DISPATCH-994 > URL: https://issues.apache.org/jira/browse/DISPATCH-994 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Gordon Sim >Priority: Major > Attachments: router-a.conf, router-b.conf, router-c.conf, > topic_test.py, topic_test_v2.py > > > Link routing from router A through router B to a 'broker', and closing and > opening two receivers causes a segfault. > {noformat} > ==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 > {noformat} > To reproduce, start three routers with the attached config files, then run > the attached python test program. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-994) segfault in qdr_link_second_attach
[ https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16474458#comment-16474458 ] Ganesh Murthy commented on DISPATCH-994: I removed the single session fix ([https://github.com/apache/qpid-dispatch/commit/d37b0eb092e617c2986393022bd7b0f245547498)] from master and tested this issue. Could not reproduce the crash or the stall. > segfault in qdr_link_second_attach > -- > > Key: DISPATCH-994 > URL: https://issues.apache.org/jira/browse/DISPATCH-994 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Gordon Sim >Priority: Major > Attachments: router-a.conf, router-b.conf, router-c.conf, > topic_test.py, topic_test_v2.py > > > Link routing from router A through router B to a 'broker', and closing and > opening two receivers causes a segfault. > {noformat} > ==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 > {noformat} > To reproduce, start three routers with the attached config files, then run > the attached python test program. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-994) segfault in qdr_link_second_attach
[ https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471162#comment-16471162 ] Gordon Sim commented on DISPATCH-994: - topic_test_v2 waits for the connections to close before resubscribing and thus could not be described as invalid. Its still exhibits similar symptoms. > segfault in qdr_link_second_attach > -- > > Key: DISPATCH-994 > URL: https://issues.apache.org/jira/browse/DISPATCH-994 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Gordon Sim >Priority: Major > Attachments: router-a.conf, router-b.conf, router-c.conf, > topic_test.py, topic_test_v2.py > > > Link routing from router A through router B to a 'broker', and closing and > opening two receivers causes a segfault. > {noformat} > ==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 > {noformat} > To reproduce, start three routers with the attached config files, then run > the attached python test program. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-994) segfault in qdr_link_second_attach
[ https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16471157#comment-16471157 ] Gordon Sim commented on DISPATCH-994: - Digging a little deeper, the issue here is the re-use of a link name on a session before the previous use has fully closed. The test case attached here is arguably incorrect, as it does not wait for the connection to be confirmed as closed before resubscribing with the same link names. However even a modified version that does so can cause the same problem. DISPATCH-997 is a different symptom of the same route cause, and the test there also waits for connection close before reusing. If router-c is run under valrgind, that too can trigger this segfault. The only way to avoid it would be for the application to wait for the link detach to be confirmed before closing the connection. That is not something that can be relied on. If the connection ends (cleanly or due to disconnect) before the link is closed, then the router will confirm the close of the connection before waiting for the detach it relays down the link route to be echoed back. If you get an attach with the same name before the detach for the previous use of that name has been echoed back, then the previous link is not fully closed (it is locally open, remotely closed), and when proton handles the attach it gives the previous object which is in the incorrect state. This either leads to the router incorrectly treating the attach as the echoing back of a router initiated link, which causes the segfault described in this issue due to correct context not being set up or it causes the attach to be ignored and not echoed back. The former happens when the detach is echoed back slowly, so running router c under valgrind makes it more likely. Fundamentally I think this is an issue in using the same session for all routed links, where the links are detached asynchronously. > segfault in qdr_link_second_attach > -- > > Key: DISPATCH-994 > URL: https://issues.apache.org/jira/browse/DISPATCH-994 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Gordon Sim >Priority: Major > Attachments: router-a.conf, router-b.conf, router-c.conf, > topic_test.py > > > Link routing from router A through router B to a 'broker', and closing and > opening two receivers causes a segfault. > {noformat} > ==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 > {noformat} > To reproduce, start three routers with the attached config files, then run > the attached python test program. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-994) segfault in qdr_link_second_attach
[ https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470593#comment-16470593 ] ASF GitHub Bot commented on DISPATCH-994: - Github user ganeshmurthy commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/303#discussion_r187373563 --- Diff: src/router_core/connections.c --- @@ -473,7 +474,8 @@ void qdr_link_second_attach(qdr_link_t *link, qdr_terminus_t *source, qdr_termin action->args.connection.link = link; action->args.connection.source = source; action->args.connection.target = target; -qdr_action_enqueue(link->core, action); +if (link) --- End diff -- I added the null check in AMQP_link_attach_handler and in qdr_link_second_attach() just to be doubly sure. > segfault in qdr_link_second_attach > -- > > Key: DISPATCH-994 > URL: https://issues.apache.org/jira/browse/DISPATCH-994 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Gordon Sim >Priority: Major > Attachments: router-a.conf, router-b.conf, router-c.conf, > topic_test.py > > > Link routing from router A through router B to a 'broker', and closing and > opening two receivers causes a segfault. > {noformat} > ==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 > {noformat} > To reproduce, start three routers with the attached config files, then run > the attached python test program. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-994) segfault in qdr_link_second_attach
[ https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470560#comment-16470560 ] ASF GitHub Bot commented on DISPATCH-994: - Github user grs commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/303#discussion_r187367734 --- Diff: src/router_core/connections.c --- @@ -473,7 +474,8 @@ void qdr_link_second_attach(qdr_link_t *link, qdr_terminus_t *source, qdr_termin action->args.connection.link = link; action->args.connection.source = source; action->args.connection.target = target; -qdr_action_enqueue(link->core, action); +if (link) --- End diff -- I wonder if the test might be better done in AMQP_link_attach_handler in router_node.c? That is the only place that calls the method, and is the one that retrieves the null context. > segfault in qdr_link_second_attach > -- > > Key: DISPATCH-994 > URL: https://issues.apache.org/jira/browse/DISPATCH-994 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Gordon Sim >Priority: Major > Attachments: router-a.conf, router-b.conf, router-c.conf, > topic_test.py > > > Link routing from router A through router B to a 'broker', and closing and > opening two receivers causes a segfault. > {noformat} > ==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 > {noformat} > To reproduce, start three routers with the attached config files, then run > the attached python test program. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-994) segfault in qdr_link_second_attach
[ https://issues.apache.org/jira/browse/DISPATCH-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16470441#comment-16470441 ] ASF GitHub Bot commented on DISPATCH-994: - GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/303 DISPATCH-994 - Added null checks on links/connections before enqueing… … actions or calling action inseting functions You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-994 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/303.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #303 commit ea4b67fdc1ccd2dfc52f096308174d3c26fba993 Author: Ganesh Murthy Date: 2018-05-10T14:20:50Z DISPATCH-994 - Added null checks on links/connections before enqueing actions or calling action inseting functions > segfault in qdr_link_second_attach > -- > > Key: DISPATCH-994 > URL: https://issues.apache.org/jira/browse/DISPATCH-994 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.1.0 >Reporter: Gordon Sim >Priority: Major > Attachments: router-a.conf, router-b.conf, router-c.conf, > topic_test.py > > > Link routing from router A through router B to a 'broker', and closing and > opening two receivers causes a segfault. > {noformat} > ==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 > {noformat} > To reproduce, start three routers with the attached config files, then run > the attached python test program. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org