[jira] [Commented] (PROTON-610) proton-c: messenger doesn't honour an advertised remote idle timeout
[ https://issues.apache.org/jira/browse/PROTON-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047440#comment-14047440 ] Robert Nicholson commented on PROTON-610: - This issue prevents standard messenger clients from working correctly with IBM MQ Light which uses AMQP. The issue seems to be relatively simple - non compliance with the spec and Dom has provided a patch. It would be great if one of the project committers can have a look at the patch and either commit it or provide feedback on the patch. Thanks. proton-c: messenger doesn't honour an advertised remote idle timeout Key: PROTON-610 URL: https://issues.apache.org/jira/browse/PROTON-610 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 0001-ensure-messenger-honours-remote-idle-timeout.patch The changes under PROTON-111 added support to the underlying proton engine for honouring a remote idle timeout (as per the AMQP 1.0 spec) and sending empty null frames on a heartbeat interval to prevent the idle timeout expiring (and hence causing the client to be disconnect), However, the Messenger API doesn't currently drive the same behaviour and so will be disconnected from any broker that has implemented such a timeout. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-576) proton-j: codec support for UTF-8 encoding and decoding appears broken?
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominic Evans updated PROTON-576:
-
Attachment: (was: benchmark-src.zip)
proton-j: codec support for UTF-8 encoding and decoding appears broken?
---
Key: PROTON-576
URL: https://issues.apache.org/jira/browse/PROTON-576
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: 0.7
Reporter: Dominic Evans
It seems like Proton-J has its own custom UTF-8 encoder, but relies on Java
String's built-in UTF-8 decoder. However, the code doesn't seem quite right
and complex double byte UTF-8 like emoji ('') can quite easily fail to
parse:
| | Cause:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | Message:1 :- Cannot parse String
| | StackTrace:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:48)
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:36)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readRaw(DecoderImpl.java:945)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:172)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:124)
| | at
org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:39)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885)
| | at
org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:629)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (PROTON-576) proton-j: codec support for UTF-8 encoding and decoding appears broken?
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominic Evans updated PROTON-576:
-
Attachment: (was: 02_fix_stringtype_encode_decode.patch)
proton-j: codec support for UTF-8 encoding and decoding appears broken?
---
Key: PROTON-576
URL: https://issues.apache.org/jira/browse/PROTON-576
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: 0.7
Reporter: Dominic Evans
It seems like Proton-J has its own custom UTF-8 encoder, but relies on Java
String's built-in UTF-8 decoder. However, the code doesn't seem quite right
and complex double byte UTF-8 like emoji ('') can quite easily fail to
parse:
| | Cause:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | Message:1 :- Cannot parse String
| | StackTrace:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:48)
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:36)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readRaw(DecoderImpl.java:945)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:172)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:124)
| | at
org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:39)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885)
| | at
org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:629)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (PROTON-576) proton-j: codec support for UTF-8 encoding and decoding appears broken?
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominic Evans updated PROTON-576:
-
Attachment: (was: Utf8Samples.txt)
proton-j: codec support for UTF-8 encoding and decoding appears broken?
---
Key: PROTON-576
URL: https://issues.apache.org/jira/browse/PROTON-576
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: 0.7
Reporter: Dominic Evans
It seems like Proton-J has its own custom UTF-8 encoder, but relies on Java
String's built-in UTF-8 decoder. However, the code doesn't seem quite right
and complex double byte UTF-8 like emoji ('') can quite easily fail to
parse:
| | Cause:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | Message:1 :- Cannot parse String
| | StackTrace:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:48)
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:36)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readRaw(DecoderImpl.java:945)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:172)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:124)
| | at
org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:39)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885)
| | at
org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:629)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (PROTON-576) proton-j: codec support for UTF-8 encoding and decoding appears broken?
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominic Evans updated PROTON-576:
-
Attachment: (was: benchmark.jar)
proton-j: codec support for UTF-8 encoding and decoding appears broken?
---
Key: PROTON-576
URL: https://issues.apache.org/jira/browse/PROTON-576
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: 0.7
Reporter: Dominic Evans
It seems like Proton-J has its own custom UTF-8 encoder, but relies on Java
String's built-in UTF-8 decoder. However, the code doesn't seem quite right
and complex double byte UTF-8 like emoji ('') can quite easily fail to
parse:
| | Cause:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | Message:1 :- Cannot parse String
| | StackTrace:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:48)
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:36)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readRaw(DecoderImpl.java:945)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:172)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:124)
| | at
org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:39)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885)
| | at
org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:629)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (PROTON-576) proton-j: codec support for UTF-8 encoding and decoding appears broken?
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominic Evans updated PROTON-576:
-
Attachment: 02_fix_stringtype_encode_decode.patch
Updated patch that also contains a StringTypeTest.java unittest that loops over
all the unicode characters in some complex ranges of the spec and attempts to
round-trip them as an AmqpValue.
The testcase fails against vanilld qpid-proton 0.7, but passes successfully
after applying the accompanying patches.
[~clebertsuconic] are you able to review and accept?
proton-j: codec support for UTF-8 encoding and decoding appears broken?
---
Key: PROTON-576
URL: https://issues.apache.org/jira/browse/PROTON-576
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: 0.7
Reporter: Dominic Evans
Attachments: 02_fix_stringtype_encode_decode.patch
It seems like Proton-J has its own custom UTF-8 encoder, but relies on Java
String's built-in UTF-8 decoder. However, the code doesn't seem quite right
and complex double byte UTF-8 like emoji ('') can quite easily fail to
parse:
| | Cause:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | Message:1 :- Cannot parse String
| | StackTrace:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:48)
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:36)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readRaw(DecoderImpl.java:945)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:172)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:124)
| | at
org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:39)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885)
| | at
org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:629)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (PROTON-623) Add missing error check to pn_string_inspect
Bozo Dragojevic created PROTON-623: -- Summary: Add missing error check to pn_string_inspect Key: PROTON-623 URL: https://issues.apache.org/jira/browse/PROTON-623 Project: Qpid Proton Issue Type: Bug Reporter: Bozo Dragojevic Found by XCode Analyze -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-622) Add missing error check to pn_event_inspect
[ https://issues.apache.org/jira/browse/PROTON-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bozo Dragojevic updated PROTON-622: --- Attachment: 0002-PROTON-622-Add-missing-error-check-to-pn_event_inspe.patch Add missing error check to pn_event_inspect --- Key: PROTON-622 URL: https://issues.apache.org/jira/browse/PROTON-622 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Bozo Dragojevic Priority: Trivial Attachments: 0002-PROTON-622-Add-missing-error-check-to-pn_event_inspe.patch Found by XCode Analyze -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-623) Add missing error check to pn_string_inspect
[ https://issues.apache.org/jira/browse/PROTON-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bozo Dragojevic updated PROTON-623: --- Attachment: 0001-PROTON-623-Add-missing-error-check-to-pn_string_insp.patch Trivial patch appended Add missing error check to pn_string_inspect Key: PROTON-623 URL: https://issues.apache.org/jira/browse/PROTON-623 Project: Qpid Proton Issue Type: Bug Reporter: Bozo Dragojevic Attachments: 0001-PROTON-623-Add-missing-error-check-to-pn_string_insp.patch Found by XCode Analyze -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Heads Up: location of config.sh has changed
On Fri, 2014-06-27 at 12:08 -0400, Andrew Stitcher wrote: As part of QPID-619 [1]. The location of the developer script config.sh has changed from the source tree to the build tree. The runnable config.sh is now built by cmake as part of the tree configuration. This allows the script to set the correct variables without using fallible heuristics. If this trips anyone up. or you have questions, comments etc. reply here (and/or on the JIRA itself). Andrew [1] https://issues.apache.org/jira/browse/PROTON-619 A while back I added tests/run.py, a python test runner that has similar config data to config.sh. It will generate something like config.sh if you do run.py --sh. Perhaps we should integrate the two. Are your changes already on trunk? I didn't see them as of r1605648 | NO-JIRA: Fix python system tests to work on python 2.5.
[jira] [Commented] (PROTON-619) The heuristics in config.sh don't work for all build directory locations
[ https://issues.apache.org/jira/browse/PROTON-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048080#comment-14048080 ] Andrew Stitcher commented on PROTON-619: Change is here (with bad comment so not picked up automatically) https://svn.apache.org/r1606140 The heuristics in config.sh don't work for all build directory locations Key: PROTON-619 URL: https://issues.apache.org/jira/browse/PROTON-619 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.7 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.8 The config.sh script is used to set shell variables which allow developers to run various proton language bindings libraries from the build area. Currently it is a fixed script in the source tree, so it can't know for sure where the build tree and hence the built libraries actually are. If we used the build system to generate the file from a template then we could make it work without using fallible heuristics. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Heads Up: location of config.sh has changed
On Mon, 2014-06-30 at 14:56 -0400, Alan Conway wrote: On Fri, 2014-06-27 at 12:08 -0400, Andrew Stitcher wrote: As part of QPID-619 [1]. The location of the developer script config.sh has changed from the source tree to the build tree. The runnable config.sh is now built by cmake as part of the tree configuration. This allows the script to set the correct variables without using fallible heuristics. If this trips anyone up. or you have questions, comments etc. reply here (and/or on the JIRA itself). Andrew [1] https://issues.apache.org/jira/browse/PROTON-619 A while back I added tests/run.py, a python test runner that has similar config data to config.sh. It will generate something like config.sh if you do run.py --sh. What's run.py used for if it's not used by the build system? Perhaps we should integrate the two. Are your changes already on trunk? I didn't see them as of r1605648 | NO-JIRA: Fix python system tests to work on python 2.5. It went in about 10 minutes before I sent out the heads up - however I screwed up the checkin comment so that the change didn't get linked to the JIRA. https://svn.apache.org/r1606140 Andrew
Re: Heads Up: location of config.sh has changed
On Mon, 2014-06-30 at 16:16 -0400, Andrew Stitcher wrote: On Mon, 2014-06-30 at 14:56 -0400, Alan Conway wrote: On Fri, 2014-06-27 at 12:08 -0400, Andrew Stitcher wrote: As part of QPID-619 [1]. The location of the developer script config.sh has changed from the source tree to the build tree. The runnable config.sh is now built by cmake as part of the tree configuration. This allows the script to set the correct variables without using fallible heuristics. If this trips anyone up. or you have questions, comments etc. reply here (and/or on the JIRA itself). Andrew [1] https://issues.apache.org/jira/browse/PROTON-619 A while back I added tests/run.py, a python test runner that has similar config data to config.sh. It will generate something like config.sh if you do run.py --sh. What's run.py used for if it's not used by the build system? Sorry, didn't read your email carefully enough. I'm talking about dispatch, not proton (doh!) In case you are curious: run.py is a test runner but I also use it stand-alone to run qdrouterd and the like instead of sourcing a script like config.sh. There are two ways to use run.py with an interactive shell: run.py bash # Start a shell with the right env run.py --sh config.sh; source config.sh # Generate a unix-sh env script In principle this works on windows as well (except for the --sh thing) but I haven't tried it. There's valgrind support also, not very well tested. https://svn.apache.org/viewvc/qpid/dispatch/trunk/tests/run.py.in Wow, svn.apache.org is slow today!
[jira] [Created] (PROTON-624) Corrupted payload with redelivered messages when transformer is jms
Jesse Fugitt created PROTON-624: --- Summary: Corrupted payload with redelivered messages when transformer is jms Key: PROTON-624 URL: https://issues.apache.org/jira/browse/PROTON-624 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.7 Environment: ActiveMQ broker with amqp transportConnector transport.transformer=jms Reporter: Jesse Fugitt In the contrib\proton-jms module (used by ActiveMQ), the JMSMappingOutboundTransformer is missing a reset call needed to make sure the BytesMessage is readable for future calls to readBytes(). The result is that redelivered messages from the broker to AMQP consumers have a payload of the correct length but with corrupted content (really all 0's as the content). To reproduce, call transform() in JMSMappingOutboundTransformer with a BytesMessage and then call it again with the same BytesMessage object. The body of the second EncodedMessage will be filled with 0's instead of having the real payload. To reproduce with ActiveMQ, configure the amqp transportConnector with transport.transformer=jms and then send a message into the broker. Once the message is assigned to a proton receiver (without acking it) close the connection and start another proton connection/receiver so the message will be redelivered to it. The payload should contain all 0's instead of the real payload. The other outbound transformer in proton-jms (AMQPNativeOutboundTransformer) makes the reset call as expected so it doesn't suffer from this bug. Based on that class the fix appears to be a one-liner to just add m.reset() after m.readBytes(data). The component is really proton-jms rather than proton-j but that wasn't a choice in JIRA. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-624) Corrupted payload with redelivered messages when transformer is jms
[ https://issues.apache.org/jira/browse/PROTON-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Fugitt updated PROTON-624: Attachment: bytes_message_reset.patch Attached patch from git diff of 0.7 branch with the reset fix. Corrupted payload with redelivered messages when transformer is jms --- Key: PROTON-624 URL: https://issues.apache.org/jira/browse/PROTON-624 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.7 Environment: ActiveMQ broker with amqp transportConnector transport.transformer=jms Reporter: Jesse Fugitt Labels: jms Attachments: bytes_message_reset.patch In the contrib\proton-jms module (used by ActiveMQ), the JMSMappingOutboundTransformer is missing a reset call needed to make sure the BytesMessage is readable for future calls to readBytes(). The result is that redelivered messages from the broker to AMQP consumers have a payload of the correct length but with corrupted content (really all 0's as the content). To reproduce, call transform() in JMSMappingOutboundTransformer with a BytesMessage and then call it again with the same BytesMessage object. The body of the second EncodedMessage will be filled with 0's instead of having the real payload. To reproduce with ActiveMQ, configure the amqp transportConnector with transport.transformer=jms and then send a message into the broker. Once the message is assigned to a proton receiver (without acking it) close the connection and start another proton connection/receiver so the message will be redelivered to it. The payload should contain all 0's instead of the real payload. The other outbound transformer in proton-jms (AMQPNativeOutboundTransformer) makes the reset call as expected so it doesn't suffer from this bug. Based on that class the fix appears to be a one-liner to just add m.reset() after m.readBytes(data). The component is really proton-jms rather than proton-j but that wasn't a choice in JIRA. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-625) Biggest Backtrace Ever!
michael goulish created PROTON-625: -- Summary: Biggest Backtrace Ever! Key: PROTON-625 URL: https://issues.apache.org/jira/browse/PROTON-625 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: michael goulish I am saving all my stuff so I can repro on demand. It doesn't happen every time, but it's about 50%. -- On one box, I have a dispatch router. On the other box, I have 10 clients: 5 Messenger-based receivers, and 5 qpid-messaging-based senders. Each client will handle 100 addresses, of the form mick/0 ... mick/1 ... c. 100 messages will be sent to each address. I start the 5 receivers first. They start OK. Dispatch router happy stable. Wait a few seconds. I start the 5 senders, from a bash script. The first sender is already sending when the 2nd, 3rd, 4th start. After a few of them start,but before all have finished starting, a few seconds into the script, the crash occurs. ( If they all start up successfully, no crash. ) Here is the biggest backtrace ever: #0 0x003cf9879ad1 in _int_malloc (av=0x7f101c20, bytes=16384) at malloc.c:4383 #1 0x003cf987a911 in __libc_malloc (bytes=16384) at malloc.c:3664 #2 0x0039c6c1650a in pni_map_allocate () from /usr/lib64/libqpid-proton.so.2 #3 0x0039c6c16a3a in pni_map_ensure () from /usr/lib64/libqpid-proton.so.2 #4 0x0039c6c16c45 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #5 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #6 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #7 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #8 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #9 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #10 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #11 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #12 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #13 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #14 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 . . . . #93549 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93550 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93551 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93552 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93553 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93554 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93555 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93556 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93557 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93558 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93559 0x0039c6c16dc0 in pn_map_put () from /usr/lib64/libqpid-proton.so.2 #93560 0x0039c6c17226 in pn_hash_put () from /usr/lib64/libqpid-proton.so.2 #93561 0x0039c6c2a643 in pn_delivery_map_push () from /usr/lib64/libqpid-proton.so.2 #93562 0x0039c6c2c44b in pn_do_transfer () from /usr/lib64/libqpid-proton.so.2 #93563 0x0039c6c24385 in pn_dispatch_frame () from /usr/lib64/libqpid-proton.so.2 #93564 0x0039c6c2448f in pn_dispatcher_input () from /usr/lib64/libqpid-proton.so.2 #93565 0x0039c6c2d68b in pn_input_read_amqp () from /usr/lib64/libqpid-proton.so.2 #93566 0x0039c6c3011a in pn_io_layer_input_passthru () from /usr/lib64/libqpid-proton.so.2 #93567 0x0039c6c3011a in pn_io_layer_input_passthru () from /usr/lib64/libqpid-proton.so.2 #93568 0x0039c6c2d275 in transport_consume () from /usr/lib64/libqpid-proton.so.2 #93569 0x0039c6c304cd in pn_transport_process () from /usr/lib64/libqpid-proton.so.2 #93570 0x0039c6c3e40c in pn_connector_process () from /usr/lib64/libqpid-proton.so.2 #93571 0x7f1060c60460 in process_connector () from /home/mick/dispatch/build/libqpid-dispatch.so.0 #93572 0x7f1060c61017 in thread_run () from /home/mick/dispatch/build/libqpid-dispatch.so.0 #93573 0x003cf9c07851 in start_thread (arg=0x7f1052bfd700) at pthread_create.c:301 #93574 0x003cf98e890d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-625) Biggest Backtrace Ever!
[ https://issues.apache.org/jira/browse/PROTON-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael goulish updated PROTON-625: --- Description: I am saving all my stuff so I can repro on demand. It doesn't happen every time, but it's about 50%. -- On one box, I have a dispatch router. On the other box, I have 10 clients: 5 Messenger-based receivers, and 5 qpid-messaging-based senders. Each client will handle 100 addresses, of the form mick/0 ... mick/1 ... c. 100 messages will be sent to each address. I start the 5 receivers first. They start OK. Dispatch router happy stable. Wait a few seconds. I start the 5 senders, from a bash script. The first sender is already sending when the 2nd, 3rd, 4th start. After a few of them start,but before all have finished starting, a few seconds into the script, the crash occurs. ( If they all start up successfully, no crash. ) The crash occurs in the dispatch router. Here is the biggest backtrace ever: #0 0x003cf9879ad1 in _int_malloc (av=0x7f101c20, bytes=16384) at malloc.c:4383 #1 0x003cf987a911 in __libc_malloc (bytes=16384) at malloc.c:3664 #2 0x0039c6c1650a in pni_map_allocate () from /usr/lib64/libqpid-proton.so.2 #3 0x0039c6c16a3a in pni_map_ensure () from /usr/lib64/libqpid-proton.so.2 #4 0x0039c6c16c45 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #5 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #6 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #7 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #8 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #9 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #10 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #11 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #12 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #13 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #14 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 . . . . #93549 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93550 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93551 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93552 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93553 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93554 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93555 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93556 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93557 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93558 0x0039c6c16c64 in pni_map_entry () from /usr/lib64/libqpid-proton.so.2 #93559 0x0039c6c16dc0 in pn_map_put () from /usr/lib64/libqpid-proton.so.2 #93560 0x0039c6c17226 in pn_hash_put () from /usr/lib64/libqpid-proton.so.2 #93561 0x0039c6c2a643 in pn_delivery_map_push () from /usr/lib64/libqpid-proton.so.2 #93562 0x0039c6c2c44b in pn_do_transfer () from /usr/lib64/libqpid-proton.so.2 #93563 0x0039c6c24385 in pn_dispatch_frame () from /usr/lib64/libqpid-proton.so.2 #93564 0x0039c6c2448f in pn_dispatcher_input () from /usr/lib64/libqpid-proton.so.2 #93565 0x0039c6c2d68b in pn_input_read_amqp () from /usr/lib64/libqpid-proton.so.2 #93566 0x0039c6c3011a in pn_io_layer_input_passthru () from /usr/lib64/libqpid-proton.so.2 #93567 0x0039c6c3011a in pn_io_layer_input_passthru () from /usr/lib64/libqpid-proton.so.2 #93568 0x0039c6c2d275 in transport_consume () from /usr/lib64/libqpid-proton.so.2 #93569 0x0039c6c304cd in pn_transport_process () from /usr/lib64/libqpid-proton.so.2 #93570 0x0039c6c3e40c in pn_connector_process () from /usr/lib64/libqpid-proton.so.2 #93571 0x7f1060c60460 in process_connector () from /home/mick/dispatch/build/libqpid-dispatch.so.0 #93572 0x7f1060c61017 in thread_run () from /home/mick/dispatch/build/libqpid-dispatch.so.0 #93573 0x003cf9c07851 in start_thread (arg=0x7f1052bfd700) at pthread_create.c:301 #93574 0x003cf98e890d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 was: I am saving all my stuff so I can repro on demand. It doesn't happen every time, but it's about 50%. -- On one box, I have a dispatch router. On the other box, I have 10 clients: 5 Messenger-based receivers, and 5 qpid-messaging-based senders. Each client will handle 100 addresses, of the form mick/0 ... mick/1 ... c. 100 messages will be sent to each address. I start the 5
