[jira] [Commented] (QPIDJMS-525) Update Netty to 4.1.60.Final
[ https://issues.apache.org/jira/browse/QPIDJMS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306741#comment-17306741 ] ASF subversion and git services commented on QPIDJMS-525: - Commit 06e1872a24ef496cbb64723f896a6dfaab4f8eb7 in qpid-jms's branch refs/heads/main from Robbie Gemmell [ https://gitbox.apache.org/repos/asf?p=qpid-jms.git;h=06e1872 ] QPIDJMS-525: update to Netty 4.1.59.Final (and netty-tcnative test dep to 2.0.36) > Update Netty to 4.1.60.Final > > > Key: QPIDJMS-525 > URL: https://issues.apache.org/jira/browse/QPIDJMS-525 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.56.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 0.57.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-525) Update Netty to 4.1.60.Final
[ https://issues.apache.org/jira/browse/QPIDJMS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306742#comment-17306742 ] ASF subversion and git services commented on QPIDJMS-525: - Commit db49d1c15500a185088fe97cf76e483fa05e6f9a in qpid-jms's branch refs/heads/main from Robbie Gemmell [ https://gitbox.apache.org/repos/asf?p=qpid-jms.git;h=db49d1c ] QPIDJMS-525: update to Netty 4.1.60 > Update Netty to 4.1.60.Final > > > Key: QPIDJMS-525 > URL: https://issues.apache.org/jira/browse/QPIDJMS-525 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.56.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 0.57.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-298) Use online service to manage and display coverage reports
[ https://issues.apache.org/jira/browse/QPIDJMS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306745#comment-17306745 ] ASF GitHub Bot commented on QPIDJMS-298: clambertus closed pull request #8: URL: https://github.com/apache/qpid-jms/pull/8 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Use online service to manage and display coverage reports > - > > Key: QPIDJMS-298 > URL: https://issues.apache.org/jira/browse/QPIDJMS-298 > Project: Qpid JMS > Issue Type: Wish > Components: qpid-jms-client, qpid-jms-discovery >Affects Versions: 0.24.0 >Reporter: Jiri Daněk >Priority: Minor > > There are multiple coverage monitoring online services that integrate with > popular CI services, like TravisCI. > I propose uploading coverage report from run in TravisCI to some coverage > monitoring service. This way, test coverage will become more visible. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-447) Make Source.setDurable available
[
https://issues.apache.org/jira/browse/QPIDJMS-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306744#comment-17306744
]
ASF GitHub Bot commented on QPIDJMS-447:
clambertus closed pull request #28:
URL: https://github.com/apache/qpid-jms/pull/28
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Make Source.setDurable available
> -
>
> Key: QPIDJMS-447
> URL: https://issues.apache.org/jira/browse/QPIDJMS-447
> Project: Qpid JMS
> Issue Type: Improvement
> Components: qpid-jms-client
>Affects Versions: 0.39.0, 0.40.0
> Environment: Broker: RabbitMQ 3.7.5 with amqpv1 plugin
> Client: QPID-JMS 0.39, 0.40
>
>Reporter: Thomas Stollenwerk
>Priority: Major
> Original Estimate: 6h
> Remaining Estimate: 6h
>
> Right now it is not possible to set the "durable" field of an amqp "target"
> by QPID-JMS
> [http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-terminus-durability]
> We are using RabbitMQ 3.7.5 with it's amqp v1.0 plugin. Without this option
> it's not possible to produce messages to a durable queue using QPID-JMS.
> Attaching to a durable queue results in:
> {{
> {'v1_0.error',\\{symbol,<<"amqp:precondition-failed">>}
> ,{utf8,<<"PRECONDITION_FAILED - inequivalent arg 'durable' for queue 'HOST'
> in vhost '/': {color:#ff}received 'false' but current is
> 'true'{color}">>},undefined}}}
> {{Using qpid or amqpnetlite with durable = *TerminusDurability.CONFIGURATION*
> (1) works fine.}}
>
> *AmqpProducerBuilder.createEndpoint* should set the *Source.setDurable*
> option like
> *AmqpConsumerBuilder.configureSource* does. Maybe by adding *setDurable* to
> *JmsDestination* passed to *JmsProducerInfo*.
>
> Setting it to "false" by default should not break any existing
> implementations.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-526) fire ExceptionListener if consumer exists with MessageListener on remotely-closed Session
[ https://issues.apache.org/jira/browse/QPIDJMS-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306743#comment-17306743 ] ASF subversion and git services commented on QPIDJMS-526: - Commit 44b73fc591cc2b3907d6b5ee3416f9eec9b56e28 in qpid-jms's branch refs/heads/main from Robbie Gemmell [ https://gitbox.apache.org/repos/asf?p=qpid-jms.git;h=44b73fc ] QPIDJMS-526: fire the ExceptionListener when handling remote Session closure if it has a consumer with a MessageListener > fire ExceptionListener if consumer exists with MessageListener on > remotely-closed Session > - > > Key: QPIDJMS-526 > URL: https://issues.apache.org/jira/browse/QPIDJMS-526 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.56.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 0.57.0 > > > We fire the ExceptionListener when a consumer is remotely-closed that has a > MessageListener, since the lack of new messages arriving to produce activity > could mean the application then never interacts with with the consumer object > and discover the closure. The same should occur (thought it already did..) > when a Session is remotely-closed whilst having a consumer with > MessageListener, as the application may similarly then not interact with the > session/consumer objects and discover the closure due to lack of message > delivery activity. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-525) Update Netty to 4.1.60.Final
[ https://issues.apache.org/jira/browse/QPIDJMS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306740#comment-17306740 ] ASF subversion and git services commented on QPIDJMS-525: - Commit 8cd7093b9abea0cd4c4dee31931cb096b73a03fa in qpid-jms's branch refs/heads/main from Timothy Bish [ https://gitbox.apache.org/repos/asf?p=qpid-jms.git;h=8cd7093 ] QPIDJMS-525 Update to latest netty release 4.1.56.Final > Update Netty to 4.1.60.Final > > > Key: QPIDJMS-525 > URL: https://issues.apache.org/jira/browse/QPIDJMS-525 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.56.0 >Reporter: Timothy A. Bish >Assignee: Timothy A. Bish >Priority: Major > Fix For: 0.57.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-jms] clambertus closed pull request #28: QPIDJMS-447 MessageProducer support for target.durable
clambertus closed pull request #28: URL: https://github.com/apache/qpid-jms/pull/28 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-jms] clambertus closed pull request #8: QPIDJMS-298 Add coverage report uploading to codecov.io in .travis.yml
clambertus closed pull request #8: URL: https://github.com/apache/qpid-jms/pull/8 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-2013) Http1AdaptorManagementTest fails with AssertionError: 0 != 1 : HTTP connection not deleted
[
https://issues.apache.org/jira/browse/DISPATCH-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk updated DISPATCH-2013:
-
Component/s: Tests
> Http1AdaptorManagementTest fails with AssertionError: 0 != 1 : HTTP
> connection not deleted
> --
>
> Key: DISPATCH-2013
> URL: https://issues.apache.org/jira/browse/DISPATCH-2013
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors, Tests
>Affects Versions: 1.16.0
>Reporter: Jiri Daněk
>Priority: Major
>
> #
> https://github.com/jiridanek/qpid-dispatch/runs/2166630124?check_suite_focus=true#step:9:2035
> This is a PR build, not master. I remember seeing the same issue once before,
> though. I'll make note of it here, in case it reappears again.
> {noformat}
> 71: Trigger Q2 backpressure against the HTTP server. ... ok
> 71:
> 71: ==
> 71: FAIL: test_01_mgmt (system_tests_http1_adaptor.Http1AdaptorManagementTest)
> 71: Create and delete HTTP1 connectors and listeners
> 71: --
> 71: Traceback (most recent call last):
> 71: File
> "/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/system_tests_http1_adaptor.py",
> line 464, in test_01_mgmt
> 71: self.assertEqual(0, hconns, msg="HTTP connection not deleted")
> 71: AssertionError: 0 != 1 : HTTP connection not deleted
> 71:
> 71: --
> 71: Ran 20 tests in 80.903s
> 71:
> 71: FAILED (failures=1)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1962) Make LSan suppressions more targeted and specific (within reason)
[
https://issues.apache.org/jira/browse/DISPATCH-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306593#comment-17306593
]
ASF subversion and git services commented on DISPATCH-1962:
---
Commit 9262f7a801c493dacf220b2d52e9da4a2d59e53c in qpid-dispatch's branch
refs/heads/master from Jiri Daněk
[ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=9262f7a ]
DISPATCH-1962 Fix leak from libwebsockets.so in unit_tests (#1080)
> Make LSan suppressions more targeted and specific (within reason)
> -
>
> Key: DISPATCH-1962
> URL: https://issues.apache.org/jira/browse/DISPATCH-1962
> Project: Qpid Dispatch
> Issue Type: Test
>Affects Versions: 1.15.0
>Reporter: Jiri Daněk
>Priority: Major
> Attachments: dispatch_leaking_agent.png
>
>
> There are some unfortunate suppressions in {{tests/lsan.supp}} at this moment:
> {code}
> leak:*libwebsockets*
> {code}
> This is way too broad. It suppresses leaks in Dispatch files, since it
> matches e.g. {{src/http-libwebsockets.c}}.
> The stars at the beginning and end are actually assumed implicitly. If you do
> not want substring match, you have to do ^foo$. LSan suppression format is
> simplistic, very unlike Valgrind's.
> {code}
> leak:run_unit_tests.c
> {code}
> Same thing, any leaks revealed by running unit_tests get suppressed. This
> suppression suppresses all leak traces that include run_unit_tests.c anywhere
> in the stack. What't the point of running such tests under leak detector,
> then?
> {code}
> leak:run_unit_tests.c
> leak:^libqpid-proton.so$
> {code}
> Same thing. The patterns suppress all leaks that include Python (or Proton)
> anywhere in the stacktrace. That means there are huge blind spots where
> dispatch leaks can hide. This is a weakness of the lsan.supp syntax (Valgrind
> suppressions can be much more targeted and discerning).
> h3. Python leaks
> Leaks are known and there is ongoing effort to fight them:
> https://bugs.python.org/issue1635741 (https://bugs.python.org/issue25302) and
> https://www.python.org/dev/peps/pep-3121
> Here's valgrind suppression file from somebody who actually investigated the
> Python leaks and identified the harmless ones:
> https://github.com/libgit2/pygit2/blob/master/misc/valgrind-python.supp
> One example of a hidden leak in dispatch, which is revealed by making Python
> suppressions more targetted:
> {code}
> 9: Direct leak of 56 byte(s) in 1 object(s) allocated from:
> 9: #0 0x7f78a3606e8f in __interceptor_malloc
> (/nix/store/g40sl3zh3nv52vj0mrl4iki5iphh5ika-gcc-10.2.0-lib/lib/libasan.so.6+0xace8f)
> 9: #1 0x7f78a2d64afb in qd_malloc ../include/qpid/dispatch/ctools.h:229
> 9: #2 0x7f78a2d657da in qdr_core_subscribe
> ../src/router_core/route_tables.c:149
> 9: #3 0x7f78a2c83072 in IoAdapter_init ../src/python_embedded.c:711
> 9: #4 0x7f78a2353a6c in type_call
> (/nix/store/r85nxfnwiv45nbmf5yb60jj8ajim4m7w-python3-3.8.5/lib/libpython3.8.so.1.0+0x165a6c)
> {code}
> The problem is in
> {code}
> class Agent:
> ...
> def activate(self, address):
> ...
> self.io = IoAdapter(self.receive, address, 'L', '0',
> TREATMENT_ANYCAST_CLOSEST)
> {code}
> IoAdapter refers to Agent (through the bound method reference self.receive)
> and Agent refers to IoAdapter (through property self.io). Since IoAdapter is
> implemented in C and does not implement support for Python's cyclic GC, there
> is no way to break the cycle.
> Heap dump in attachment. The bound method is at the top of the picture.
> (Ignore the Mock objects, I was trying to simplify the picture while not
> getting crashes due to too much meddling).
> h3. Random observations
> It is possible to build special Debug build of Python, which has tools to
> detect leaks, asserts to prevent negative refcounts, etc.
> https://pythonextensionpatterns.readthedocs.io/en/latest/debugging/debug_python.html#debug-version-of-python-memory-alloc-label
> Use the following to detect python leaks (instead of valgrind)
> https://docs.python.org/3/library/tracemalloc.html
> Use https://pypi.org/project/objgraph (with graphviz) to view heap object
> trees. The following renders the picture as a png under /tmp and prints the
> path to stdout.
> {code}
> int ret = PyRun_SimpleString("import objgraph;
> objgraph.show_backrefs(config.global_agent, max_depth=10)\n\n");
> PyErr_PrintEx(0);
> assert(ret == 0);
> {code}
> h2. Tools
> h3. CPyChecker
> https://dmalcolm.fedorapeople.org/presentations/PyCon-US-2013/PyCon-US-2013-dmalcolm-StaticAnalysis.html#(38)
> https://emptysqua.re/blog/analyzing-python-c-extensions-with-cpychecker/
> https://nedbatchelder.com/blog/201502/cpychecker.html
> h3. Pungi
> http://www.cse.psu.edu/~gxt29/papers/refcount.pdf
> h3. Use CFFI or similar,
[jira] [Commented] (DISPATCH-1962) Make LSan suppressions more targeted and specific (within reason)
[
https://issues.apache.org/jira/browse/DISPATCH-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306594#comment-17306594
]
ASF GitHub Bot commented on DISPATCH-1962:
--
jiridanek merged pull request #1080:
URL: https://github.com/apache/qpid-dispatch/pull/1080
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Make LSan suppressions more targeted and specific (within reason)
> -
>
> Key: DISPATCH-1962
> URL: https://issues.apache.org/jira/browse/DISPATCH-1962
> Project: Qpid Dispatch
> Issue Type: Test
>Affects Versions: 1.15.0
>Reporter: Jiri Daněk
>Priority: Major
> Attachments: dispatch_leaking_agent.png
>
>
> There are some unfortunate suppressions in {{tests/lsan.supp}} at this moment:
> {code}
> leak:*libwebsockets*
> {code}
> This is way too broad. It suppresses leaks in Dispatch files, since it
> matches e.g. {{src/http-libwebsockets.c}}.
> The stars at the beginning and end are actually assumed implicitly. If you do
> not want substring match, you have to do ^foo$. LSan suppression format is
> simplistic, very unlike Valgrind's.
> {code}
> leak:run_unit_tests.c
> {code}
> Same thing, any leaks revealed by running unit_tests get suppressed. This
> suppression suppresses all leak traces that include run_unit_tests.c anywhere
> in the stack. What't the point of running such tests under leak detector,
> then?
> {code}
> leak:run_unit_tests.c
> leak:^libqpid-proton.so$
> {code}
> Same thing. The patterns suppress all leaks that include Python (or Proton)
> anywhere in the stacktrace. That means there are huge blind spots where
> dispatch leaks can hide. This is a weakness of the lsan.supp syntax (Valgrind
> suppressions can be much more targeted and discerning).
> h3. Python leaks
> Leaks are known and there is ongoing effort to fight them:
> https://bugs.python.org/issue1635741 (https://bugs.python.org/issue25302) and
> https://www.python.org/dev/peps/pep-3121
> Here's valgrind suppression file from somebody who actually investigated the
> Python leaks and identified the harmless ones:
> https://github.com/libgit2/pygit2/blob/master/misc/valgrind-python.supp
> One example of a hidden leak in dispatch, which is revealed by making Python
> suppressions more targetted:
> {code}
> 9: Direct leak of 56 byte(s) in 1 object(s) allocated from:
> 9: #0 0x7f78a3606e8f in __interceptor_malloc
> (/nix/store/g40sl3zh3nv52vj0mrl4iki5iphh5ika-gcc-10.2.0-lib/lib/libasan.so.6+0xace8f)
> 9: #1 0x7f78a2d64afb in qd_malloc ../include/qpid/dispatch/ctools.h:229
> 9: #2 0x7f78a2d657da in qdr_core_subscribe
> ../src/router_core/route_tables.c:149
> 9: #3 0x7f78a2c83072 in IoAdapter_init ../src/python_embedded.c:711
> 9: #4 0x7f78a2353a6c in type_call
> (/nix/store/r85nxfnwiv45nbmf5yb60jj8ajim4m7w-python3-3.8.5/lib/libpython3.8.so.1.0+0x165a6c)
> {code}
> The problem is in
> {code}
> class Agent:
> ...
> def activate(self, address):
> ...
> self.io = IoAdapter(self.receive, address, 'L', '0',
> TREATMENT_ANYCAST_CLOSEST)
> {code}
> IoAdapter refers to Agent (through the bound method reference self.receive)
> and Agent refers to IoAdapter (through property self.io). Since IoAdapter is
> implemented in C and does not implement support for Python's cyclic GC, there
> is no way to break the cycle.
> Heap dump in attachment. The bound method is at the top of the picture.
> (Ignore the Mock objects, I was trying to simplify the picture while not
> getting crashes due to too much meddling).
> h3. Random observations
> It is possible to build special Debug build of Python, which has tools to
> detect leaks, asserts to prevent negative refcounts, etc.
> https://pythonextensionpatterns.readthedocs.io/en/latest/debugging/debug_python.html#debug-version-of-python-memory-alloc-label
> Use the following to detect python leaks (instead of valgrind)
> https://docs.python.org/3/library/tracemalloc.html
> Use https://pypi.org/project/objgraph (with graphviz) to view heap object
> trees. The following renders the picture as a png under /tmp and prints the
> path to stdout.
> {code}
> int ret = PyRun_SimpleString("import objgraph;
> objgraph.show_backrefs(config.global_agent, max_depth=10)\n\n");
> PyErr_PrintEx(0);
> assert(ret == 0);
> {code}
> h2. Tools
> h3. CPyChecker
> https://dmalcolm.fedorapeople.org/presentations/PyCon-US-2013/PyCon-US-2013-dmalcolm-StaticAnalysis.html#(38)
> https://emptysqua.re/blog/analyzing-python-c-extensions-with-cpychecker/
> https://nedbatchelder.com/blog/201502/cpychecker.html
> h3. Pungi
>
[GitHub] [qpid-dispatch] jiridanek merged pull request #1080: DISPATCH-1962 Fix leak from libwebsockets.so in unit_tests
jiridanek merged pull request #1080: URL: https://github.com/apache/qpid-dispatch/pull/1080 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1962) Make LSan suppressions more targeted and specific (within reason)
[
https://issues.apache.org/jira/browse/DISPATCH-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306570#comment-17306570
]
ASF GitHub Bot commented on DISPATCH-1962:
--
jiridanek commented on pull request #1080:
URL: https://github.com/apache/qpid-dispatch/pull/1080#issuecomment-804388302
It is possible to get https://issues.apache.org/jira/browse/DISPATCH-2013
_Http1AdaptorManagementTest fails with AssertionError: 0 != 1 : HTTP connection
not deleted_ with this PR. It looks to me that it's a flaky failure not caused
by the PR. I am rerunning GHA tests, just to get another datapoint.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Make LSan suppressions more targeted and specific (within reason)
> -
>
> Key: DISPATCH-1962
> URL: https://issues.apache.org/jira/browse/DISPATCH-1962
> Project: Qpid Dispatch
> Issue Type: Test
>Affects Versions: 1.15.0
>Reporter: Jiri Daněk
>Priority: Major
> Attachments: dispatch_leaking_agent.png
>
>
> There are some unfortunate suppressions in {{tests/lsan.supp}} at this moment:
> {code}
> leak:*libwebsockets*
> {code}
> This is way too broad. It suppresses leaks in Dispatch files, since it
> matches e.g. {{src/http-libwebsockets.c}}.
> The stars at the beginning and end are actually assumed implicitly. If you do
> not want substring match, you have to do ^foo$. LSan suppression format is
> simplistic, very unlike Valgrind's.
> {code}
> leak:run_unit_tests.c
> {code}
> Same thing, any leaks revealed by running unit_tests get suppressed. This
> suppression suppresses all leak traces that include run_unit_tests.c anywhere
> in the stack. What't the point of running such tests under leak detector,
> then?
> {code}
> leak:run_unit_tests.c
> leak:^libqpid-proton.so$
> {code}
> Same thing. The patterns suppress all leaks that include Python (or Proton)
> anywhere in the stacktrace. That means there are huge blind spots where
> dispatch leaks can hide. This is a weakness of the lsan.supp syntax (Valgrind
> suppressions can be much more targeted and discerning).
> h3. Python leaks
> Leaks are known and there is ongoing effort to fight them:
> https://bugs.python.org/issue1635741 (https://bugs.python.org/issue25302) and
> https://www.python.org/dev/peps/pep-3121
> Here's valgrind suppression file from somebody who actually investigated the
> Python leaks and identified the harmless ones:
> https://github.com/libgit2/pygit2/blob/master/misc/valgrind-python.supp
> One example of a hidden leak in dispatch, which is revealed by making Python
> suppressions more targetted:
> {code}
> 9: Direct leak of 56 byte(s) in 1 object(s) allocated from:
> 9: #0 0x7f78a3606e8f in __interceptor_malloc
> (/nix/store/g40sl3zh3nv52vj0mrl4iki5iphh5ika-gcc-10.2.0-lib/lib/libasan.so.6+0xace8f)
> 9: #1 0x7f78a2d64afb in qd_malloc ../include/qpid/dispatch/ctools.h:229
> 9: #2 0x7f78a2d657da in qdr_core_subscribe
> ../src/router_core/route_tables.c:149
> 9: #3 0x7f78a2c83072 in IoAdapter_init ../src/python_embedded.c:711
> 9: #4 0x7f78a2353a6c in type_call
> (/nix/store/r85nxfnwiv45nbmf5yb60jj8ajim4m7w-python3-3.8.5/lib/libpython3.8.so.1.0+0x165a6c)
> {code}
> The problem is in
> {code}
> class Agent:
> ...
> def activate(self, address):
> ...
> self.io = IoAdapter(self.receive, address, 'L', '0',
> TREATMENT_ANYCAST_CLOSEST)
> {code}
> IoAdapter refers to Agent (through the bound method reference self.receive)
> and Agent refers to IoAdapter (through property self.io). Since IoAdapter is
> implemented in C and does not implement support for Python's cyclic GC, there
> is no way to break the cycle.
> Heap dump in attachment. The bound method is at the top of the picture.
> (Ignore the Mock objects, I was trying to simplify the picture while not
> getting crashes due to too much meddling).
> h3. Random observations
> It is possible to build special Debug build of Python, which has tools to
> detect leaks, asserts to prevent negative refcounts, etc.
> https://pythonextensionpatterns.readthedocs.io/en/latest/debugging/debug_python.html#debug-version-of-python-memory-alloc-label
> Use the following to detect python leaks (instead of valgrind)
> https://docs.python.org/3/library/tracemalloc.html
> Use https://pypi.org/project/objgraph (with graphviz) to view heap object
> trees. The following renders the picture as a png under /tmp and prints the
> path to stdout.
> {code}
> int ret = PyRun_SimpleString("import objgraph;
> objgraph.show_backrefs(config.global_agent, max_depth=10)\n\n");
>
[GitHub] [qpid-dispatch] jiridanek commented on pull request #1080: DISPATCH-1962 Fix leak from libwebsockets.so in unit_tests
jiridanek commented on pull request #1080: URL: https://github.com/apache/qpid-dispatch/pull/1080#issuecomment-804388302 It is possible to get https://issues.apache.org/jira/browse/DISPATCH-2013 _Http1AdaptorManagementTest fails with AssertionError: 0 != 1 : HTTP connection not deleted_ with this PR. It looks to me that it's a flaky failure not caused by the PR. I am rerunning GHA tests, just to get another datapoint. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2346) Build failure on musl
[
https://issues.apache.org/jira/browse/PROTON-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306561#comment-17306561
]
Jiri Daněk commented on PROTON-2346:
Related mailing list discussion (two links to the same thread). Same issue
manifests on Alpine Linux:
#
http://qpid.2158936.n2.nabble.com/Compiling-proton-c-for-Linux-Alpine-td7669810.html
#
http://mail-archives.apache.org/mod_mbox/qpid-users/201711.mbox/%3c1901279767.3407823.1511197861...@mail.yahoo.com%3e
> Build failure on musl
> -
>
> Key: PROTON-2346
> URL: https://issues.apache.org/jira/browse/PROTON-2346
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.33.0
> Environment: Linux
>Reporter: Fabrice Fontaine
>Priority: Major
> Attachments:
> 0001-c-src-proactor-epoll-internal.h-fix-build-on-musl.patch
>
>
> Build with epoll proactor on musl is broken since at least version 0.23.0 and
> https://github.com/apache/qpid-proton/commit/37136940e3077f25ce58c94775f48c66f666f4a8
> because musl does not define PTHREAD_MUTEX_ADAPTIVE_NP resulting in the
> following build failure:
> {code:java}
> In file included from
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/qpid-proton-0.33.0/c/src/proactor/epoll.c:60:
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/qpid-proton-0.33.0/c/src/proactor/epoll-internal.h:
> In function 'pmutex_init':
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/qpid-proton-0.33.0/c/src/proactor/epoll-internal.h:319:36:
> error: 'PTHREAD_MUTEX_ADAPTIVE_NP' undeclared (first use in this function);
> did you mean 'PTHREAD_MUTEX_STALLED'?
> 319 | pthread_mutexattr_settype(, PTHREAD_MUTEX_ADAPTIVE_NP);
> | ^
> | PTHREAD_MUTEX_STALLED{code}
> Fixes:
> -
> http://autobuild.buildroot.org/results/6a901b9ff68b7f52cabf8273d1017025fbd93b0d
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1965) Dispatch does not compile with gcc 10 when -Og is used
[
https://issues.apache.org/jira/browse/DISPATCH-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk resolved DISPATCH-1965.
--
Fix Version/s: 1.16.0
Resolution: Fixed
It did! Thanks for noticing.
> Dispatch does not compile with gcc 10 when -Og is used
> --
>
> Key: DISPATCH-1965
> URL: https://issues.apache.org/jira/browse/DISPATCH-1965
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Jiri Daněk
>Priority: Minor
> Fix For: 1.16.0
>
>
> {code}
> [23/116] Building C object src/CMakeFiles/qpid-dispatch.dir/hash.c.o
> FAILED: src/CMakeFiles/qpid-dispatch.dir/hash.c.o
> /nix/store/6h5455lvpkzksi2mz8h7cc85nxl9ln3z-gcc-wrapper-10.2.0/bin/cc
> -D_DEBUG -Dqpid_dispatch_EXPORTS -I../include -Iinclude
> -I/home/jdanek/repos/qpid/qpid-proton/build/install/include
> -I/nix/store/0yhk4sk4x9s9hsrf3p1skbfy1pwd1rbf-python3-3.8.5/include/python3.8
> -I../src -I../src/router_core -Isrc -Og -DQD_MEMORY_DEBUG -g
> -fno-omit-frame-pointer -fsanitize=address,undefined -std=gnu99 -g -fPIC
> -Werror -Wall -Wpedantic -MD -MT src/CMakeFiles/qpid-dispatch.dir/hash.c.o
> -MF src/CMakeFiles/qpid-dispatch.dir/hash.c.o.d -o
> src/CMakeFiles/qpid-dispatch.dir/hash.c.o -c ../src/hash.c
> ../src/hash.c: In function ���qd_hash_retrieve_prefix���:
> ../src/hash.c:303:17: error: ���item��� may be used uninitialized in this
> function [-Werror=maybe-uninitialized]
> 303 | *val = item->v.val;
> | ~~~^~~~
> ../src/hash.c: In function ���qd_hash_retrieve_prefix_const���:
> ../src/hash.c:327:23: error: ���item��� may be used uninitialized in this
> function [-Werror=maybe-uninitialized]
> 327 | *val = item->v.val_const;
> | ~~~^~
> cc1: all warnings being treated as errors
> [32/116] Building C object src/CMakeFiles/qpid-dispatch.dir/message.c.o
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2346) Build failure on musl
[
https://issues.apache.org/jira/browse/PROTON-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306555#comment-17306555
]
ASF GitHub Bot commented on PROTON-2346:
jiridanek commented on pull request #300:
URL: https://github.com/apache/qpid-proton/pull/300#issuecomment-804369264
I'm adding an explanatory comment (about this being a mere performance
hint). I could try to write benchmark for this. From what I saw, it's supposed
to help when there are short critical sections...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Build failure on musl
> -
>
> Key: PROTON-2346
> URL: https://issues.apache.org/jira/browse/PROTON-2346
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.33.0
> Environment: Linux
>Reporter: Fabrice Fontaine
>Priority: Major
> Attachments:
> 0001-c-src-proactor-epoll-internal.h-fix-build-on-musl.patch
>
>
> Build with epoll proactor on musl is broken since at least version 0.23.0 and
> https://github.com/apache/qpid-proton/commit/37136940e3077f25ce58c94775f48c66f666f4a8
> because musl does not define PTHREAD_MUTEX_ADAPTIVE_NP resulting in the
> following build failure:
> {code:java}
> In file included from
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/qpid-proton-0.33.0/c/src/proactor/epoll.c:60:
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/qpid-proton-0.33.0/c/src/proactor/epoll-internal.h:
> In function 'pmutex_init':
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/qpid-proton-0.33.0/c/src/proactor/epoll-internal.h:319:36:
> error: 'PTHREAD_MUTEX_ADAPTIVE_NP' undeclared (first use in this function);
> did you mean 'PTHREAD_MUTEX_STALLED'?
> 319 | pthread_mutexattr_settype(, PTHREAD_MUTEX_ADAPTIVE_NP);
> | ^
> | PTHREAD_MUTEX_STALLED{code}
> Fixes:
> -
> http://autobuild.buildroot.org/results/6a901b9ff68b7f52cabf8273d1017025fbd93b0d
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jiridanek commented on pull request #300: PROTON-2346: c/src/proactor/epoll-internal.h: fix build on musl
jiridanek commented on pull request #300: URL: https://github.com/apache/qpid-proton/pull/300#issuecomment-804369264 I'm adding an explanatory comment (about this being a mere performance hint). I could try to write benchmark for this. From what I saw, it's supposed to help when there are short critical sections... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2346) Build failure on musl
[
https://issues.apache.org/jira/browse/PROTON-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306554#comment-17306554
]
ASF GitHub Bot commented on PROTON-2346:
jiridanek commented on a change in pull request #300:
URL: https://github.com/apache/qpid-proton/pull/300#discussion_r599047291
##
File path: c/src/proactor/epoll-internal.h
##
@@ -315,7 +315,9 @@ static inline void pmutex_init(pthread_mutex_t *pm){
pthread_mutexattr_t attr;
pthread_mutexattr_init();
+#ifdef PTHREAD_MUTEX_ADAPTIVE_NP
Review comment:
```suggestion
// PROTON-2346: Some stdlibs (e.g., musl) don't implement
PTHREAD_MUTEX_ADAPTIVE_NP
// Since this option is a performance hint, it should be harmless to drop
it when it's not available.
#ifdef PTHREAD_MUTEX_ADAPTIVE_NP
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Build failure on musl
> -
>
> Key: PROTON-2346
> URL: https://issues.apache.org/jira/browse/PROTON-2346
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.33.0
> Environment: Linux
>Reporter: Fabrice Fontaine
>Priority: Major
> Attachments:
> 0001-c-src-proactor-epoll-internal.h-fix-build-on-musl.patch
>
>
> Build with epoll proactor on musl is broken since at least version 0.23.0 and
> https://github.com/apache/qpid-proton/commit/37136940e3077f25ce58c94775f48c66f666f4a8
> because musl does not define PTHREAD_MUTEX_ADAPTIVE_NP resulting in the
> following build failure:
> {code:java}
> In file included from
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/qpid-proton-0.33.0/c/src/proactor/epoll.c:60:
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/qpid-proton-0.33.0/c/src/proactor/epoll-internal.h:
> In function 'pmutex_init':
> /home/giuliobenetti/autobuild/run/instance-0/output-1/build/qpid-proton-0.33.0/c/src/proactor/epoll-internal.h:319:36:
> error: 'PTHREAD_MUTEX_ADAPTIVE_NP' undeclared (first use in this function);
> did you mean 'PTHREAD_MUTEX_STALLED'?
> 319 | pthread_mutexattr_settype(, PTHREAD_MUTEX_ADAPTIVE_NP);
> | ^
> | PTHREAD_MUTEX_STALLED{code}
> Fixes:
> -
> http://autobuild.buildroot.org/results/6a901b9ff68b7f52cabf8273d1017025fbd93b0d
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jiridanek commented on a change in pull request #300: PROTON-2346: c/src/proactor/epoll-internal.h: fix build on musl
jiridanek commented on a change in pull request #300:
URL: https://github.com/apache/qpid-proton/pull/300#discussion_r599047291
##
File path: c/src/proactor/epoll-internal.h
##
@@ -315,7 +315,9 @@ static inline void pmutex_init(pthread_mutex_t *pm){
pthread_mutexattr_t attr;
pthread_mutexattr_init();
+#ifdef PTHREAD_MUTEX_ADAPTIVE_NP
Review comment:
```suggestion
// PROTON-2346: Some stdlibs (e.g., musl) don't implement
PTHREAD_MUTEX_ADAPTIVE_NP
// Since this option is a performance hint, it should be harmless to drop
it when it's not available.
#ifdef PTHREAD_MUTEX_ADAPTIVE_NP
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1965) Dispatch does not compile with gcc 10 when -Og is used
[
https://issues.apache.org/jira/browse/DISPATCH-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306550#comment-17306550
]
Ganesh Murthy commented on DISPATCH-1965:
-
I wonder if the fix to DISPATCH-1660
(https://github.com/apache/qpid-dispatch/commit/1625d831354384c085d288dfaf9a0d116c626d3a)
fixed this issue
> Dispatch does not compile with gcc 10 when -Og is used
> --
>
> Key: DISPATCH-1965
> URL: https://issues.apache.org/jira/browse/DISPATCH-1965
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> {code}
> [23/116] Building C object src/CMakeFiles/qpid-dispatch.dir/hash.c.o
> FAILED: src/CMakeFiles/qpid-dispatch.dir/hash.c.o
> /nix/store/6h5455lvpkzksi2mz8h7cc85nxl9ln3z-gcc-wrapper-10.2.0/bin/cc
> -D_DEBUG -Dqpid_dispatch_EXPORTS -I../include -Iinclude
> -I/home/jdanek/repos/qpid/qpid-proton/build/install/include
> -I/nix/store/0yhk4sk4x9s9hsrf3p1skbfy1pwd1rbf-python3-3.8.5/include/python3.8
> -I../src -I../src/router_core -Isrc -Og -DQD_MEMORY_DEBUG -g
> -fno-omit-frame-pointer -fsanitize=address,undefined -std=gnu99 -g -fPIC
> -Werror -Wall -Wpedantic -MD -MT src/CMakeFiles/qpid-dispatch.dir/hash.c.o
> -MF src/CMakeFiles/qpid-dispatch.dir/hash.c.o.d -o
> src/CMakeFiles/qpid-dispatch.dir/hash.c.o -c ../src/hash.c
> ../src/hash.c: In function ���qd_hash_retrieve_prefix���:
> ../src/hash.c:303:17: error: ���item��� may be used uninitialized in this
> function [-Werror=maybe-uninitialized]
> 303 | *val = item->v.val;
> | ~~~^~~~
> ../src/hash.c: In function ���qd_hash_retrieve_prefix_const���:
> ../src/hash.c:327:23: error: ���item��� may be used uninitialized in this
> function [-Werror=maybe-uninitialized]
> 327 | *val = item->v.val_const;
> | ~~~^~
> cc1: all warnings being treated as errors
> [32/116] Building C object src/CMakeFiles/qpid-dispatch.dir/message.c.o
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2342) Fails to build on Fedora rawhide
[
https://issues.apache.org/jira/browse/PROTON-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306546#comment-17306546
]
ASF subversion and git services commented on PROTON-2342:
-
Commit db90a2b3becdcd9a7fa98186c10b86e45212dac8 in qpid-proton's branch
refs/heads/master from Jiri Danek
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=db90a2b ]
PROTON-2342 Upgrade Catch to v1.12.2
https://github.com/catchorg/Catch2/releases/tag/v1.12.2
> Fails to build on Fedora rawhide
>
>
> Key: PROTON-2342
> URL: https://issues.apache.org/jira/browse/PROTON-2342
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.33.0
>Reporter: Irina Boverman
>Priority: Major
> Fix For: proton-c-0.34.0
>
>
> {noformat}
> [ 29%] Building CXX object c/tests/CMakeFiles/test_main.dir/test_main.cpp.o
> In file included from /usr/include/signal.h:315,
> from /root/apache-qpid-proton/tests/include/catch.hpp:6520,
> from /root/apache-qpid-proton/c/tests/test_main.cpp:21:
> /root/apache-qpid-proton/tests/include/catch.hpp:6543:33: error: size of
> array 'altStackMem' is not an integral constant-expression
> 6543 | static char altStackMem[SIGSTKSZ];
> | ^~~~
> /root/apache-qpid-proton/tests/include/catch.hpp:6594:45: error: size of
> array 'altStackMem' is not an integral constant-expression
> 6594 | char FatalConditionHandler::altStackMem[SIGSTKSZ] = {};
> | ^~~~
> make[2]: *** [c/tests/CMakeFiles/test_main.dir/build.make:82:
> c/tests/CMakeFiles/test_main.dir/test_main.cpp.o] Error 1
> make[1]: *** [CMakeFiles/Makefile2:1901:
> c/tests/CMakeFiles/test_main.dir/all] Error 2
> make: *** [Makefile:160: all] Error 2
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2342) Fails to build on Fedora rawhide
[
https://issues.apache.org/jira/browse/PROTON-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306547#comment-17306547
]
ASF subversion and git services commented on PROTON-2342:
-
Commit 3deea551c9fe61adefae5eb8fd77e919850a213d in qpid-proton's branch
refs/heads/master from Jiri Danek
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=3deea55 ]
PROTON-2342 Apply patch for non-constant SIGSTKSZ from Fedora to Catch
https://src.fedoraproject.org/rpms/catch1/c/059104ba87494c0b5ebe16844ec190f253e51cac?branch=rawhide
> Fails to build on Fedora rawhide
>
>
> Key: PROTON-2342
> URL: https://issues.apache.org/jira/browse/PROTON-2342
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.33.0
>Reporter: Irina Boverman
>Priority: Major
> Fix For: proton-c-0.34.0
>
>
> {noformat}
> [ 29%] Building CXX object c/tests/CMakeFiles/test_main.dir/test_main.cpp.o
> In file included from /usr/include/signal.h:315,
> from /root/apache-qpid-proton/tests/include/catch.hpp:6520,
> from /root/apache-qpid-proton/c/tests/test_main.cpp:21:
> /root/apache-qpid-proton/tests/include/catch.hpp:6543:33: error: size of
> array 'altStackMem' is not an integral constant-expression
> 6543 | static char altStackMem[SIGSTKSZ];
> | ^~~~
> /root/apache-qpid-proton/tests/include/catch.hpp:6594:45: error: size of
> array 'altStackMem' is not an integral constant-expression
> 6594 | char FatalConditionHandler::altStackMem[SIGSTKSZ] = {};
> | ^~~~
> make[2]: *** [c/tests/CMakeFiles/test_main.dir/build.make:82:
> c/tests/CMakeFiles/test_main.dir/test_main.cpp.o] Error 1
> make[1]: *** [CMakeFiles/Makefile2:1901:
> c/tests/CMakeFiles/test_main.dir/all] Error 2
> make: *** [Makefile:160: all] Error 2
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2342) Fails to build on Fedora rawhide
[
https://issues.apache.org/jira/browse/PROTON-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk resolved PROTON-2342.
Assignee: Jiri Daněk
Resolution: Fixed
> Fails to build on Fedora rawhide
>
>
> Key: PROTON-2342
> URL: https://issues.apache.org/jira/browse/PROTON-2342
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.33.0
>Reporter: Irina Boverman
>Assignee: Jiri Daněk
>Priority: Major
> Fix For: proton-c-0.34.0
>
>
> {noformat}
> [ 29%] Building CXX object c/tests/CMakeFiles/test_main.dir/test_main.cpp.o
> In file included from /usr/include/signal.h:315,
> from /root/apache-qpid-proton/tests/include/catch.hpp:6520,
> from /root/apache-qpid-proton/c/tests/test_main.cpp:21:
> /root/apache-qpid-proton/tests/include/catch.hpp:6543:33: error: size of
> array 'altStackMem' is not an integral constant-expression
> 6543 | static char altStackMem[SIGSTKSZ];
> | ^~~~
> /root/apache-qpid-proton/tests/include/catch.hpp:6594:45: error: size of
> array 'altStackMem' is not an integral constant-expression
> 6594 | char FatalConditionHandler::altStackMem[SIGSTKSZ] = {};
> | ^~~~
> make[2]: *** [c/tests/CMakeFiles/test_main.dir/build.make:82:
> c/tests/CMakeFiles/test_main.dir/test_main.cpp.o] Error 1
> make[1]: *** [CMakeFiles/Makefile2:1901:
> c/tests/CMakeFiles/test_main.dir/all] Error 2
> make: *** [Makefile:160: all] Error 2
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2342) Fails to build on Fedora rawhide
[
https://issues.apache.org/jira/browse/PROTON-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306545#comment-17306545
]
ASF GitHub Bot commented on PROTON-2342:
jiridanek merged pull request #301:
URL: https://github.com/apache/qpid-proton/pull/301
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Fails to build on Fedora rawhide
>
>
> Key: PROTON-2342
> URL: https://issues.apache.org/jira/browse/PROTON-2342
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.33.0
>Reporter: Irina Boverman
>Priority: Major
> Fix For: proton-c-0.34.0
>
>
> {noformat}
> [ 29%] Building CXX object c/tests/CMakeFiles/test_main.dir/test_main.cpp.o
> In file included from /usr/include/signal.h:315,
> from /root/apache-qpid-proton/tests/include/catch.hpp:6520,
> from /root/apache-qpid-proton/c/tests/test_main.cpp:21:
> /root/apache-qpid-proton/tests/include/catch.hpp:6543:33: error: size of
> array 'altStackMem' is not an integral constant-expression
> 6543 | static char altStackMem[SIGSTKSZ];
> | ^~~~
> /root/apache-qpid-proton/tests/include/catch.hpp:6594:45: error: size of
> array 'altStackMem' is not an integral constant-expression
> 6594 | char FatalConditionHandler::altStackMem[SIGSTKSZ] = {};
> | ^~~~
> make[2]: *** [c/tests/CMakeFiles/test_main.dir/build.make:82:
> c/tests/CMakeFiles/test_main.dir/test_main.cpp.o] Error 1
> make[1]: *** [CMakeFiles/Makefile2:1901:
> c/tests/CMakeFiles/test_main.dir/all] Error 2
> make: *** [Makefile:160: all] Error 2
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-proton] jiridanek merged pull request #301: PROTON-2342 Apply patch for non-constant SIGSTKSZ from Fedora to Catch
jiridanek merged pull request #301: URL: https://github.com/apache/qpid-proton/pull/301 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1962) Make LSan suppressions more targeted and specific (within reason)
[
https://issues.apache.org/jira/browse/DISPATCH-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306539#comment-17306539
]
ASF GitHub Bot commented on DISPATCH-1962:
--
jiridanek commented on a change in pull request #1080:
URL: https://github.com/apache/qpid-dispatch/pull/1080#discussion_r599037627
##
File path: src/server.c
##
@@ -1372,6 +1372,10 @@ qd_server_t *qd_server(qd_dispatch_t *qd, int
thread_count, const char *containe
void qd_server_free(qd_server_t *qd_server)
{
if (!qd_server) return;
+
+qd_http_server_stop(qd_server->http); /* Stop HTTP threads immediately */
+qd_http_server_free(qd_server->http);
Review comment:
```suggestion
qd_http_server_free(qd_server->http);
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Make LSan suppressions more targeted and specific (within reason)
> -
>
> Key: DISPATCH-1962
> URL: https://issues.apache.org/jira/browse/DISPATCH-1962
> Project: Qpid Dispatch
> Issue Type: Test
>Affects Versions: 1.15.0
>Reporter: Jiri Daněk
>Priority: Major
> Attachments: dispatch_leaking_agent.png
>
>
> There are some unfortunate suppressions in {{tests/lsan.supp}} at this moment:
> {code}
> leak:*libwebsockets*
> {code}
> This is way too broad. It suppresses leaks in Dispatch files, since it
> matches e.g. {{src/http-libwebsockets.c}}.
> The stars at the beginning and end are actually assumed implicitly. If you do
> not want substring match, you have to do ^foo$. LSan suppression format is
> simplistic, very unlike Valgrind's.
> {code}
> leak:run_unit_tests.c
> {code}
> Same thing, any leaks revealed by running unit_tests get suppressed. This
> suppression suppresses all leak traces that include run_unit_tests.c anywhere
> in the stack. What't the point of running such tests under leak detector,
> then?
> {code}
> leak:run_unit_tests.c
> leak:^libqpid-proton.so$
> {code}
> Same thing. The patterns suppress all leaks that include Python (or Proton)
> anywhere in the stacktrace. That means there are huge blind spots where
> dispatch leaks can hide. This is a weakness of the lsan.supp syntax (Valgrind
> suppressions can be much more targeted and discerning).
> h3. Python leaks
> Leaks are known and there is ongoing effort to fight them:
> https://bugs.python.org/issue1635741 (https://bugs.python.org/issue25302) and
> https://www.python.org/dev/peps/pep-3121
> Here's valgrind suppression file from somebody who actually investigated the
> Python leaks and identified the harmless ones:
> https://github.com/libgit2/pygit2/blob/master/misc/valgrind-python.supp
> One example of a hidden leak in dispatch, which is revealed by making Python
> suppressions more targetted:
> {code}
> 9: Direct leak of 56 byte(s) in 1 object(s) allocated from:
> 9: #0 0x7f78a3606e8f in __interceptor_malloc
> (/nix/store/g40sl3zh3nv52vj0mrl4iki5iphh5ika-gcc-10.2.0-lib/lib/libasan.so.6+0xace8f)
> 9: #1 0x7f78a2d64afb in qd_malloc ../include/qpid/dispatch/ctools.h:229
> 9: #2 0x7f78a2d657da in qdr_core_subscribe
> ../src/router_core/route_tables.c:149
> 9: #3 0x7f78a2c83072 in IoAdapter_init ../src/python_embedded.c:711
> 9: #4 0x7f78a2353a6c in type_call
> (/nix/store/r85nxfnwiv45nbmf5yb60jj8ajim4m7w-python3-3.8.5/lib/libpython3.8.so.1.0+0x165a6c)
> {code}
> The problem is in
> {code}
> class Agent:
> ...
> def activate(self, address):
> ...
> self.io = IoAdapter(self.receive, address, 'L', '0',
> TREATMENT_ANYCAST_CLOSEST)
> {code}
> IoAdapter refers to Agent (through the bound method reference self.receive)
> and Agent refers to IoAdapter (through property self.io). Since IoAdapter is
> implemented in C and does not implement support for Python's cyclic GC, there
> is no way to break the cycle.
> Heap dump in attachment. The bound method is at the top of the picture.
> (Ignore the Mock objects, I was trying to simplify the picture while not
> getting crashes due to too much meddling).
> h3. Random observations
> It is possible to build special Debug build of Python, which has tools to
> detect leaks, asserts to prevent negative refcounts, etc.
> https://pythonextensionpatterns.readthedocs.io/en/latest/debugging/debug_python.html#debug-version-of-python-memory-alloc-label
> Use the following to detect python leaks (instead of valgrind)
> https://docs.python.org/3/library/tracemalloc.html
> Use https://pypi.org/project/objgraph (with graphviz) to view heap object
> trees. The following renders the picture as a png under /tmp and prints the
>
[GitHub] [qpid-dispatch] jiridanek commented on a change in pull request #1080: DISPATCH-1962 Fix leak from libwebsockets.so in unit_tests
jiridanek commented on a change in pull request #1080:
URL: https://github.com/apache/qpid-dispatch/pull/1080#discussion_r599037627
##
File path: src/server.c
##
@@ -1372,6 +1372,10 @@ qd_server_t *qd_server(qd_dispatch_t *qd, int
thread_count, const char *containe
void qd_server_free(qd_server_t *qd_server)
{
if (!qd_server) return;
+
+qd_http_server_stop(qd_server->http); /* Stop HTTP threads immediately */
+qd_http_server_free(qd_server->http);
Review comment:
```suggestion
qd_http_server_free(qd_server->http);
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1962) Make LSan suppressions more targeted and specific (within reason)
[
https://issues.apache.org/jira/browse/DISPATCH-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306529#comment-17306529
]
ASF GitHub Bot commented on DISPATCH-1962:
--
ganeshmurthy commented on a change in pull request #1080:
URL: https://github.com/apache/qpid-dispatch/pull/1080#discussion_r599029573
##
File path: src/server.c
##
@@ -1372,6 +1372,10 @@ qd_server_t *qd_server(qd_dispatch_t *qd, int
thread_count, const char *containe
void qd_server_free(qd_server_t *qd_server)
{
if (!qd_server) return;
+
+qd_http_server_stop(qd_server->http); /* Stop HTTP threads immediately */
+qd_http_server_free(qd_server->http);
Review comment:
Yes, let's remove the call to qd_http_server_stop(). Otherwise this PR
is good to go. Thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Make LSan suppressions more targeted and specific (within reason)
> -
>
> Key: DISPATCH-1962
> URL: https://issues.apache.org/jira/browse/DISPATCH-1962
> Project: Qpid Dispatch
> Issue Type: Test
>Affects Versions: 1.15.0
>Reporter: Jiri Daněk
>Priority: Major
> Attachments: dispatch_leaking_agent.png
>
>
> There are some unfortunate suppressions in {{tests/lsan.supp}} at this moment:
> {code}
> leak:*libwebsockets*
> {code}
> This is way too broad. It suppresses leaks in Dispatch files, since it
> matches e.g. {{src/http-libwebsockets.c}}.
> The stars at the beginning and end are actually assumed implicitly. If you do
> not want substring match, you have to do ^foo$. LSan suppression format is
> simplistic, very unlike Valgrind's.
> {code}
> leak:run_unit_tests.c
> {code}
> Same thing, any leaks revealed by running unit_tests get suppressed. This
> suppression suppresses all leak traces that include run_unit_tests.c anywhere
> in the stack. What't the point of running such tests under leak detector,
> then?
> {code}
> leak:run_unit_tests.c
> leak:^libqpid-proton.so$
> {code}
> Same thing. The patterns suppress all leaks that include Python (or Proton)
> anywhere in the stacktrace. That means there are huge blind spots where
> dispatch leaks can hide. This is a weakness of the lsan.supp syntax (Valgrind
> suppressions can be much more targeted and discerning).
> h3. Python leaks
> Leaks are known and there is ongoing effort to fight them:
> https://bugs.python.org/issue1635741 (https://bugs.python.org/issue25302) and
> https://www.python.org/dev/peps/pep-3121
> Here's valgrind suppression file from somebody who actually investigated the
> Python leaks and identified the harmless ones:
> https://github.com/libgit2/pygit2/blob/master/misc/valgrind-python.supp
> One example of a hidden leak in dispatch, which is revealed by making Python
> suppressions more targetted:
> {code}
> 9: Direct leak of 56 byte(s) in 1 object(s) allocated from:
> 9: #0 0x7f78a3606e8f in __interceptor_malloc
> (/nix/store/g40sl3zh3nv52vj0mrl4iki5iphh5ika-gcc-10.2.0-lib/lib/libasan.so.6+0xace8f)
> 9: #1 0x7f78a2d64afb in qd_malloc ../include/qpid/dispatch/ctools.h:229
> 9: #2 0x7f78a2d657da in qdr_core_subscribe
> ../src/router_core/route_tables.c:149
> 9: #3 0x7f78a2c83072 in IoAdapter_init ../src/python_embedded.c:711
> 9: #4 0x7f78a2353a6c in type_call
> (/nix/store/r85nxfnwiv45nbmf5yb60jj8ajim4m7w-python3-3.8.5/lib/libpython3.8.so.1.0+0x165a6c)
> {code}
> The problem is in
> {code}
> class Agent:
> ...
> def activate(self, address):
> ...
> self.io = IoAdapter(self.receive, address, 'L', '0',
> TREATMENT_ANYCAST_CLOSEST)
> {code}
> IoAdapter refers to Agent (through the bound method reference self.receive)
> and Agent refers to IoAdapter (through property self.io). Since IoAdapter is
> implemented in C and does not implement support for Python's cyclic GC, there
> is no way to break the cycle.
> Heap dump in attachment. The bound method is at the top of the picture.
> (Ignore the Mock objects, I was trying to simplify the picture while not
> getting crashes due to too much meddling).
> h3. Random observations
> It is possible to build special Debug build of Python, which has tools to
> detect leaks, asserts to prevent negative refcounts, etc.
> https://pythonextensionpatterns.readthedocs.io/en/latest/debugging/debug_python.html#debug-version-of-python-memory-alloc-label
> Use the following to detect python leaks (instead of valgrind)
> https://docs.python.org/3/library/tracemalloc.html
> Use https://pypi.org/project/objgraph (with graphviz) to view heap object
> trees. The following renders the picture as a png
[GitHub] [qpid-dispatch] ganeshmurthy commented on a change in pull request #1080: DISPATCH-1962 Fix leak from libwebsockets.so in unit_tests
ganeshmurthy commented on a change in pull request #1080:
URL: https://github.com/apache/qpid-dispatch/pull/1080#discussion_r599029573
##
File path: src/server.c
##
@@ -1372,6 +1372,10 @@ qd_server_t *qd_server(qd_dispatch_t *qd, int
thread_count, const char *containe
void qd_server_free(qd_server_t *qd_server)
{
if (!qd_server) return;
+
+qd_http_server_stop(qd_server->http); /* Stop HTTP threads immediately */
+qd_http_server_free(qd_server->http);
Review comment:
Yes, let's remove the call to qd_http_server_stop(). Otherwise this PR
is good to go. Thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1949) ASAN flags shift errors on signed conversion
[ https://issues.apache.org/jira/browse/DISPATCH-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306517#comment-17306517 ] ASF GitHub Bot commented on DISPATCH-1949: -- asfgit merged pull request #1030: URL: https://github.com/apache/qpid-dispatch/pull/1030 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > ASAN flags shift errors on signed conversion > > > Key: DISPATCH-1949 > URL: https://issues.apache.org/jira/browse/DISPATCH-1949 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.14.0, 1.15.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Trivial > Fix For: 1.16.0 > > > Raised during the unit_test* ctests: > > 8: /home/kgiusti/work/dispatch/qpid-dispatch/src/parse.c:509:74: runtime > error: left shift of 128 by 24 places cannot be represented in type 'int\ > ' > 8: /home/kgiusti/work/dispatch/qpid-dispatch/src/parse.c:497:66: runtime > error: left shift of 128 by 56 places cannot be represented in type 'lon\ > g int' -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1949) ASAN flags shift errors on signed conversion
[ https://issues.apache.org/jira/browse/DISPATCH-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306516#comment-17306516 ] ASF subversion and git services commented on DISPATCH-1949: --- Commit e7e7189f3fbc4dc80df45bda596571c4031cba02 in qpid-dispatch's branch refs/heads/master from Ken Giusti [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=e7e7189 ] DISPATCH-1949: fix ASAN warnings in parse.c > ASAN flags shift errors on signed conversion > > > Key: DISPATCH-1949 > URL: https://issues.apache.org/jira/browse/DISPATCH-1949 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.14.0, 1.15.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Trivial > Fix For: 1.16.0 > > > Raised during the unit_test* ctests: > > 8: /home/kgiusti/work/dispatch/qpid-dispatch/src/parse.c:509:74: runtime > error: left shift of 128 by 24 places cannot be represented in type 'int\ > ' > 8: /home/kgiusti/work/dispatch/qpid-dispatch/src/parse.c:497:66: runtime > error: left shift of 128 by 56 places cannot be represented in type 'lon\ > g int' -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1949) ASAN flags shift errors on signed conversion
[ https://issues.apache.org/jira/browse/DISPATCH-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved DISPATCH-1949. -- Resolution: Fixed > ASAN flags shift errors on signed conversion > > > Key: DISPATCH-1949 > URL: https://issues.apache.org/jira/browse/DISPATCH-1949 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.14.0, 1.15.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Trivial > Fix For: 1.16.0 > > > Raised during the unit_test* ctests: > > 8: /home/kgiusti/work/dispatch/qpid-dispatch/src/parse.c:509:74: runtime > error: left shift of 128 by 24 places cannot be represented in type 'int\ > ' > 8: /home/kgiusti/work/dispatch/qpid-dispatch/src/parse.c:497:66: runtime > error: left shift of 128 by 56 places cannot be represented in type 'lon\ > g int' -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] asfgit merged pull request #1030: DISPATCH-1949: fix ASAN warnings in parse.c
asfgit merged pull request #1030: URL: https://github.com/apache/qpid-dispatch/pull/1030 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2014) Router TCP Adapter crash with high thread count and load
[
https://issues.apache.org/jira/browse/DISPATCH-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306496#comment-17306496
]
michael goulish commented on DISPATCH-2014:
---
When I used 64 dispatch worker threads and hit it with 200 'hey' senders – each
test 30 seconds long – it died 3 out of 4 times. (SEGV)
When I went down to 32 dispatch worker threads, it survived 3 out of 3 tests
with 200 senders, and then 3 out of 3 tests with 500 senders, and then 3 out of
3 tests with 1000 senders.
> Router TCP Adapter crash with high thread count and load
>
>
> Key: DISPATCH-2014
> URL: https://issues.apache.org/jira/browse/DISPATCH-2014
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Reporter: michael goulish
>Priority: Major
>
> Using latest proton and dispatch master code as of 3 hours ago.
> Testing router TCP adapter on a machine with 32 cores / 64 threads.
> I gave the router 64 worker threads, then used 'hey' load generator to send
> it HTTP requests to a TCP listener which router forwarded to Nginx on same
> machine.
> Multiple tests with increasing number of parallel senders: 10, 20, 30,...Each
> sender throttled to 10 messages per second.
> It survived many tests, but crashed around test with 200 senders.
> I believe this is easily repeatable – I will go check that now.
>
> Here is the thread that crashed:
> {color:#de350b} #0 0x7f33186a0684 in pthread_mutex_lock () from
> /lib64/libpthread.so.0{color}
> {color:#de350b} #1 0x7f33186e2848 in lock (m=){color}
> {color:#de350b} at
> /home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
> {color:#de350b} #2 process (tsk=){color}
> {color:#de350b} at
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2248{color}
> {color:#de350b} #3 next_event_batch (p=0x10ed970, can_block=true){color}
> {color:#de350b} at
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2423{color}
> {color:#de350b} #4 0x7f33187c192f in thread_run (arg=0x10f6e40){color}
> {color:#de350b} at /home/mick/latest/qpid-dispatch/src/server.c:1107{color}
> {color:#de350b} #5 0x7f331869e3f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b} #6 0x7f33181b2b53 in clone () from /lib64/libc.so.6{color}
>
> {color:#172b4d}And here are all the threads:{color}
> {color:#de350b}(gdb) thread apply all bt{color}
> {color:#de350b}Thread 65 (Thread 0x7f3244ff9640 (LWP 36500)):{color}
> {color:#de350b}#0 0x7f33186a7ea0 in __lll_lock_wait () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#1 0x7f33186a08f5 in pthread_mutex_lock () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#2 0x7f33186dfc5f in lock (m=0x10edc90) at
> /home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
> {color:#de350b}#3 pni_raw_connection_done (rc=0x10ed3b8) at
> /home/mick/latest/qpid-proton/c/src/proactor/epoll_raw_connection.c:423{color}
> {color:#de350b}#4 pn_proactor_done (batch=0x10ed970, p=0x10ed970) at
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2696{color}
> {color:#de350b}#5 pn_proactor_done (p=0x10ed970,
> batch=batch@entry=0x7f326811a578) at
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2676{color}
> {color:#de350b}#6 0x7f33187c1a11 in thread_run (arg=0x10f6e40) at
> /home/mick/latest/qpid-dispatch/src/server.c:1140{color}
> {color:#de350b}#7 0x7f331869e3f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#8 0x7f33181b2b53 in clone () from /lib64/libc.so.6{color}
> {color:#de350b}Thread 64 (Thread 0x7f327640 (LWP 36481)):{color}
> {color:#de350b}#0 0x7f33186a7ea0 in __lll_lock_wait () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#1 0x7f33186a08f5 in pthread_mutex_lock () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#2 0x7f33186e2b7e in lock (m=0x10edc90) at
> /home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
> {color:#de350b}#3 process (tsk=) at
> /home/mick/latest/qpid-proton/c/src/proacto--Type for more, q to quit,
> c to continue without paging--{color}
> {color:#de350b}r/epoll.c:2248{color}
> {color:#de350b}#4 next_event_batch (p=, can_block=true) at
> /home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2423{color}
> {color:#de350b}#5 0x7f33187c192f in thread_run (arg=0x10f6e40) at
> /home/mick/latest/qpid-dispatch/src/server.c:1107{color}
> {color:#de350b}#6 0x7f331869e3f9 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#7 0x7f33181b2b53 in clone () from /lib64/libc.so.6{color}
> {color:#de350b}Thread 63 (Thread 0x7f322f7fe640 (LWP 36502)):{color}
> {color:#de350b}#0 0x7f33186a7ea0 in __lll_lock_wait () from
> /lib64/libpthread.so.0{color}
> {color:#de350b}#1
[jira] [Created] (DISPATCH-2014) Router TCP Adapter crash with high thread count and load
michael goulish created DISPATCH-2014:
-
Summary: Router TCP Adapter crash with high thread count and load
Key: DISPATCH-2014
URL: https://issues.apache.org/jira/browse/DISPATCH-2014
Project: Qpid Dispatch
Issue Type: Bug
Components: Protocol Adaptors
Reporter: michael goulish
Using latest proton and dispatch master code as of 3 hours ago.
Testing router TCP adapter on a machine with 32 cores / 64 threads.
I gave the router 64 worker threads, then used 'hey' load generator to send it
HTTP requests to a TCP listener which router forwarded to Nginx on same
machine.
Multiple tests with increasing number of parallel senders: 10, 20, 30,...Each
sender throttled to 10 messages per second.
It survived many tests, but crashed around test with 200 senders.
I believe this is easily repeatable – I will go check that now.
Here is the thread that crashed:
{color:#de350b} #0 0x7f33186a0684 in pthread_mutex_lock () from
/lib64/libpthread.so.0{color}
{color:#de350b} #1 0x7f33186e2848 in lock (m=){color}
{color:#de350b} at
/home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
{color:#de350b} #2 process (tsk=){color}
{color:#de350b} at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2248{color}
{color:#de350b} #3 next_event_batch (p=0x10ed970, can_block=true){color}
{color:#de350b} at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2423{color}
{color:#de350b} #4 0x7f33187c192f in thread_run (arg=0x10f6e40){color}
{color:#de350b} at /home/mick/latest/qpid-dispatch/src/server.c:1107{color}
{color:#de350b} #5 0x7f331869e3f9 in start_thread () from
/lib64/libpthread.so.0{color}
{color:#de350b} #6 0x7f33181b2b53 in clone () from /lib64/libc.so.6{color}
{color:#172b4d}And here are all the threads:{color}
{color:#de350b}(gdb) thread apply all bt{color}
{color:#de350b}Thread 65 (Thread 0x7f3244ff9640 (LWP 36500)):{color}
{color:#de350b}#0 0x7f33186a7ea0 in __lll_lock_wait () from
/lib64/libpthread.so.0{color}
{color:#de350b}#1 0x7f33186a08f5 in pthread_mutex_lock () from
/lib64/libpthread.so.0{color}
{color:#de350b}#2 0x7f33186dfc5f in lock (m=0x10edc90) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
{color:#de350b}#3 pni_raw_connection_done (rc=0x10ed3b8) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll_raw_connection.c:423{color}
{color:#de350b}#4 pn_proactor_done (batch=0x10ed970, p=0x10ed970) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2696{color}
{color:#de350b}#5 pn_proactor_done (p=0x10ed970,
batch=batch@entry=0x7f326811a578) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2676{color}
{color:#de350b}#6 0x7f33187c1a11 in thread_run (arg=0x10f6e40) at
/home/mick/latest/qpid-dispatch/src/server.c:1140{color}
{color:#de350b}#7 0x7f331869e3f9 in start_thread () from
/lib64/libpthread.so.0{color}
{color:#de350b}#8 0x7f33181b2b53 in clone () from /lib64/libc.so.6{color}
{color:#de350b}Thread 64 (Thread 0x7f327640 (LWP 36481)):{color}
{color:#de350b}#0 0x7f33186a7ea0 in __lll_lock_wait () from
/lib64/libpthread.so.0{color}
{color:#de350b}#1 0x7f33186a08f5 in pthread_mutex_lock () from
/lib64/libpthread.so.0{color}
{color:#de350b}#2 0x7f33186e2b7e in lock (m=0x10edc90) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
{color:#de350b}#3 process (tsk=) at
/home/mick/latest/qpid-proton/c/src/proacto--Type for more, q to quit, c
to continue without paging--{color}
{color:#de350b}r/epoll.c:2248{color}
{color:#de350b}#4 next_event_batch (p=, can_block=true) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2423{color}
{color:#de350b}#5 0x7f33187c192f in thread_run (arg=0x10f6e40) at
/home/mick/latest/qpid-dispatch/src/server.c:1107{color}
{color:#de350b}#6 0x7f331869e3f9 in start_thread () from
/lib64/libpthread.so.0{color}
{color:#de350b}#7 0x7f33181b2b53 in clone () from /lib64/libc.so.6{color}
{color:#de350b}Thread 63 (Thread 0x7f322f7fe640 (LWP 36502)):{color}
{color:#de350b}#0 0x7f33186a7ea0 in __lll_lock_wait () from
/lib64/libpthread.so.0{color}
{color:#de350b}#1 0x7f33186a08f5 in pthread_mutex_lock () from
/lib64/libpthread.so.0{color}
{color:#de350b}#2 0x7f33186dfc5f in lock (m=0x10edc90) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll-internal.h:326{color}
{color:#de350b}#3 pni_raw_connection_done (rc=0x10ed3b8) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll_raw_connection.c:423{color}
{color:#de350b}#4 pn_proactor_done (batch=0x10ed970, p=0x10ed970) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2696{color}
{color:#de350b}#5 pn_proactor_done (p=0x10ed970,
batch=batch@entry=0x7f32c8063af8) at
/home/mick/latest/qpid-proton/c/src/proactor/epoll.c:2676{color}
{color:#de350b}#6 0x7f33187c1a11 in thread_run (arg=0x10f6e40) at
[jira] [Created] (DISPATCH-2013) Http1AdaptorManagementTest fails with AssertionError: 0 != 1 : HTTP connection not deleted
Jiri Daněk created DISPATCH-2013:
Summary: Http1AdaptorManagementTest fails with AssertionError: 0
!= 1 : HTTP connection not deleted
Key: DISPATCH-2013
URL: https://issues.apache.org/jira/browse/DISPATCH-2013
Project: Qpid Dispatch
Issue Type: Bug
Components: Protocol Adaptors
Affects Versions: 1.16.0
Reporter: Jiri Daněk
#
https://github.com/jiridanek/qpid-dispatch/runs/2166630124?check_suite_focus=true#step:9:2035
This is a PR build, not master. I remember seeing the same issue once before,
though. I'll make note of it here, in case it reappears again.
{noformat}
71: Trigger Q2 backpressure against the HTTP server. ... ok
71:
71: ==
71: FAIL: test_01_mgmt (system_tests_http1_adaptor.Http1AdaptorManagementTest)
71: Create and delete HTTP1 connectors and listeners
71: --
71: Traceback (most recent call last):
71: File
"/home/runner/work/qpid-dispatch/qpid-dispatch/qpid-dispatch/tests/system_tests_http1_adaptor.py",
line 464, in test_01_mgmt
71: self.assertEqual(0, hconns, msg="HTTP connection not deleted")
71: AssertionError: 0 != 1 : HTTP connection not deleted
71:
71: --
71: Ran 20 tests in 80.903s
71:
71: FAILED (failures=1)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1844) sys_mutex leak detected by LeakSanitizer ASAN (shutdown)
[
https://issues.apache.org/jira/browse/DISPATCH-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306244#comment-17306244
]
Jiri Daněk commented on DISPATCH-1844:
--
bq. can I re-assign is Jira to you?
[~kgiusti] Not sure. WDYT about the PR that is moving things around? Is that a
viable start? I don't know dispatch well enough to just start refactoring
things...
My interest in resolving this is that I need dispatch to be able to do a clean
shutdown like this because other leak issues depend on it: e.g. the IoAdapter
leak from Python needs this leak resolved, otherwise all Python objects won't
be GCd (if I remember the situation correctly, its already a month old in my
head).
> sys_mutex leak detected by LeakSanitizer ASAN (shutdown)
>
>
> Key: DISPATCH-1844
> URL: https://issues.apache.org/jira/browse/DISPATCH-1844
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 1.14.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Labels: lsan
> Fix For: 1.16.0
>
>
> The LSAN (ASAN) leak sanitizer occasionally detects a leak of sys_mutex items
> that are used by the qd_message_t content:
>
> {quote}70: ==1475684==ERROR: LeakSanitizer: detected memory leaks
> 70:
> 70: Direct leak of 128 byte(s) in 2 object(s) allocated from:
> 70: #0 0x7f52044ebbf5 in __interceptor_posix_memalign
> (/lib64/libasan.so.5+0x10ebf5)
> 70: #1 0x7f5203b7e2cc in sys_mutex
> /home/kgiusti/work/dispatch/qpid-dispatch/src/posix/threading.c:41
> 70: #2 0x7f5203b31b0f in qd_message
> /home/kgiusti/work/dispatch/qpid-dispatch/src/message.c:1012
> 70: #3 0x7f5203a9edae in _server_rx_headers_done_cb
> /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/http1/http1_server.c:862
>
> 70: #4 0x7f5203a64d2a in process_headers_done
> /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/http1/http1_codec.c:831
>
> 70: #5 0x7f5203a66411 in parse_header
> /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/http1/http1_codec.c:911
>
> 70: #6 0x7f5203a6d065 in decode_incoming
> /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/http1/http1_codec.c:1301
>
> 70: #7 0x7f5203a6e09a in h1_codec_connection_rx_data
> /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/http1/http1_codec.c:1346
>
> 70: #8 0x7f5203a9a3fe in _handle_connection_events
> /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/http1/http1_server.c:562
>
> 70: #9 0x7f5203ceb754 in handle_event_with_context
> /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:804
> 70: #10 0x7f5203ceb796 in do_handle_raw_connection_event
> /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:810
> 70: #11 0x7f5203ceffe5 in handle
> /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:1090
> 70: #12 0x7f5203cf0297 in thread_run
> /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:1122
> 70: #13 0x7f5203cf770f in qd_server_run
> /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:1484
> 70: #14 0x4026f8 in main_process
> /home/kgiusti/work/dispatch/qpid-dispatch/router/src/main.c:113
> 70: #15 0x404576 in main
> /home/kgiusti/work/dispatch/qpid-dispatch/router/src/main.c:367
> 70: #16 0x7f52025761a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
> {quote}
> This leak is easily triggered by the HTTP1 adaptor but can also be triggered
> using plain AMQP.
> This is a shutdown leak. This occurs when a qdr_delivery_t is left on the
> link's updated_deliveries list at the point where the shutdown occurs.
> Since this is a shutdown leak I will add a suppression to the lsan.supp list
> for now - this Jira remains open until the issue is actually fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1844) sys_mutex leak detected by LeakSanitizer ASAN (shutdown)
[
https://issues.apache.org/jira/browse/DISPATCH-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306232#comment-17306232
]
Ken Giusti commented on DISPATCH-1844:
--
[~jdanek] can I re-assign is Jira to you?
> sys_mutex leak detected by LeakSanitizer ASAN (shutdown)
>
>
> Key: DISPATCH-1844
> URL: https://issues.apache.org/jira/browse/DISPATCH-1844
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 1.14.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
> Labels: lsan
> Fix For: 1.16.0
>
>
> The LSAN (ASAN) leak sanitizer occasionally detects a leak of sys_mutex items
> that are used by the qd_message_t content:
>
> {quote}70: ==1475684==ERROR: LeakSanitizer: detected memory leaks
> 70:
> 70: Direct leak of 128 byte(s) in 2 object(s) allocated from:
> 70: #0 0x7f52044ebbf5 in __interceptor_posix_memalign
> (/lib64/libasan.so.5+0x10ebf5)
> 70: #1 0x7f5203b7e2cc in sys_mutex
> /home/kgiusti/work/dispatch/qpid-dispatch/src/posix/threading.c:41
> 70: #2 0x7f5203b31b0f in qd_message
> /home/kgiusti/work/dispatch/qpid-dispatch/src/message.c:1012
> 70: #3 0x7f5203a9edae in _server_rx_headers_done_cb
> /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/http1/http1_server.c:862
>
> 70: #4 0x7f5203a64d2a in process_headers_done
> /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/http1/http1_codec.c:831
>
> 70: #5 0x7f5203a66411 in parse_header
> /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/http1/http1_codec.c:911
>
> 70: #6 0x7f5203a6d065 in decode_incoming
> /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/http1/http1_codec.c:1301
>
> 70: #7 0x7f5203a6e09a in h1_codec_connection_rx_data
> /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/http1/http1_codec.c:1346
>
> 70: #8 0x7f5203a9a3fe in _handle_connection_events
> /home/kgiusti/work/dispatch/qpid-dispatch/src/adaptors/http1/http1_server.c:562
>
> 70: #9 0x7f5203ceb754 in handle_event_with_context
> /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:804
> 70: #10 0x7f5203ceb796 in do_handle_raw_connection_event
> /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:810
> 70: #11 0x7f5203ceffe5 in handle
> /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:1090
> 70: #12 0x7f5203cf0297 in thread_run
> /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:1122
> 70: #13 0x7f5203cf770f in qd_server_run
> /home/kgiusti/work/dispatch/qpid-dispatch/src/server.c:1484
> 70: #14 0x4026f8 in main_process
> /home/kgiusti/work/dispatch/qpid-dispatch/router/src/main.c:113
> 70: #15 0x404576 in main
> /home/kgiusti/work/dispatch/qpid-dispatch/router/src/main.c:367
> 70: #16 0x7f52025761a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
> {quote}
> This leak is easily triggered by the HTTP1 adaptor but can also be triggered
> using plain AMQP.
> This is a shutdown leak. This occurs when a qdr_delivery_t is left on the
> link's updated_deliveries list at the point where the shutdown occurs.
> Since this is a shutdown leak I will add a suppression to the lsan.supp list
> for now - this Jira remains open until the issue is actually fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1962) Make LSan suppressions more targeted and specific (within reason)
[
https://issues.apache.org/jira/browse/DISPATCH-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306225#comment-17306225
]
ASF GitHub Bot commented on DISPATCH-1962:
--
kgiusti commented on pull request #1051:
URL: https://github.com/apache/qpid-dispatch/pull/1051#issuecomment-804096568
> @kgiusti I take it that this leak is extremely low priority and maybe it
makes sense to instead simply make the suppression permanent. Is that a correct
understanding?
@jiridanek Yes that would be my opinion. We should continue suppressing it
until we (someday) refactor the router shutdown process to deterministically
release all resources.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Make LSan suppressions more targeted and specific (within reason)
> -
>
> Key: DISPATCH-1962
> URL: https://issues.apache.org/jira/browse/DISPATCH-1962
> Project: Qpid Dispatch
> Issue Type: Test
>Affects Versions: 1.15.0
>Reporter: Jiri Daněk
>Priority: Major
> Attachments: dispatch_leaking_agent.png
>
>
> There are some unfortunate suppressions in {{tests/lsan.supp}} at this moment:
> {code}
> leak:*libwebsockets*
> {code}
> This is way too broad. It suppresses leaks in Dispatch files, since it
> matches e.g. {{src/http-libwebsockets.c}}.
> The stars at the beginning and end are actually assumed implicitly. If you do
> not want substring match, you have to do ^foo$. LSan suppression format is
> simplistic, very unlike Valgrind's.
> {code}
> leak:run_unit_tests.c
> {code}
> Same thing, any leaks revealed by running unit_tests get suppressed. This
> suppression suppresses all leak traces that include run_unit_tests.c anywhere
> in the stack. What't the point of running such tests under leak detector,
> then?
> {code}
> leak:run_unit_tests.c
> leak:^libqpid-proton.so$
> {code}
> Same thing. The patterns suppress all leaks that include Python (or Proton)
> anywhere in the stacktrace. That means there are huge blind spots where
> dispatch leaks can hide. This is a weakness of the lsan.supp syntax (Valgrind
> suppressions can be much more targeted and discerning).
> h3. Python leaks
> Leaks are known and there is ongoing effort to fight them:
> https://bugs.python.org/issue1635741 (https://bugs.python.org/issue25302) and
> https://www.python.org/dev/peps/pep-3121
> Here's valgrind suppression file from somebody who actually investigated the
> Python leaks and identified the harmless ones:
> https://github.com/libgit2/pygit2/blob/master/misc/valgrind-python.supp
> One example of a hidden leak in dispatch, which is revealed by making Python
> suppressions more targetted:
> {code}
> 9: Direct leak of 56 byte(s) in 1 object(s) allocated from:
> 9: #0 0x7f78a3606e8f in __interceptor_malloc
> (/nix/store/g40sl3zh3nv52vj0mrl4iki5iphh5ika-gcc-10.2.0-lib/lib/libasan.so.6+0xace8f)
> 9: #1 0x7f78a2d64afb in qd_malloc ../include/qpid/dispatch/ctools.h:229
> 9: #2 0x7f78a2d657da in qdr_core_subscribe
> ../src/router_core/route_tables.c:149
> 9: #3 0x7f78a2c83072 in IoAdapter_init ../src/python_embedded.c:711
> 9: #4 0x7f78a2353a6c in type_call
> (/nix/store/r85nxfnwiv45nbmf5yb60jj8ajim4m7w-python3-3.8.5/lib/libpython3.8.so.1.0+0x165a6c)
> {code}
> The problem is in
> {code}
> class Agent:
> ...
> def activate(self, address):
> ...
> self.io = IoAdapter(self.receive, address, 'L', '0',
> TREATMENT_ANYCAST_CLOSEST)
> {code}
> IoAdapter refers to Agent (through the bound method reference self.receive)
> and Agent refers to IoAdapter (through property self.io). Since IoAdapter is
> implemented in C and does not implement support for Python's cyclic GC, there
> is no way to break the cycle.
> Heap dump in attachment. The bound method is at the top of the picture.
> (Ignore the Mock objects, I was trying to simplify the picture while not
> getting crashes due to too much meddling).
> h3. Random observations
> It is possible to build special Debug build of Python, which has tools to
> detect leaks, asserts to prevent negative refcounts, etc.
> https://pythonextensionpatterns.readthedocs.io/en/latest/debugging/debug_python.html#debug-version-of-python-memory-alloc-label
> Use the following to detect python leaks (instead of valgrind)
> https://docs.python.org/3/library/tracemalloc.html
> Use https://pypi.org/project/objgraph (with graphviz) to view heap object
> trees. The following renders the picture as a png under /tmp and prints the
> path to stdout.
> {code}
> int ret = PyRun_SimpleString("import objgraph;
>
[GitHub] [qpid-dispatch] kgiusti commented on pull request #1051: DISPATCH-1962 Fix leak of qdr_core_subscribe
kgiusti commented on pull request #1051: URL: https://github.com/apache/qpid-dispatch/pull/1051#issuecomment-804096568 > @kgiusti I take it that this leak is extremely low priority and maybe it makes sense to instead simply make the suppression permanent. Is that a correct understanding? @jiridanek Yes that would be my opinion. We should continue suppressing it until we (someday) refactor the router shutdown process to deterministically release all resources. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2009) Cannot build on fedora F34
[
https://issues.apache.org/jira/browse/DISPATCH-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306211#comment-17306211
]
Jiri Daněk commented on DISPATCH-2009:
--
[~iboverma] https://github.com/apache/qpid-dispatch/pull/1083.patch should fix
this
> Cannot build on fedora F34
> --
>
> Key: DISPATCH-2009
> URL: https://issues.apache.org/jira/browse/DISPATCH-2009
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Affects Versions: 1.15.0
> Environment: Fedora 34,
> [armv7h|https://koji.fedoraproject.org/koji/taskinfo?taskID=64057005] and
> [i686|https://koji.fedoraproject.org/koji/taskinfo?taskID=64057006] arches
>Reporter: Irina Boverman
>Priority: Major
>
> build is broken on
> [armv7hl|https://koji.fedoraproject.org/koji/taskinfo?taskID=64057005] and
> [i686|https://koji.fedoraproject.org/koji/taskinfo?taskID=64057006] arches:
> –
> [ 5%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/adaptors/http1/http1_client.c.o
> cd /builddir/build/BUILD/qpid-dispatch-1.15.0/src && /usr/bin/gcc
> -Dqpid_dispatch_EXPORTS -I/builddir/build/BUILD/qpid-dispatch-1.15.0/include
> -I/usr/include/python3.9 -I/builddir/build/BUILD/qpid-dispatch-1.15.0/src
> -I/builddir/build/BUILD/qpid-dispatch-1.15.0/src/router_core -O2 -flto=auto
> -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=armv7-a -mfpu=vfpv3-d16
> -mtune=generic-armv7-a -mabi=aapcs-linux -mfloat-abi=hard -std=gnu99 -O2 -g
> -DNDEBUG -fPIC -Werror -Wall -Wpedantic -o
> CMakeFiles/qpid-dispatch.dir/adaptors/http1/http1_client.c.o -c
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:
> In function '_create_client_connection':
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:149:29:
> error: assignment to 'int (*)(h1_codec_request_state_t *, qd_buffer_list_t
> *, size_t, _Bool)' {aka 'int (*)(h1_codec_request_state_t *, qd_buffer_list_t
> *, unsigned int, _Bool)'} from incompatible pointer type 'int
> (*)(h1_codec_request_state_t *, qd_buffer_list_t *, uintmax_t, _Bool)' {aka
> 'int (*)(h1_codec_request_state_t *, qd_buffer_list_t *, long long unsigned
> int, _Bool)'} [-Werror=incompatible-pointer-types]
> 149 | config.rx_body = _client_rx_body_cb;
> |^
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:
> At top level:
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:848:12:
> error: conflicting types for '_client_rx_body_cb'; have
> 'int(h1_codec_request_state_t *, qd_buffer_list_t *, size_t, _Bool)' \{aka
> 'int(h1_codec_request_state_t *, qd_buffer_list_t *, unsigned int, _Bool)'}
> 848|static int _client_rx_body_cb(h1_codec_request_state_t *hrs,
> qd_buffer_list_t *body, size_t len,|
> |^~
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:109:12:
> note: previous declaration of '_client_rx_body_cb' with type
> 'int(h1_codec_request_state_t *, qd_buffer_list_t *, uintmax_t, _Bool)' \{aka
> 'int(h1_codec_request_state_t *, qd_buffer_list_t *, long long unsigned int,
> _Bool)'}
> 109|static int _client_rx_body_cb(h1_codec_request_state_t *lib_rs,
> qd_buffer_list_t *body, uintmax_t len, bool more);|
> |^~
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:109:12:
> error: '_client_rx_body_cb' used but never defined [-Werror]
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:848:12:
> error: '_client_rx_body_cb' defined but not used [-Werror=unused-function]
> 848|static int _client_rx_body_cb(h1_codec_request_state_t *hrs,
> qd_buffer_list_t *body, size_t len,|
> |^~
> cc1: all warnings being treated as errors|
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2009) Cannot build on fedora F34
[
https://issues.apache.org/jira/browse/DISPATCH-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306208#comment-17306208
]
ASF GitHub Bot commented on DISPATCH-2009:
--
jiridanek opened a new pull request #1083:
URL: https://github.com/apache/qpid-dispatch/pull/1083
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Cannot build on fedora F34
> --
>
> Key: DISPATCH-2009
> URL: https://issues.apache.org/jira/browse/DISPATCH-2009
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Affects Versions: 1.15.0
> Environment: Fedora 34,
> [armv7h|https://koji.fedoraproject.org/koji/taskinfo?taskID=64057005] and
> [i686|https://koji.fedoraproject.org/koji/taskinfo?taskID=64057006] arches
>Reporter: Irina Boverman
>Priority: Major
>
> build is broken on
> [armv7hl|https://koji.fedoraproject.org/koji/taskinfo?taskID=64057005] and
> [i686|https://koji.fedoraproject.org/koji/taskinfo?taskID=64057006] arches:
> –
> [ 5%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/adaptors/http1/http1_client.c.o
> cd /builddir/build/BUILD/qpid-dispatch-1.15.0/src && /usr/bin/gcc
> -Dqpid_dispatch_EXPORTS -I/builddir/build/BUILD/qpid-dispatch-1.15.0/include
> -I/usr/include/python3.9 -I/builddir/build/BUILD/qpid-dispatch-1.15.0/src
> -I/builddir/build/BUILD/qpid-dispatch-1.15.0/src/router_core -O2 -flto=auto
> -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=armv7-a -mfpu=vfpv3-d16
> -mtune=generic-armv7-a -mabi=aapcs-linux -mfloat-abi=hard -std=gnu99 -O2 -g
> -DNDEBUG -fPIC -Werror -Wall -Wpedantic -o
> CMakeFiles/qpid-dispatch.dir/adaptors/http1/http1_client.c.o -c
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:
> In function '_create_client_connection':
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:149:29:
> error: assignment to 'int (*)(h1_codec_request_state_t *, qd_buffer_list_t
> *, size_t, _Bool)' {aka 'int (*)(h1_codec_request_state_t *, qd_buffer_list_t
> *, unsigned int, _Bool)'} from incompatible pointer type 'int
> (*)(h1_codec_request_state_t *, qd_buffer_list_t *, uintmax_t, _Bool)' {aka
> 'int (*)(h1_codec_request_state_t *, qd_buffer_list_t *, long long unsigned
> int, _Bool)'} [-Werror=incompatible-pointer-types]
> 149 | config.rx_body = _client_rx_body_cb;
> |^
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:
> At top level:
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:848:12:
> error: conflicting types for '_client_rx_body_cb'; have
> 'int(h1_codec_request_state_t *, qd_buffer_list_t *, size_t, _Bool)' \{aka
> 'int(h1_codec_request_state_t *, qd_buffer_list_t *, unsigned int, _Bool)'}
> 848|static int _client_rx_body_cb(h1_codec_request_state_t *hrs,
> qd_buffer_list_t *body, size_t len,|
> |^~
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:109:12:
> note: previous declaration of '_client_rx_body_cb' with type
> 'int(h1_codec_request_state_t *, qd_buffer_list_t *, uintmax_t, _Bool)' \{aka
> 'int(h1_codec_request_state_t *, qd_buffer_list_t *, long long unsigned int,
> _Bool)'}
> 109|static int _client_rx_body_cb(h1_codec_request_state_t *lib_rs,
> qd_buffer_list_t *body, uintmax_t len, bool more);|
> |^~
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:109:12:
> error: '_client_rx_body_cb' used but never defined [-Werror]
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:848:12:
> error: '_client_rx_body_cb' defined but not used [-Werror=unused-function]
> 848|static int _client_rx_body_cb(h1_codec_request_state_t *hrs,
> qd_buffer_list_t *body, size_t len,|
> |^~
> cc1: all warnings being treated as errors|
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] jiridanek opened a new pull request #1083: DISPATCH-2009 Fix printf format specifier for size_t in buffer_test.c
jiridanek opened a new pull request #1083: URL: https://github.com/apache/qpid-dispatch/pull/1083 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-2009) Cannot build on fedora F34
[
https://issues.apache.org/jira/browse/DISPATCH-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306189#comment-17306189
]
Irina Boverman commented on DISPATCH-2009:
--
I applied a number of patches from master, and now only have 1 warning:
[ 81%] Building C object tests/CMakeFiles/unit_tests_size.dir/buffer_test.c.o
cd /builddir/build/BUILD/qpid-dispatch-1.15.0/tests && /usr/bin/gcc
-I/builddir/build/BUILD/qpid-dispatch-1.15.0/include -I/usr/include/python3.9
-I/builddir/build/BUILD/qpid-dispatch-1.15.0/src -O2 -flto=auto
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=armv7-a -mfpu=vfpv3-d16
-mtune=generic-armv7-a -mabi=aapcs-linux -mfloat-abi=hard -std=gnu99 -O2 -g
-DNDEBUG -Werror -Wall -Wpedantic -o
CMakeFiles/unit_tests_size.dir/buffer_test.c.o -c
/builddir/build/BUILD/qpid-dispatch-1.15.0/tests/buffer_test.c
/builddir/build/BUILD/qpid-dispatch-1.15.0/tests/buffer_test.c: In function
'test_buffer_list_append':
/builddir/build/BUILD/qpid-dispatch-1.15.0/tests/buffer_test.c:116:62: error:
format '%ld' expects argument of type 'long int', but argument 3 has type
'size_t' \{aka 'unsigned int'} [-Werror=format=]
116 | sprintf(error, "Incorrect accumulated buffer size: %ld", list_len);
| ~~^
| | |
| | size_t \{aka unsigned int}
| long int
| %d
cc1: all warnings being treated as errors
> Cannot build on fedora F34
> --
>
> Key: DISPATCH-2009
> URL: https://issues.apache.org/jira/browse/DISPATCH-2009
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Protocol Adaptors
>Affects Versions: 1.15.0
> Environment: Fedora 34,
> [armv7h|https://koji.fedoraproject.org/koji/taskinfo?taskID=64057005] and
> [i686|https://koji.fedoraproject.org/koji/taskinfo?taskID=64057006] arches
>Reporter: Irina Boverman
>Priority: Major
>
> build is broken on
> [armv7hl|https://koji.fedoraproject.org/koji/taskinfo?taskID=64057005] and
> [i686|https://koji.fedoraproject.org/koji/taskinfo?taskID=64057006] arches:
> –
> [ 5%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/adaptors/http1/http1_client.c.o
> cd /builddir/build/BUILD/qpid-dispatch-1.15.0/src && /usr/bin/gcc
> -Dqpid_dispatch_EXPORTS -I/builddir/build/BUILD/qpid-dispatch-1.15.0/include
> -I/usr/include/python3.9 -I/builddir/build/BUILD/qpid-dispatch-1.15.0/src
> -I/builddir/build/BUILD/qpid-dispatch-1.15.0/src/router_core -O2 -flto=auto
> -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -march=armv7-a -mfpu=vfpv3-d16
> -mtune=generic-armv7-a -mabi=aapcs-linux -mfloat-abi=hard -std=gnu99 -O2 -g
> -DNDEBUG -fPIC -Werror -Wall -Wpedantic -o
> CMakeFiles/qpid-dispatch.dir/adaptors/http1/http1_client.c.o -c
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:
> In function '_create_client_connection':
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:149:29:
> error: assignment to 'int (*)(h1_codec_request_state_t *, qd_buffer_list_t
> *, size_t, _Bool)' {aka 'int (*)(h1_codec_request_state_t *, qd_buffer_list_t
> *, unsigned int, _Bool)'} from incompatible pointer type 'int
> (*)(h1_codec_request_state_t *, qd_buffer_list_t *, uintmax_t, _Bool)' {aka
> 'int (*)(h1_codec_request_state_t *, qd_buffer_list_t *, long long unsigned
> int, _Bool)'} [-Werror=incompatible-pointer-types]
> 149 | config.rx_body = _client_rx_body_cb;
> |^
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:
> At top level:
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:848:12:
> error: conflicting types for '_client_rx_body_cb'; have
> 'int(h1_codec_request_state_t *, qd_buffer_list_t *, size_t, _Bool)' \{aka
> 'int(h1_codec_request_state_t *, qd_buffer_list_t *, unsigned int, _Bool)'}
> 848|static int _client_rx_body_cb(h1_codec_request_state_t *hrs,
> qd_buffer_list_t *body, size_t len,|
> |^~
>
> /builddir/build/BUILD/qpid-dispatch-1.15.0/src/adaptors/http1/http1_client.c:109:12:
> note: previous declaration of '_client_rx_body_cb' with type
> 'int(h1_codec_request_state_t *, qd_buffer_list_t *, uintmax_t, _Bool)' \{aka
> 'int(h1_codec_request_state_t *, qd_buffer_list_t *, long long unsigned int,
> _Bool)'}
> 109|static int _client_rx_body_cb(h1_codec_request_state_t *lib_rs,
[jira] [Commented] (DISPATCH-1997) Cannot build on fedora rawhide
[
https://issues.apache.org/jira/browse/DISPATCH-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306169#comment-17306169
]
ASF GitHub Bot commented on DISPATCH-1997:
--
jiridanek opened a new pull request #1082:
URL: https://github.com/apache/qpid-dispatch/pull/1082
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Cannot build on fedora rawhide
> --
>
> Key: DISPATCH-1997
> URL: https://issues.apache.org/jira/browse/DISPATCH-1997
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.14.0
> Environment: | || |
>Reporter: Irina Boverman
>Assignee: Jiri Daněk
>Priority: Major
> Fix For: 1.16.0
>
>
> Reproducible on master:
> sudo docker run -it fedora:rawhide bash
> dnf install make gcc cmake git valgrind swig pkgconfig doxygen libuuid-devel
> openssl-devel asciidoc libwebsockets-devel python3 python3-devel
> cyrus-sasl-devel cyrus-sasl-lib cyrus-sasl-gssapi cyrus-sasl-plain
> cyrus-sasl-md5 cyrus-sasl-scram java-1.8.0-openjdk maven ruby-devel
> rubygem-rspec rubygem-simplecov python3-tox libnghttp2-devel
> qpid-proton-c-devel
> git clone [https://gitbox.apache.org/repos/asf/qpid-dispatch.git]
> apache-qpid-dispatch
> cd apache-qpid-dispatch/
> cmake .
> make
> ...
> {noformat}
> [ 94%] Building CXX object
> tests/c_unittests/CMakeFiles/c_unittests.dir/c_unittests_main.cpp.o
> In file included from
> /root/apache-qpid-dispatch/tests/c_unittests/qdr_doctest.h:25,
> from /root/apache-qpid-dispatch/tests/c_unittests/c_unittests_main.cpp:21:
> /root/apache-qpid-dispatch/tests/c_unittests/doctest.h:4008:47: error: size
> of array 'altStackMem' is not an integral constant-expression
> 4008 | static char altStackMem[4 * SIGSTKSZ];
> |^
> make[2]: *** [tests/c_unittests/CMakeFiles/c_unittests.dir/build.make:82:
> tests/c_unittests/CMakeFiles/c_unittests.dir/c_unittests_main.cpp.o] Error 1
> make[1]: *** [CMakeFiles/Makefile2:1234:
> tests/c_unittests/CMakeFiles/c_unittests.dir/all] Error 2
> make: *** [Makefile:160: all] Error 2|
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-dispatch] jiridanek opened a new pull request #1082: DISPATCH-1997 Update Doctest from 2.3.6 to 2.4.6 to resolve Rawhide compilation failure
jiridanek opened a new pull request #1082: URL: https://github.com/apache/qpid-dispatch/pull/1082 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8512) QPID threads hang on shutdown
[
https://issues.apache.org/jira/browse/QPID-8512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik updated QPID-8512:
--
Description:
QPID Threads in the client hang on shutdown. This issue seems to specifically
occur in SLES 15 SP2 (SuSE Linux Service Pack 2). It was working fine on SLES
15 SP1 and older versions like SLES11, 12 etc.
QPID Client/Broker Version: 0.8
On debugging into the QPID code, observed that the hang occurs in this function
and in the ::epoll_wait call.
*Code-Reference*:
{{*qpid/sys/epoll/EpollPoller.cpp*}}
{{Poller::Event Poller::wait(Duration timeout) {}}
{{ .}}{{..}}
{{ *int rc = ::epoll_wait(impl->epollFd, , 1, timeoutMs);*}}
{{ ...}}
{{}}}
Thread backtrace on shutdown which hang:
{{Thread }}{{8}} {{(Thread }}{{0x7fffe27fc700}} {{(LWP }}{{29944}}{{)):}}
{{#}}{{0}} {{0x72dff126}} {{in epoll_pwait () from
/lib64/libc.so.}}{{6}}
{{#}}{{1}} {{0x75abc461}} {{in qpid::sys::Poller::wait
(}}{{this}}{{=}}{{0x6eb230}}{{, timeout=...) at
qpid/sys/epoll/EpollPoller.cpp:}}{{568}}
{{#}}{{2}} {{0x75abcf31}} {{in qpid::sys::Poller::run
(}}{{this}}{{=}}{{0x6eb230}}{{) at qpid/sys/epoll/EpollPoller.cpp:}}{{518}}
{{#}}{{3}} {{0x75ab3caa}} {{in qpid::sys::(anonymous
namespace)::runRunnable (p=}}{{0x6}}{{) at qpid/sys/posix/Thread.cpp:}}{{35}}
{{#}}{{4}} {{0x777b44f9}} {{in start_thread () from
/lib64/libpthread.so.}}{{0}}
{{#}}{{5}} {{0x72dfefbf}} {{in clone () from /lib64/libc.so.}}{{6}}
{{Thread }}{{3}} {{(Thread }}{{0x71681700}} {{(LWP }}{{29939}}{{)):}}
{{#}}{{0}} {{0x72dff126}} {{in epoll_pwait () from
/lib64/libc.so.}}{{6}}
{{#}}{{1}} {{0x75abc461}} {{in qpid::sys::Poller::wait
(}}{{this}}{{=}}{{0x6eb230}}{{, timeout=...) at
qpid/sys/epoll/EpollPoller.cpp:}}{{568}}
{{#}}{{2}} {{0x75abcf31}} {{in qpid::sys::Poller::run
(}}{{this}}{{=}}{{0x6eb230}}{{) at qpid/sys/epoll/EpollPoller.cpp:}}{{518}}
{{#}}{{3}} {{0x75ab3caa}} {{in qpid::sys::(anonymous
namespace)::runRunnable (p=}}{{0x6}}{{) at qpid/sys/posix/Thread.cpp:}}{{35}}
{{#}}{{4}} {{0x777b44f9}} {{in start_thread () from
/lib64/libpthread.so.}}{{0}}
{{#}}{{5}} {{0x72dfefbf}} {{in clone () from /lib64/libc.so.}}{{6}}
{{Thread }}{{1}} {{(Thread }}{{0x77fb97c0}} {{(LWP }}{{29842}}{{)):}}
{{#}}{{0}} {{0x777b58bd}} {{in pthread_join () from
/lib64/libpthread.so.}}{{0}}
{{#}}{{1}} {{0x75ab3db3}} {{in qpid::sys::Thread::join
(}}{{this}}{{=) at qpid/sys/posix/Thread.cpp:}}{{70}}
{{#}}{{2}} {{0x75716b09}} {{in qpid::client::(anonymous
namespace)::IOThread::~IOThread (}}{{this}}{{=}}{{0x7597b6a0}}
{{, __in_chrg=) at qpid/client/ConnectionImpl.cpp:}}{{140}}
{{#}}{{3}} {{0x72d3f138}} {{in __run_exit_handlers () from
/lib64/libc.so.}}{{6}}
{{#}}{{4}} {{0x72d3f18a}} {{in exit () from /lib64/libc.so.}}{{6}}
{{#}}{{5}} {{0x72d27351}} {{in __libc_start_main () from
/lib64/libc.so.}}{{6}}
{{#}}{{6}} {{0x0040f179}} {{in _start () at
../sysdeps/x86_64/elf/start.S:}}{{113}}
was:
QPID Threads in the client hang on shutdown. This issue seems to specifically
occur in SLES 12 SP2 (SuSE Linux Service Pack 2). It was working fine on SLES
15 SP1 and older versions like SLES11, 12 etc.
QPID Client/Broker Version: 0.8
On debugging into the QPID code, observed that the hang occurs in this function
and in the ::epoll_wait call.
*Code-Reference*:
{{*qpid/sys/epoll/EpollPoller.cpp*}}
{{Poller::Event Poller::wait(Duration timeout) {}}
{{ .}}{{..}}
{{ *int rc = ::epoll_wait(impl->epollFd, , 1, timeoutMs);*}}
{{ ...}}
{{}}}
Thread backtrace on shutdown which hang:
{{Thread }}{{8}} {{(Thread }}{{0x7fffe27fc700}} {{(LWP }}{{29944}}{{)):}}
{{#}}{{0}} {{0x72dff126}} {{in epoll_pwait () from
/lib64/libc.so.}}{{6}}
{{#}}{{1}} {{0x75abc461}} {{in qpid::sys::Poller::wait
(}}{{this}}{{=}}{{0x6eb230}}{{, timeout=...) at
qpid/sys/epoll/EpollPoller.cpp:}}{{568}}
{{#}}{{2}} {{0x75abcf31}} {{in qpid::sys::Poller::run
(}}{{this}}{{=}}{{0x6eb230}}{{) at qpid/sys/epoll/EpollPoller.cpp:}}{{518}}
{{#}}{{3}} {{0x75ab3caa}} {{in qpid::sys::(anonymous
namespace)::runRunnable (p=}}{{0x6}}{{) at qpid/sys/posix/Thread.cpp:}}{{35}}
{{#}}{{4}} {{0x777b44f9}} {{in start_thread () from
/lib64/libpthread.so.}}{{0}}
{{#}}{{5}} {{0x72dfefbf}} {{in clone () from /lib64/libc.so.}}{{6}}
{{Thread }}{{3}} {{(Thread }}{{0x71681700}} {{(LWP }}{{29939}}{{)):}}
{{#}}{{0}} {{0x72dff126}} {{in epoll_pwait () from
/lib64/libc.so.}}{{6}}
{{#}}{{1}} {{0x75abc461}} {{in qpid::sys::Poller::wait
(}}{{this}}{{=}}{{0x6eb230}}{{, timeout=...) at
qpid/sys/epoll/EpollPoller.cpp:}}{{568}}
{{#}}{{2}} {{0x75abcf31}} {{in qpid::sys::Poller::run
[jira] [Updated] (DISPATCH-1997) Cannot build on fedora rawhide
[
https://issues.apache.org/jira/browse/DISPATCH-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk updated DISPATCH-1997:
-
Environment: | || | (was: | |)
> Cannot build on fedora rawhide
> --
>
> Key: DISPATCH-1997
> URL: https://issues.apache.org/jira/browse/DISPATCH-1997
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.14.0
> Environment: | || |
>Reporter: Irina Boverman
>Assignee: Jiri Daněk
>Priority: Major
> Fix For: 1.16.0
>
>
> Reproducible on master:
> sudo docker run -it fedora:rawhide bash
> dnf install make gcc cmake git valgrind swig pkgconfig doxygen libuuid-devel
> openssl-devel asciidoc libwebsockets-devel python3 python3-devel
> cyrus-sasl-devel cyrus-sasl-lib cyrus-sasl-gssapi cyrus-sasl-plain
> cyrus-sasl-md5 cyrus-sasl-scram java-1.8.0-openjdk maven ruby-devel
> rubygem-rspec rubygem-simplecov python3-tox libnghttp2-devel
> qpid-proton-c-devel
> git clone [https://gitbox.apache.org/repos/asf/qpid-dispatch.git]
> apache-qpid-dispatch
> cd apache-qpid-dispatch/
> cmake .
> make
> ...
> {noformat}
> [ 94%] Building CXX object
> tests/c_unittests/CMakeFiles/c_unittests.dir/c_unittests_main.cpp.o
> In file included from
> /root/apache-qpid-dispatch/tests/c_unittests/qdr_doctest.h:25,
> from /root/apache-qpid-dispatch/tests/c_unittests/c_unittests_main.cpp:21:
> /root/apache-qpid-dispatch/tests/c_unittests/doctest.h:4008:47: error: size
> of array 'altStackMem' is not an integral constant-expression
> 4008 | static char altStackMem[4 * SIGSTKSZ];
> |^
> make[2]: *** [tests/c_unittests/CMakeFiles/c_unittests.dir/build.make:82:
> tests/c_unittests/CMakeFiles/c_unittests.dir/c_unittests_main.cpp.o] Error 1
> make[1]: *** [CMakeFiles/Makefile2:1234:
> tests/c_unittests/CMakeFiles/c_unittests.dir/all] Error 2
> make: *** [Makefile:160: all] Error 2|
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1997) Cannot build on fedora rawhide
[
https://issues.apache.org/jira/browse/DISPATCH-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk reassigned DISPATCH-1997:
Assignee: Jiri Daněk
> Cannot build on fedora rawhide
> --
>
> Key: DISPATCH-1997
> URL: https://issues.apache.org/jira/browse/DISPATCH-1997
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.14.0
> Environment: | |
>Reporter: Irina Boverman
>Assignee: Jiri Daněk
>Priority: Major
>
> Reproducible on master:
> sudo docker run -it fedora:rawhide bash
> dnf install make gcc cmake git valgrind swig pkgconfig doxygen libuuid-devel
> openssl-devel asciidoc libwebsockets-devel python3 python3-devel
> cyrus-sasl-devel cyrus-sasl-lib cyrus-sasl-gssapi cyrus-sasl-plain
> cyrus-sasl-md5 cyrus-sasl-scram java-1.8.0-openjdk maven ruby-devel
> rubygem-rspec rubygem-simplecov python3-tox libnghttp2-devel
> qpid-proton-c-devel
> git clone [https://gitbox.apache.org/repos/asf/qpid-dispatch.git]
> apache-qpid-dispatch
> cd apache-qpid-dispatch/
> cmake .
> make
> ...
> {noformat}
> [ 94%] Building CXX object
> tests/c_unittests/CMakeFiles/c_unittests.dir/c_unittests_main.cpp.o
> In file included from
> /root/apache-qpid-dispatch/tests/c_unittests/qdr_doctest.h:25,
> from /root/apache-qpid-dispatch/tests/c_unittests/c_unittests_main.cpp:21:
> /root/apache-qpid-dispatch/tests/c_unittests/doctest.h:4008:47: error: size
> of array 'altStackMem' is not an integral constant-expression
> 4008 | static char altStackMem[4 * SIGSTKSZ];
> |^
> make[2]: *** [tests/c_unittests/CMakeFiles/c_unittests.dir/build.make:82:
> tests/c_unittests/CMakeFiles/c_unittests.dir/c_unittests_main.cpp.o] Error 1
> make[1]: *** [CMakeFiles/Makefile2:1234:
> tests/c_unittests/CMakeFiles/c_unittests.dir/all] Error 2
> make: *** [Makefile:160: all] Error 2|
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1997) Cannot build on fedora rawhide
[
https://issues.apache.org/jira/browse/DISPATCH-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk updated DISPATCH-1997:
-
Fix Version/s: 1.16.0
> Cannot build on fedora rawhide
> --
>
> Key: DISPATCH-1997
> URL: https://issues.apache.org/jira/browse/DISPATCH-1997
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.14.0
> Environment: | |
>Reporter: Irina Boverman
>Assignee: Jiri Daněk
>Priority: Major
> Fix For: 1.16.0
>
>
> Reproducible on master:
> sudo docker run -it fedora:rawhide bash
> dnf install make gcc cmake git valgrind swig pkgconfig doxygen libuuid-devel
> openssl-devel asciidoc libwebsockets-devel python3 python3-devel
> cyrus-sasl-devel cyrus-sasl-lib cyrus-sasl-gssapi cyrus-sasl-plain
> cyrus-sasl-md5 cyrus-sasl-scram java-1.8.0-openjdk maven ruby-devel
> rubygem-rspec rubygem-simplecov python3-tox libnghttp2-devel
> qpid-proton-c-devel
> git clone [https://gitbox.apache.org/repos/asf/qpid-dispatch.git]
> apache-qpid-dispatch
> cd apache-qpid-dispatch/
> cmake .
> make
> ...
> {noformat}
> [ 94%] Building CXX object
> tests/c_unittests/CMakeFiles/c_unittests.dir/c_unittests_main.cpp.o
> In file included from
> /root/apache-qpid-dispatch/tests/c_unittests/qdr_doctest.h:25,
> from /root/apache-qpid-dispatch/tests/c_unittests/c_unittests_main.cpp:21:
> /root/apache-qpid-dispatch/tests/c_unittests/doctest.h:4008:47: error: size
> of array 'altStackMem' is not an integral constant-expression
> 4008 | static char altStackMem[4 * SIGSTKSZ];
> |^
> make[2]: *** [tests/c_unittests/CMakeFiles/c_unittests.dir/build.make:82:
> tests/c_unittests/CMakeFiles/c_unittests.dir/c_unittests_main.cpp.o] Error 1
> make[1]: *** [CMakeFiles/Makefile2:1234:
> tests/c_unittests/CMakeFiles/c_unittests.dir/all] Error 2
> make: *** [Makefile:160: all] Error 2|
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1962) Make LSan suppressions more targeted and specific (within reason)
[
https://issues.apache.org/jira/browse/DISPATCH-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305980#comment-17305980
]
ASF GitHub Bot commented on DISPATCH-1962:
--
jiridanek commented on a change in pull request #1080:
URL: https://github.com/apache/qpid-dispatch/pull/1080#discussion_r598504299
##
File path: src/server.c
##
@@ -1372,6 +1372,10 @@ qd_server_t *qd_server(qd_dispatch_t *qd, int
thread_count, const char *containe
void qd_server_free(qd_server_t *qd_server)
{
if (!qd_server) return;
+
+qd_http_server_stop(qd_server->http); /* Stop HTTP threads immediately */
+qd_http_server_free(qd_server->http);
Review comment:
It appears that calling only `qd_http_server_free` is indeed sufficient.
I was thinking that maybe calling _stop before _free is some sort of dispatch
convention... Do you want me to remove the call to _stop here?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Make LSan suppressions more targeted and specific (within reason)
> -
>
> Key: DISPATCH-1962
> URL: https://issues.apache.org/jira/browse/DISPATCH-1962
> Project: Qpid Dispatch
> Issue Type: Test
>Affects Versions: 1.15.0
>Reporter: Jiri Daněk
>Priority: Major
> Attachments: dispatch_leaking_agent.png
>
>
> There are some unfortunate suppressions in {{tests/lsan.supp}} at this moment:
> {code}
> leak:*libwebsockets*
> {code}
> This is way too broad. It suppresses leaks in Dispatch files, since it
> matches e.g. {{src/http-libwebsockets.c}}.
> The stars at the beginning and end are actually assumed implicitly. If you do
> not want substring match, you have to do ^foo$. LSan suppression format is
> simplistic, very unlike Valgrind's.
> {code}
> leak:run_unit_tests.c
> {code}
> Same thing, any leaks revealed by running unit_tests get suppressed. This
> suppression suppresses all leak traces that include run_unit_tests.c anywhere
> in the stack. What't the point of running such tests under leak detector,
> then?
> {code}
> leak:run_unit_tests.c
> leak:^libqpid-proton.so$
> {code}
> Same thing. The patterns suppress all leaks that include Python (or Proton)
> anywhere in the stacktrace. That means there are huge blind spots where
> dispatch leaks can hide. This is a weakness of the lsan.supp syntax (Valgrind
> suppressions can be much more targeted and discerning).
> h3. Python leaks
> Leaks are known and there is ongoing effort to fight them:
> https://bugs.python.org/issue1635741 (https://bugs.python.org/issue25302) and
> https://www.python.org/dev/peps/pep-3121
> Here's valgrind suppression file from somebody who actually investigated the
> Python leaks and identified the harmless ones:
> https://github.com/libgit2/pygit2/blob/master/misc/valgrind-python.supp
> One example of a hidden leak in dispatch, which is revealed by making Python
> suppressions more targetted:
> {code}
> 9: Direct leak of 56 byte(s) in 1 object(s) allocated from:
> 9: #0 0x7f78a3606e8f in __interceptor_malloc
> (/nix/store/g40sl3zh3nv52vj0mrl4iki5iphh5ika-gcc-10.2.0-lib/lib/libasan.so.6+0xace8f)
> 9: #1 0x7f78a2d64afb in qd_malloc ../include/qpid/dispatch/ctools.h:229
> 9: #2 0x7f78a2d657da in qdr_core_subscribe
> ../src/router_core/route_tables.c:149
> 9: #3 0x7f78a2c83072 in IoAdapter_init ../src/python_embedded.c:711
> 9: #4 0x7f78a2353a6c in type_call
> (/nix/store/r85nxfnwiv45nbmf5yb60jj8ajim4m7w-python3-3.8.5/lib/libpython3.8.so.1.0+0x165a6c)
> {code}
> The problem is in
> {code}
> class Agent:
> ...
> def activate(self, address):
> ...
> self.io = IoAdapter(self.receive, address, 'L', '0',
> TREATMENT_ANYCAST_CLOSEST)
> {code}
> IoAdapter refers to Agent (through the bound method reference self.receive)
> and Agent refers to IoAdapter (through property self.io). Since IoAdapter is
> implemented in C and does not implement support for Python's cyclic GC, there
> is no way to break the cycle.
> Heap dump in attachment. The bound method is at the top of the picture.
> (Ignore the Mock objects, I was trying to simplify the picture while not
> getting crashes due to too much meddling).
> h3. Random observations
> It is possible to build special Debug build of Python, which has tools to
> detect leaks, asserts to prevent negative refcounts, etc.
> https://pythonextensionpatterns.readthedocs.io/en/latest/debugging/debug_python.html#debug-version-of-python-memory-alloc-label
> Use the following to detect python leaks (instead of valgrind)
> https://docs.python.org/3/library/tracemalloc.html
> Use
[GitHub] [qpid-dispatch] jiridanek commented on a change in pull request #1080: DISPATCH-1962 Fix leak from libwebsockets.so in unit_tests
jiridanek commented on a change in pull request #1080:
URL: https://github.com/apache/qpid-dispatch/pull/1080#discussion_r598504299
##
File path: src/server.c
##
@@ -1372,6 +1372,10 @@ qd_server_t *qd_server(qd_dispatch_t *qd, int
thread_count, const char *containe
void qd_server_free(qd_server_t *qd_server)
{
if (!qd_server) return;
+
+qd_http_server_stop(qd_server->http); /* Stop HTTP threads immediately */
+qd_http_server_free(qd_server->http);
Review comment:
It appears that calling only `qd_http_server_free` is indeed sufficient.
I was thinking that maybe calling _stop before _free is some sort of dispatch
convention... Do you want me to remove the call to _stop here?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
