[jira] [Created] (PROTON-1174) Proton C encodes Open.channel-max 0 as a null and not as a uint.
Chuck Rolke created PROTON-1174:
---
Summary: Proton C encodes Open.channel-max 0 as a null and not as
a uint.
Key: PROTON-1174
URL: https://issues.apache.org/jira/browse/PROTON-1174
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.12.0
Reporter: Chuck Rolke
A connection Open frame is created with the intent of limiting the peer to
exactly one link.
{noformat}
pn_transport_set_channel_max(pn_trans, 0);
{noformat}
Proton encodes the frame with a null 0x40 going over the wire in the
channel-max slot.
A receiving application treats the value as 'default' and uses the spec default
value of 65535. If the receiving application had received a 0x43
(types:encoding uint:uint0) it would have used the intended channel max of 0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-1173) Proton C core dump in face of channel-max protocol violation
[
https://issues.apache.org/jira/browse/PROTON-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved PROTON-1173.
-
Resolution: Fixed
Fixed at commit 9d88f82
> Proton C core dump in face of channel-max protocol violation
>
>
> Key: PROTON-1173
> URL: https://issues.apache.org/jira/browse/PROTON-1173
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.11.1
>Reporter: Chuck Rolke
>
> A rogue client creates a session on a channel higher than the channel-max
> exchanged at connection open.
> {noformat}
> Mon Apr 11 10:34:27 2016 SERVER (trace) [1]:pn_session: too many sessions: 1
> channel_max is 0 (/home/chug/git/qpid-dispatch/src/server.c:116)
> Program received signal SIGSEGV, Segmentation fault.
> 0x7793b84a in pn_do_begin (transport=0x6a4bd0, frame_type=0 '\000',
> channel=1, args=0x7c1f60, payload=0x7fffd2c0)
> at /home/chug/git/qpid-proton/proton-c/src/transport/transport.c:1205
> 1205ssn->state.incoming_transfer_count = next;
> Missing separate debuginfos, use: debuginfo-install
> nss-mdns-0.10-15.fc21.x86_64
> (gdb)
> (gdb) list
> 1200 // XXX: what if session is NULL?
> 1201 ssn = (pn_session_t *) pn_hash_get(transport->local_channels,
> remote_channel);
> 1202} else {
> 1203 ssn = pn_session(transport->connection);
> 1204}
> 1205ssn->state.incoming_transfer_count = next;
> 1206pni_map_remote_channel(ssn, channel);
> 1207PN_SET_REMOTE(ssn->endpoint.state, PN_REMOTE_ACTIVE);
> 1208pn_collector_put(transport->connection->collector, PN_OBJECT, ssn,
> PN_SESSION_REMOTE_OPEN);
> 1209return 0;
> (gdb) p ssn
> $1 = (pn_session_t *) 0x0
> (gdb)
> {noformat}
> Session is null and SEGV is what happens.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-1173) Proton C core dump in face of channel-max protocol violation
Chuck Rolke created PROTON-1173:
---
Summary: Proton C core dump in face of channel-max protocol
violation
Key: PROTON-1173
URL: https://issues.apache.org/jira/browse/PROTON-1173
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.11.1
Reporter: Chuck Rolke
A rogue client creates a session on a channel higher than the channel-max
exchanged at connection open.
{noformat}
Mon Apr 11 10:34:27 2016 SERVER (trace) [1]:pn_session: too many sessions: 1
channel_max is 0 (/home/chug/git/qpid-dispatch/src/server.c:116)
Program received signal SIGSEGV, Segmentation fault.
0x7793b84a in pn_do_begin (transport=0x6a4bd0, frame_type=0 '\000',
channel=1, args=0x7c1f60, payload=0x7fffd2c0)
at /home/chug/git/qpid-proton/proton-c/src/transport/transport.c:1205
1205 ssn->state.incoming_transfer_count = next;
Missing separate debuginfos, use: debuginfo-install nss-mdns-0.10-15.fc21.x86_64
(gdb)
(gdb) list
1200// XXX: what if session is NULL?
1201ssn = (pn_session_t *) pn_hash_get(transport->local_channels,
remote_channel);
1202 } else {
1203ssn = pn_session(transport->connection);
1204 }
1205 ssn->state.incoming_transfer_count = next;
1206 pni_map_remote_channel(ssn, channel);
1207 PN_SET_REMOTE(ssn->endpoint.state, PN_REMOTE_ACTIVE);
1208 pn_collector_put(transport->connection->collector, PN_OBJECT, ssn,
PN_SESSION_REMOTE_OPEN);
1209 return 0;
(gdb) p ssn
$1 = (pn_session_t *) 0x0
(gdb)
{noformat}
Session is null and SEGV is what happens.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1156) Building C++ binding causes VS2008 to ICE
[
https://issues.apache.org/jira/browse/PROTON-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15187399#comment-15187399
]
Chuck Rolke commented on PROTON-1156:
-
terminus.cpp will compile with an unacceptable code change but then the ICE
moves to some other module.
{noformat}
-terminus::terminus(pn_terminus_t* t) :
-object_(t), properties_(pn_terminus_properties(t)),
filter_(pn_terminus_filter(t))
-{}
+terminus::terminus(pn_terminus_t* t)
+{ object_ = t;
+properties_ = pn_terminus_properties(t);
+filter_ = pn_terminus_filter(t);
+}
{noformat}
This code has been around for a while and the error is probably a result of
changes to included files.
I'm all for retiring VS2008 support. Do we call for a vote?
> Building C++ binding causes VS2008 to ICE
> -
>
> Key: PROTON-1156
> URL: https://issues.apache.org/jira/browse/PROTON-1156
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.13.0
> Environment: Windows Visual Studio 2008 (VS9)
>Reporter: Andrew Stitcher
>Assignee: Cliff Jansen
>
> {noformat}
> 3>c:\jenkins\workspace\proton-c-master-windows\rh-qpid-proton\proton-c\bindings\cpp\src\terminus.cpp(29)
> : fatal error C1001: An internal error has occurred in the compiler.
> 3>(compiler file
> 'f:\dd\vctools\compiler\utc\src\p2\main.c[0x6C510CA6:0x0010]', line 182)
> 3> To work around this problem, try simplifying or changing the program near
> the locations listed above.
> 3>Please choose the Technical Support command on the Visual C++
> 3> Help menu, or open the Technical Support help file for more information
> 3>Internal Compiler Error in C:\Program Files\Microsoft Visual Studio
> 9.0\VC\bin\cl.exe. You will be prompted to send an error report to Microsoft
> later.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1138) Assorted C++ API cleanups
[ https://issues.apache.org/jira/browse/PROTON-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15185840#comment-15185840 ] Chuck Rolke commented on PROTON-1138: - please ignore last comment > Assorted C++ API cleanups > - > > Key: PROTON-1138 > URL: https://issues.apache.org/jira/browse/PROTON-1138 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Affects Versions: 0.13.0 >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: 0.13.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1138) Assorted C++ API cleanups
[
https://issues.apache.org/jira/browse/PROTON-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15185831#comment-15185831
]
Chuck Rolke commented on PROTON-1138:
-
The last commit with:
{noformat}
-template data& copy(T ) { clear(); encoder() << t; return
*this; }
+template typename enable_amqp_type::type& copy(T ) {
+clear(); encoder() << t; return *this;
+}
{noformat}
causes Windows (VS2008, x64) warning
{noformat}
34>d:\users\git\qpid-proton\proton-c\bindings\cpp\include\proton\data.hpp(50) :
warning C4717:
'proton::data::copy,proton::value> const >' :
recursive on all control paths, function will cause runtime stack overflow
{noformat}
> Assorted C++ API cleanups
> -
>
> Key: PROTON-1138
> URL: https://issues.apache.org/jira/browse/PROTON-1138
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
>Affects Versions: 0.13.0
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: 0.13.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-1133) Proton C includes port number in AMQP Open hostname
Chuck Rolke created PROTON-1133:
---
Summary: Proton C includes port number in AMQP Open hostname
Key: PROTON-1133
URL: https://issues.apache.org/jira/browse/PROTON-1133
Project: Qpid Proton
Issue Type: Bug
Affects Versions: 0.12.0
Reporter: Chuck Rolke
A command like:
{noformat}
qdmanage -b amqp://u1:password@photoserver:21000 --type policyStats query
{noformat}
sends the port number in the hostname field of the AMQP Open:
{noformat}
Mon Feb 8 11:37:46 2016 SERVER (trace) [2]:0 <- @open(16)
[container-id="34e49947-b4df-4a01-9570-0a74e9e57b5b",
hostname="photoserver:21000", channel-max=32767]
(/home/chug/git/qpid-dispatch/src/server.c:75)
{noformat}
Built in C example code using Proton only does the same thing.
This bug originally reported at
https://issues.apache.org/jira/browse/DISPATCH-214
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1127) [Windows] qpid-proton-cpp.dll not installed by "make install" target
[ https://issues.apache.org/jira/browse/PROTON-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134407#comment-15134407 ] Chuck Rolke commented on PROTON-1127: - This change should go into release 0.12. > [Windows] qpid-proton-cpp.dll not installed by "make install" target > > > Key: PROTON-1127 > URL: https://issues.apache.org/jira/browse/PROTON-1127 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.12.0 > Environment: Windows MSVC >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.12.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-926) [proton-c windows] Create all binary executables in build/proton-c folder
[ https://issues.apache.org/jira/browse/PROTON-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke closed PROTON-926. -- Resolution: Won't Fix > [proton-c windows] Create all binary executables in build/proton-c folder > - > > Key: PROTON-926 > URL: https://issues.apache.org/jira/browse/PROTON-926 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.9.1 > Environment: Windows >Reporter: Chuck Rolke > > Test code and examples are created in various places in the build dir. For a > windows user there is a big advantage to creating all the .exe files in the > same dir as the .dll files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-921) [C windows] compile warnings: PN_WINAPI defined multiple times
[ https://issues.apache.org/jira/browse/PROTON-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved PROTON-921. Resolution: Fixed Fix Version/s: 0.10 > [C windows] compile warnings: PN_WINAPI defined multiple times > -- > > Key: PROTON-921 > URL: https://issues.apache.org/jira/browse/PROTON-921 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9.1 > Environment: Windows >Reporter: Chuck Rolke > Fix For: 0.10 > > > Files ip.c, iocp.c, write_pipeline.c, and selector.c have an unnecessary > #define PN_WINAPI. This symbol is already defined in the project settings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-884) [C Windows] python transport tracer breaks windows build
[
https://issues.apache.org/jira/browse/PROTON-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved PROTON-884.
Resolution: Fixed
Fix Version/s: 0.10
> [C Windows] python transport tracer breaks windows build
>
>
> Key: PROTON-884
> URL: https://issues.apache.org/jira/browse/PROTON-884
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, python-binding
>Affects Versions: 0.10
> Environment: Win Server 2008, Visual Studio 2008 x86
>Reporter: Chuck Rolke
> Fix For: 0.10
>
>
> {noformat}
> 12>.\cprotonPYTHON_wrap.cxx(3611) : error C2440: 'initializing' : cannot
> convert from 'void *' to 'PyObject *'
> 12>Conversion from 'void*' to pointer to non-'void' requires an
> explicit cast
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-821) Windows swigged perl install fails - no .so files
[ https://issues.apache.org/jira/browse/PROTON-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved PROTON-821. Resolution: Fixed Fix Version/s: 0.9 > Windows swigged perl install fails - no .so files > - > > Key: PROTON-821 > URL: https://issues.apache.org/jira/browse/PROTON-821 > Project: Qpid Proton > Issue Type: Bug > Components: perl-binding >Affects Versions: 0.9 > Environment: Windows Server 2008 x86 >Reporter: Chuck Rolke > Fix For: 0.9 > > > The install code in cmake has hard-coded cproton_perl.so and > libcproton_perl.so files names. Those don't exist on windows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-821) Windows swigged perl install fails - no .so files
[ https://issues.apache.org/jira/browse/PROTON-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke closed PROTON-821. -- > Windows swigged perl install fails - no .so files > - > > Key: PROTON-821 > URL: https://issues.apache.org/jira/browse/PROTON-821 > Project: Qpid Proton > Issue Type: Bug > Components: perl-binding >Affects Versions: 0.9 > Environment: Windows Server 2008 x86 >Reporter: Chuck Rolke > Fix For: 0.9 > > > The install code in cmake has hard-coded cproton_perl.so and > libcproton_perl.so files names. Those don't exist on windows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1093) [proton-c++] pragma to hide a warning in GCC introduces a warning in Windows
Chuck Rolke created PROTON-1093: --- Summary: [proton-c++] pragma to hide a warning in GCC introduces a warning in Windows Key: PROTON-1093 URL: https://issues.apache.org/jira/browse/PROTON-1093 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: 0.12.0 Environment: Visual Studio 20xx Reporter: Chuck Rolke Assignee: Chuck Rolke proton-c\bindings\cpp\src\contexts.cpp(48) : warning C4068: unknown pragma #pragma GCC diagnostic ignored "-Wold-style-cast" commit fd52a33 I propose fixing this by moving the pragma into cmake to leave the source with no #pragma and with no conditional to hide the pragma. Windows has plenty of other warnings if we're serious about squelching them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-766) Proton-c Windows IO prints misleading error messages
[
https://issues.apache.org/jira/browse/PROTON-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15086227#comment-15086227
]
Chuck Rolke commented on PROTON-766:
In reviewing this issue the behavior has changed. Now (master branch at commit
178aa46) there is no longer a misleading message. Instead the code fails
silently.
{noformat}
W:\>send -a [::1]
W:\>
{noformat}
The failure is evident when proton trace is turned on
{noformat}
W:\>set PN_TRACE_FRM=1
W:\>send -a [::1]
[01216830]: -> AMQP
[01216830]:0 -> @open(16) [container-id="C3540831-9767-4425-A13B-8769D12AF272",
hostname="::1", channel-max=32767]
[01216830]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]
[01216830]:0 -> @attach(18) [name="sender-xxx", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [durable=0, timeout=0, dynamic=false],
target=@target(41) [durable=0, timeout=0, dynamic=false],
initial-delivery-count=0]
[01216830]:0 -> @close(24) [error=@error(29)
[condition=:"amqp:connection:framing-error",
description="AMQP header mismatch: Insufficient data to determine protocol
[''] (connection aborted)"]]
[01216830]: <- EOS
{noformat}
> Proton-c Windows IO prints misleading error messages
>
>
> Key: PROTON-766
> URL: https://issues.apache.org/jira/browse/PROTON-766
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.8
> Environment: Windows Server 2012 R2
> Examples messaging c recv
>Reporter: Chuck Rolke
>
> Connecting to a port that is not open.
> Windows:
> {noformat}
> > send -a [::1]
> recv: No error
> [01241B10]:ERROR amqp:connection:framing-error SASL header mismatch:
> ''
> CONNECTION ERROR connection aborted (remote)
> send: No error
> {noformat}
> The same action on Linux:
> {noformat}
> > ./send -a [::1]
> recv: Connection refused
> [0x158d030]:ERROR amqp:connection:framing-error SASL header mismatch:
> Insufficient data to determine protocol [''] (connection aborted)
> CONNECTION ERROR connection aborted (remote)
> send: Broken pipe
> {noformat}
> The Linux messages are more useful and indicate the precise error conditions.
> The Windows messages show recv: and send: with 'No error' and that is not the
> case.
> The same error message is displayed for IPv4 and IPv6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (PROTON-600) Windows python Debug binding install fails due to missing "d" debug suffix
[
https://issues.apache.org/jira/browse/PROTON-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke closed PROTON-600.
--
Resolution: Won't Fix
Use cmake 'RelWithDebInfo' for debug builds.
> Windows python Debug binding install fails due to missing "d" debug suffix
> --
>
> Key: PROTON-600
> URL: https://issues.apache.org/jira/browse/PROTON-600
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.7
> Environment: Windows Server 2012 R2
> Visual Studio 2010, x86 Win32
> Swig 3.0.1
> Python 2.6.1
> Cmake 2.8.12.2
> Ruby 1.8.6
>Reporter: Chuck Rolke
>
> {noformat}
> 15> CMake Error at proton-c/bindings/python/cmake_install.cmake:63 (FILE):
> 15>file INSTALL cannot find
> 15>"D:/build_2010_x86/proton-c/bindings/python/Debug/_cprotond.pyd".
> 15> Call Stack (most recent call first):
> 15>proton-c/bindings/cmake_install.cmake:32 (INCLUDE)
> 15>proton-c/cmake_install.cmake:144 (INCLUDE)
> 15>cmake_install.cmake:58 (INCLUDE)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-991) [C] Generated code redefines constants
[ https://issues.apache.org/jira/browse/PROTON-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved PROTON-991. Resolution: Fixed Fix Version/s: 0.11 > [C] Generated code redefines constants > -- > > Key: PROTON-991 > URL: https://issues.apache.org/jira/browse/PROTON-991 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Chuck Rolke >Priority: Minor > Fix For: 0.11 > > > Generated file /proton-c/src/protocol.h defines the HEADERS and > PROPERTIES symbols twice. Same value both times. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-986) [C] proton-dump assumes one AMQP header
[ https://issues.apache.org/jira/browse/PROTON-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved PROTON-986. Resolution: Fixed Fix Version/s: 0.11 > [C] proton-dump assumes one AMQP header > --- > > Key: PROTON-986 > URL: https://issues.apache.org/jira/browse/PROTON-986 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.10 > Environment: C >Reporter: Chuck Rolke > Fix For: 0.11 > > > Proton-dump discards the leading 8 bytes of data in all cases. I have two > uses where this is a nuisance. They are generated by wireshark the same way: > * Start wireshark trace > * Find stream of interest > * Follow TCP stream > * Save As type raw > * Feed the raw file to proton-dump > Case 1. The raw saved file has a complete AMQP connection startup. The binary > data has two AMQP headers and proton-dump fails. > Case 2. The raw saved file starts midstream in the AMQP content. The binary > data has no AMQP headers and proton-dump fails. > With the wireshark dissector one usually does not need proton-dump. But > sometimes wireshark complains about a frame format or a decoding issue. > Proton-dump as an AMQP decoder is a higher authority than wireshark and > fixing proton-dump a little improves its utility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1035) [proton-c] Python binding mishandles connection close event
[
https://issues.apache.org/jira/browse/PROTON-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke updated PROTON-1035:
Affects Version/s: 0.11
> [proton-c] Python binding mishandles connection close event
> ---
>
> Key: PROTON-1035
> URL: https://issues.apache.org/jira/browse/PROTON-1035
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10, 0.11
> Environment: qpid-dispatch tool qdstat client
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
>
> Testing out policy-based connection rejection shows qdstat tool
> mis-interpreting the connection failure. The order of events on the wire is:
> {noformat}
> Client sends
> Open
> Router sends
> Open
> Close(Arguments: Error: {
> Condition: 'amqp:resource-limit-exceeded',
> Description: 'connection disallowed by local policy',
> Info: ''}
> {noformat}
> Then the qdstat tool fails with message:
> {noformat}
> AttributeError: 'ConnectionClosed' object has no attribute 'url'
> {noformat}
> The expectation is for the tool to show the condition/description from the
> Close performative.
> This issue was originally reported under DISPATCH-189
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-1035) [proton-c] Python binding mishandles connection close event
[
https://issues.apache.org/jira/browse/PROTON-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved PROTON-1035.
-
Resolution: Fixed
Fix Version/s: 0.12.0
Fixed at
Commit 4f5e18a059d1e0ced5b5f3ae8c9fa4503dde43fc in qpid-proton's branch
refs/heads/master
> [proton-c] Python binding mishandles connection close event
> ---
>
> Key: PROTON-1035
> URL: https://issues.apache.org/jira/browse/PROTON-1035
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10, 0.11
> Environment: qpid-dispatch tool qdstat client
>Reporter: Chuck Rolke
>Assignee: Chuck Rolke
> Fix For: 0.12.0
>
>
> Testing out policy-based connection rejection shows qdstat tool
> mis-interpreting the connection failure. The order of events on the wire is:
> {noformat}
> Client sends
> Open
> Router sends
> Open
> Close(Arguments: Error: {
> Condition: 'amqp:resource-limit-exceeded',
> Description: 'connection disallowed by local policy',
> Info: ''}
> {noformat}
> Then the qdstat tool fails with message:
> {noformat}
> AttributeError: 'ConnectionClosed' object has no attribute 'url'
> {noformat}
> The expectation is for the tool to show the condition/description from the
> Close performative.
> This issue was originally reported under DISPATCH-189
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-1034) [Go binding] Windows build fails if Go language is installed but no gcc tool kit
Chuck Rolke created PROTON-1034: --- Summary: [Go binding] Windows build fails if Go language is installed but no gcc tool kit Key: PROTON-1034 URL: https://issues.apache.org/jira/browse/PROTON-1034 Project: Qpid Proton Issue Type: Bug Components: go-binding Affects Versions: 0.11 Environment: Windows with Go but without CYGWIN gcc. Reporter: Chuck Rolke Assignee: Chuck Rolke Go builds detect the presence of the Go executable and build based on that. On Windows the build also requires gcc/ld which are part of a separate tool kit such MINGW or CYGWIN. Even then there are issues with * the debug postfix 'd' character on library names * 32-bit/64-bit library detection The proton-c builds should still work even if Go is installed. This issue tracks solving the build problem by defaulting the Go binding to OFF on windows. Users with or without Go installed will still get a good proton build but with no Go binding. A developer can issue -DBUILD_GO=Yes to force the build while he works out the gcc interface issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1035) [proton-c] Python binding mishandles connection close event
Chuck Rolke created PROTON-1035:
---
Summary: [proton-c] Python binding mishandles connection close
event
Key: PROTON-1035
URL: https://issues.apache.org/jira/browse/PROTON-1035
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: 0.10
Environment: qpid-dispatch tool qdstat client
Reporter: Chuck Rolke
Assignee: Chuck Rolke
Testing out policy-based connection rejection shows qdstat tool
mis-interpreting the connection failure. The order of events on the wire is:
{noformat}
Client sends
Open
Router sends
Open
Close(Arguments: Error: {
Condition: 'amqp:resource-limit-exceeded',
Description: 'connection disallowed by local policy',
Info: ''}
{noformat}
Then the qdstat tool fails with message:
{noformat}
AttributeError: 'ConnectionClosed' object has no attribute 'url'
{noformat}
The expectation is for the tool to show the condition/description from the
Close performative.
This issue was originally reported under DISPATCH-189
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-991) [C] Generated code redefines constants
Chuck Rolke created PROTON-991: -- Summary: [C] Generated code redefines constants Key: PROTON-991 URL: https://issues.apache.org/jira/browse/PROTON-991 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Chuck Rolke Priority: Minor Generated file /proton-c/src/protocol.h defines the HEADERS and PROPERTIES symbols twice. Same value both times. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-990) [C++ binding] Examples fail to link in Visual Studio 2012, 2015
Chuck Rolke created PROTON-990:
--
Summary: [C++ binding] Examples fail to link in Visual Studio
2012, 2015
Key: PROTON-990
URL: https://issues.apache.org/jira/browse/PROTON-990
Project: Qpid Proton
Issue Type: Bug
Affects Versions: 0.10
Environment: Windows Visual Studio 2012, 2015
Reporter: Chuck Rolke
Issue reported by Clemens Vasters
Trying to build current qpid-proton master on Windows with Visual Studio 2015
(MSVC 19) and I'm getting linker errors for std::auto_ptr for all the examples
in examples/cpp
The errors all look largely the same and are all about auto_ptr, so I just give
one:
{noformat}
sync_client.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport) public: static class std::auto_ptr __cdecl proton::message::create(void)"
(__imp_?create@message@proton@@SA?AV?$auto_ptr@Vmessage@proton@@@std@@XZ)
referenced in function "public: __thiscall
proton::message_value::message_value(void)" (??0message_value@proton@@QAE@XZ)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-986) [C] proton-dump assumes one AMQP header
Chuck Rolke created PROTON-986: -- Summary: [C] proton-dump assumes one AMQP header Key: PROTON-986 URL: https://issues.apache.org/jira/browse/PROTON-986 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.10 Environment: C Reporter: Chuck Rolke Proton-dump discards the leading 8 bytes of data in all cases. I have two uses where this is a nuisance. They are generated by wireshark the same way: * Start wireshark trace * Find stream of interest * Follow TCP stream * Save As type raw * Feed the raw file to proton-dump Case 1. The raw saved file has a complete AMQP connection startup. The binary data has two AMQP headers and proton-dump fails. Case 2. The raw saved file starts midstream in the AMQP content. The binary data has no AMQP headers and proton-dump fails. With the wireshark dissector one usually does not need proton-dump. But sometimes wireshark complains about a frame format or a decoding issue. Proton-dump as an AMQP decoder is a higher authority than wireshark and fixing proton-dump a little improves its utility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-926) [proton-c windows] Create all binary executables in build/proton-c folder
Chuck Rolke created PROTON-926: -- Summary: [proton-c windows] Create all binary executables in build/proton-c folder Key: PROTON-926 URL: https://issues.apache.org/jira/browse/PROTON-926 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.9.1 Environment: Windows Reporter: Chuck Rolke Test code and examples are created in various places in the build dir. For a windows user there is a big advantage to creating all the .exe files in the same dir as the .dll files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-921) [C windows] compile warnings: PN_WINAPI defined multiple times
Chuck Rolke created PROTON-921: -- Summary: [C windows] compile warnings: PN_WINAPI defined multiple times Key: PROTON-921 URL: https://issues.apache.org/jira/browse/PROTON-921 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Environment: Windows Reporter: Chuck Rolke Files ip.c, iocp.c, write_pipeline.c, and selector.c have an unnecessary #define PN_WINAPI. This symbol is already defined in the project settings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-884) [C Windows] python transport tracer breaks windows build
Chuck Rolke created PROTON-884:
--
Summary: [C Windows] python transport tracer breaks windows build
Key: PROTON-884
URL: https://issues.apache.org/jira/browse/PROTON-884
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, python-binding
Affects Versions: 0.10
Environment: Win Server 2008, Visual Studio 2008 x86
Reporter: Chuck Rolke
{noformat}
12.\cprotonPYTHON_wrap.cxx(3611) : error C2440: 'initializing' : cannot
convert from 'void *' to 'PyObject *'
12Conversion from 'void*' to pointer to non-'void' requires an
explicit cast
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-875) Proton-C SASL changes break windows self tests
Chuck Rolke created PROTON-875:
--
Summary: Proton-C SASL changes break windows self tests
Key: PROTON-875
URL: https://issues.apache.org/jira/browse/PROTON-875
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, python-binding
Affects Versions: 0.9
Environment: Windows Server Datacenter SP2, 32-bit
swigwin-2.0.10
Python26
Reporter: Chuck Rolke
After commits 4a09c6, 7cf0aba, and b3bf328 from PROTON-334, self tests started
to fail.
{noformat}
1: proton_tests.sasl.SaslTest.testPipelined2 ...
fail
1: Error during test: Traceback (most recent call last):
1: File
C:/Jenkins/workspace/rh_qpid_proton-trunk/rh-qpid-proton/tests/python/proton-test,
line 355, in run
1: phase()
1: File
C:\Jenkins\workspace\rh_qpid_proton-trunk\rh-qpid-proton\tests\python\proton_tests\sasl.py,
line 161, in testPipelined2
1: assert len(out1) 0
1: AssertionError
1: proton_tests.sasl.SaslTest.testPipelinedClient ..
fail
1: Error during test: Traceback (most recent call last):
1: File
C:/Jenkins/workspace/rh_qpid_proton-trunk/rh-qpid-proton/tests/python/proton-test,
line 355, in run
1: phase()
1: File
C:\Jenkins\workspace\rh_qpid_proton-trunk\rh-qpid-proton\tests\python\proton_tests\sasl.py,
line 68, in testPipelinedClient
1: assert self.s1.outcome == SASL.OK
1: AssertionError
1: proton_tests.sasl.SaslTest.testPipelinedClientFail ..
fail
1: Error during test: Traceback (most recent call last):
1: File
C:/Jenkins/workspace/rh_qpid_proton-trunk/rh-qpid-proton/tests/python/proton-test,
line 355, in run
1: phase()
1: File
C:\Jenkins\workspace\rh_qpid_proton-trunk\rh-qpid-proton\tests\python\proton_tests\sasl.py,
line 95, in testPipelinedClientFail
1: assert self.s1.outcome == SASL.AUTH
1: AssertionError
1: proton_tests.sasl.SaslTest.testSaslAndAmqpInSingleChunk .
fail
1: Error during test: Traceback (most recent call last):
1: File
C:/Jenkins/workspace/rh_qpid_proton-trunk/rh-qpid-proton/tests/python/proton-test,
line 355, in run
1: phase()
1: File
C:\Jenkins\workspace\rh_qpid_proton-trunk\rh-qpid-proton\tests\python\proton_tests\sasl.py,
line 140, in testSaslAndAmqpInSingleChunk
1: assert self.s2.outcome == SASL.OK
1: AssertionError
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-824) Windows fails testIdleTimeout with assert p.conn.remote_condition
[
https://issues.apache.org/jira/browse/PROTON-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1495#comment-1495
]
Chuck Rolke commented on PROTON-824:
Here's what's happening. All of the Program's reactor callbacks are firing and
each is passing its assertions.
But when the main program continues from Reactor(p).run() then p.conn does not
have a remote_condition any more.
Any thoughts?
{noformat}
1: start
1: INFO: on_reactor_init
1: INFO: on_connection_remote_open
1: INFO: on_timer_task
1: INFO: on_connection_remote_close
1: INFO:self.conn : proton.Connection 0x2704610 ~ 0x27be2f0
1: INFO:self.conn.remote_condition :
Condition('amqp:resource-limit-exceeded', 'local-idle-timeout expired')
1: INFO: p.conn : proton.Connection 0x2704610 ~ 0x27be2f0
1: INFO: p.conn.remote_condition : None
1: proton_tests.engine.AAAServerTest.testIdleTimeout ...
proton_tests.engine.AAAServerTest.testIdleTimeout ...
fail
1: Error during test: Traceback (most recent call last):
1: File D:/Users/crolke/git/rh-qpid-proton/tests/python/proton-test, line
355, in run
1: phase()
1: File
D:\Users\crolke\git\rh-qpid-proton\tests\python\proton_tests\engine.py, line
1894, in testIdleTimeout
1: assert p.conn.remote_condition
1: AssertionError
{noformat}
Windows fails testIdleTimeout with assert p.conn.remote_condition
-
Key: PROTON-824
URL: https://issues.apache.org/jira/browse/PROTON-824
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Environment: Windows Server 2008 or 2012
Visual studio 2010, x86
Reporter: Chuck Rolke
{noformat}
1: proton_tests.engine.ServerTest.testIdleTimeout .
fail
1: Error during test: Traceback (most recent call last):
1: File D:/Users/crolke/git/rh-qpid-proton/tests/python/proton-test,
line 355, in run
1: phase()
1: File
D:\Users\crolke\git\rh-qpid-proton\tests\python\proton_tests\engine.py,
line 1919 (or so), in testIdleTimeout
1: assert p.conn.remote_condition
1: AssertionError
{noformat}
Playing with Program explicit timeout (trying 10 instead of 3) gets the test
to pass sometimes. It passes sometimes with 3 as well but normally fails.
In debugging this it looks like there as no synchronization between what a
test will show through print statements and what the proton library shows
through PN_TRACE_FRM statements. Are there any hints to lining these up?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-824) Windows fails testIdleTimeout with assert p.conn.remote_condition
Chuck Rolke created PROTON-824:
--
Summary: Windows fails testIdleTimeout with assert
p.conn.remote_condition
Key: PROTON-824
URL: https://issues.apache.org/jira/browse/PROTON-824
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Environment: Windows Server 2008 or 2012
Visual studio 2010, x86
Reporter: Chuck Rolke
{noformat}
1: proton_tests.engine.ServerTest.testIdleTimeout . fail
1: Error during test: Traceback (most recent call last):
1: File D:/Users/crolke/git/rh-qpid-proton/tests/python/proton-test, line
355, in run
1: phase()
1: File
D:\Users\crolke\git\rh-qpid-proton\tests\python\proton_tests\engine.py, line
1919 (or so), in testIdleTimeout
1: assert p.conn.remote_condition
1: AssertionError
{noformat}
Playing with Program explicit timeout (trying 10 instead of 3) gets the test to
pass sometimes. It passes sometimes with 3 as well but normally fails.
In debugging this it looks like there as no synchronization between what a test
will show through print statements and what the proton library shows through
PN_TRACE_FRM statements. Are there any hints to lining these up?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (PROTON-820) Windows build error for perlPERL_wrap.c
[ https://issues.apache.org/jira/browse/PROTON-820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke closed PROTON-820. -- Resolution: Fixed Fix Version/s: 0.9 Fixed at commit 4b955e4..350ec82 HEAD - master Windows build error for perlPERL_wrap.c --- Key: PROTON-820 URL: https://issues.apache.org/jira/browse/PROTON-820 Project: Qpid Proton Issue Type: Bug Components: perl-binding Affects Versions: 0.9 Environment: Windows Server 2008 32-bit, Visual Studio 2008, swig 2.0.10, perl v5.10.1 MSWin32-x86-multi-thread, cmake 2.8.11.2 Reporter: Chuck Rolke Fix For: 0.9 File include/proton/delivery.h has a 'static inline' code construct. When delivery is included by codec.c (project qpid-proton) it's fine. When delivery is included by perlPERL_wrap.c (project cproton_perl) it fails. It expects __inline and not just inline. Note that project qpid-proton.vcproj uses CompileAs=C++ while project cproton_perl uses CompileAs=C. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-821) Windows swigged perl install fails - no .so files
[ https://issues.apache.org/jira/browse/PROTON-821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14326150#comment-14326150 ] Chuck Rolke commented on PROTON-821: Hmmm. I pushed a patch and put PROTON-820 in the commit comment. The comment shows up in PROTON-821. Maybe the web link to PROTON-821 in the commit message tripped up the post-to target (or something) Windows swigged perl install fails - no .so files - Key: PROTON-821 URL: https://issues.apache.org/jira/browse/PROTON-821 Project: Qpid Proton Issue Type: Bug Components: perl-binding Affects Versions: 0.9 Environment: Windows Server 2008 x86 Reporter: Chuck Rolke The install code in cmake has hard-coded cproton_perl.so and libcproton_perl.so files names. Those don't exist on windows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-821) Windows swigged perl install fails - no .so files
Chuck Rolke created PROTON-821: -- Summary: Windows swigged perl install fails - no .so files Key: PROTON-821 URL: https://issues.apache.org/jira/browse/PROTON-821 Project: Qpid Proton Issue Type: Bug Components: perl-binding Affects Versions: 0.9 Environment: Windows Server 2008 x86 Reporter: Chuck Rolke The install code in cmake has hard-coded cproton_perl.so and libcproton_perl.so files names. Those don't exist on windows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-820) Windows build error for perlPERL_wrap.c
Chuck Rolke created PROTON-820: -- Summary: Windows build error for perlPERL_wrap.c Key: PROTON-820 URL: https://issues.apache.org/jira/browse/PROTON-820 Project: Qpid Proton Issue Type: Bug Components: perl-binding Affects Versions: 0.9 Environment: Windows Server 2008 32-bit, Visual Studio 2008, swig 2.0.10, perl v5.10.1 MSWin32-x86-multi-thread, cmake 2.8.11.2 Reporter: Chuck Rolke File include/proton/delivery.h has a 'static inline' code construct. When delivery is included by codec.c (project qpid-proton) it's fine. When delivery is included by perlPERL_wrap.c (project cproton_perl) it fails. It expects __inline and not just inline. Note that project qpid-proton.vcproj uses CompileAs=C++ while project cproton_perl uses CompileAs=C. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-794) [Windows] Visual Studio 2008 compile error
[
https://issues.apache.org/jira/browse/PROTON-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved PROTON-794.
Resolution: Fixed
Fix Version/s: 0.9
Fixed at Commit efa5eab
[Windows] Visual Studio 2008 compile error
--
Key: PROTON-794
URL: https://issues.apache.org/jira/browse/PROTON-794
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Environment: Windows Server 2008 32 bit
Visual Studio 2008
Reporter: Chuck Rolke
Fix For: 0.9
{noformat}
13-- Rebuild All started: Project: c-reactor-tests, Configuration:
RelWithDebInfo Win32 --
13Deleting intermediate and output files for project 'c-reactor-tests',
configuration 'RelWithDebInfo|Win32'
13Building Custom Rule
C:/Hudson/jobs/rh_qpid_proton-trunk/workspace/rh-qpid-proton/proton-c/src/tests/CMakeLists.txt
13CMake does not need to re-run because
C:\Hudson\jobs\rh_qpid_proton-trunk\workspace\rh-qpid-proton\build\proton-c\src\tests\CMakeFiles\generate.stamp
is up-to-date.
13Compiling...
13reactor.c
13..\..\..\..\proton-c\src\tests\reactor.c(80) : error C2440: 'type cast' :
cannot convert from 'void *' to 'pn_event_type_t'
13There is no context in which this conversion is possible
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-800) [Windows C] Reactor test times out
Chuck Rolke created PROTON-800:
--
Summary: [Windows C] Reactor test times out
Key: PROTON-800
URL: https://issues.apache.org/jira/browse/PROTON-800
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.8
Environment: Windows Server 2012 R2, Visual Studio 2010 x64
Reporter: Chuck Rolke
ctest -VV times out on the reactor test.
Instrumenting and debugging shows the failure in test_reactor_acceptor
Running Debug instead of RelWithDebInfo crashes with an AccVio
{noformat}
qpid-protond.dll!pni_iocpdesc_map_get(iocp_t * iocp, unsigned __int64
s) Line 773 + 0xa bytes C++
qpid-protond.dll!pn_close(pn_io_t * io, unsigned __int64 socket) Line
350 + 0x16 bytes C++
qpid-protond.dll!pni_acceptor_finalize(pn_selectable_t * sel) Line 56
C++
qpid-protond.dll!pn_selectable_finalize(void * obj) Line 81C++
qpid-protond.dll!pn_class_decref(const pn_class_t * clazz, void *
object) Line 100 C++
qpid-protond.dll!pn_list_finalize(void * object) Line 205 C++
qpid-protond.dll!pn_class_decref(const pn_class_t * clazz, void *
object) Line 100 C++
qpid-protond.dll!pn_decref(void * object) Line 253 C++
qpid-protond.dll!pn_reactor_finalize(pn_reactor_t * reactor) Line 77
C++
qpid-protond.dll!pn_reactor_finalize_cast(void * object) Line 113 +
0x28 bytes C++
qpid-protond.dll!pn_class_decref(const pn_class_t * clazz, void *
object) Line 100 C++
qpid-protond.dll!pn_decref(void * object) Line 253 C++
qpid-protond.dll!pn_reactor_free(pn_reactor_t * reactor) Line 132
C++
c-reactor-tests.exe!test_reactor_acceptor() Line 171 C++
c-reactor-tests.exe!main(int argc, char * * argv) Line 446 C++
c-reactor-tests.exe!__tmainCRTStartup() Line 555 + 0x19 bytes C
c-reactor-tests.exe!mainCRTStartup() Line 371 C
kernel32.dll!7ff90cc913d2()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
ntdll.dll!7ff90e1003c4()
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-794) [Windows] Visual Studio 2008 compile error
Chuck Rolke created PROTON-794:
--
Summary: [Windows] Visual Studio 2008 compile error
Key: PROTON-794
URL: https://issues.apache.org/jira/browse/PROTON-794
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Environment: Windows Server 2008 32 bit
Visual Studio 2008
Reporter: Chuck Rolke
{noformat}
13-- Rebuild All started: Project: c-reactor-tests, Configuration:
RelWithDebInfo Win32 --
13Deleting intermediate and output files for project 'c-reactor-tests',
configuration 'RelWithDebInfo|Win32'
13Building Custom Rule
C:/Hudson/jobs/rh_qpid_proton-trunk/workspace/rh-qpid-proton/proton-c/src/tests/CMakeLists.txt
13CMake does not need to re-run because
C:\Hudson\jobs\rh_qpid_proton-trunk\workspace\rh-qpid-proton\build\proton-c\src\tests\CMakeFiles\generate.stamp
is up-to-date.
13Compiling...
13reactor.c
13..\..\..\..\proton-c\src\tests\reactor.c(80) : error C2440: 'type cast' :
cannot convert from 'void *' to 'pn_event_type_t'
13There is no context in which this conversion is possible
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-784) Settled Deliveries keep piling up, and do not seem to get freed from heap
[
https://issues.apache.org/jira/browse/PROTON-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14268309#comment-14268309
]
Chuck Rolke commented on PROTON-784:
Rafi, Thanks for your patience.
Running against the QPID examples has an issue in that it doesn't settle
deliveries. So they do pile up but it's not proton's fault. I fixed that in
linux but not in windows so that's why windows still looked broken. You can
call this jira fixed.
Settled Deliveries keep piling up, and do not seem to get freed from heap
-
Key: PROTON-784
URL: https://issues.apache.org/jira/browse/PROTON-784
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: German Shepherd (PrE)
Fix For: 0.9
When running the ProtonC 0.8, this issue was not present.
Then, in ProtonC 0.9 (Git trunk of 12/19/2014), there are changes in a way
the deliveries are handled (engine.c).
Correct me if I'm wrong, but given the behavior in 0.8, and keeping the same
application side approach to ProtonC, while running 0.9, I would expect the
Deliveries to be eventually freed from heap. Or is there a new plan on how to
approach this ?
I'm calling pn_messenger_settle with PN_CUMMULATIVE for both input and output
trackers, and the delivery-local.settled gets set to true (verified).
Here is the dump of Deliveries, after there is one message received:
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
Then my application code sends a message to broker. The previous, now fully
settled Delivery, is not freed - here is the dump (there are now two
Deliveries on heap):
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
Continuing, by received one more message and also sending one to broker,
there are now four Deliveries on the heap.
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x01\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
And so on, until it eventually runs out of heap.
I have done an extensive debug session, looking at the refcounts, behavior
inside the pn_delivery_finalize(), places this gets called from, etc.
One thing that hits the eye is the missing pn_full_settle() function, which
is now replaced somehow differently by other code. Also, the tpwork-ers used
to decref the Disposions, this is also modified for 0.9 (compared to 0.8).
I'm not sure (yet) what is going on in there, it also might just be some
error of mine (so I'm not immediately describing this as a bug, and I might
provide more information as the situation unravels).
At this moment, I would appreciate some hints on this topic, and also a
review of the particular functionality (dispositon of Deliveries) in ProtonC
0.9.
Thanks a lot !
(minor edit - text formatting - on 12/21/2014)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-784) Settled Deliveries keep piling up, and do not seem to get freed from heap
[
https://issues.apache.org/jira/browse/PROTON-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265271#comment-14265271
]
Chuck Rolke commented on PROTON-784:
I'm sure there is an issue. It may not be this issue.
Settled Deliveries keep piling up, and do not seem to get freed from heap
-
Key: PROTON-784
URL: https://issues.apache.org/jira/browse/PROTON-784
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: German Shepherd (PrE)
Fix For: 0.9
When running the ProtonC 0.8, this issue was not present.
Then, in ProtonC 0.9 (Git trunk of 12/19/2014), there are changes in a way
the deliveries are handled (engine.c).
Correct me if I'm wrong, but given the behavior in 0.8, and keeping the same
application side approach to ProtonC, while running 0.9, I would expect the
Deliveries to be eventually freed from heap. Or is there a new plan on how to
approach this ?
I'm calling pn_messenger_settle with PN_CUMMULATIVE for both input and output
trackers, and the delivery-local.settled gets set to true (verified).
Here is the dump of Deliveries, after there is one message received:
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
Then my application code sends a message to broker. The previous, now fully
settled Delivery, is not freed - here is the dump (there are now two
Deliveries on heap):
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
Continuing, by received one more message and also sending one to broker,
there are now four Deliveries on the heap.
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x01\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
And so on, until it eventually runs out of heap.
I have done an extensive debug session, looking at the refcounts, behavior
inside the pn_delivery_finalize(), places this gets called from, etc.
One thing that hits the eye is the missing pn_full_settle() function, which
is now replaced somehow differently by other code. Also, the tpwork-ers used
to decref the Disposions, this is also modified for 0.9 (compared to 0.8).
I'm not sure (yet) what is going on in there, it also might just be some
error of mine (so I'm not immediately describing this as a bug, and I might
provide more information as the situation unravels).
At this moment, I would appreciate some hints on this topic, and also a
review of the particular functionality (dispositon of Deliveries) in ProtonC
0.9.
Thanks a lot !
(minor edit - text formatting - on 12/21/2014)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-784) Settled Deliveries keep piling up, and do not seem to get freed from heap
[
https://issues.apache.org/jira/browse/PROTON-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265090#comment-14265090
]
Chuck Rolke commented on PROTON-784:
On Linux this issue appears resolved. On Windows it's still an issue and I'm
investigating further from my end.
-Cheers
Settled Deliveries keep piling up, and do not seem to get freed from heap
-
Key: PROTON-784
URL: https://issues.apache.org/jira/browse/PROTON-784
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: German Shepherd (PrE)
Fix For: 0.9
When running the ProtonC 0.8, this issue was not present.
Then, in ProtonC 0.9 (Git trunk of 12/19/2014), there are changes in a way
the deliveries are handled (engine.c).
Correct me if I'm wrong, but given the behavior in 0.8, and keeping the same
application side approach to ProtonC, while running 0.9, I would expect the
Deliveries to be eventually freed from heap. Or is there a new plan on how to
approach this ?
I'm calling pn_messenger_settle with PN_CUMMULATIVE for both input and output
trackers, and the delivery-local.settled gets set to true (verified).
Here is the dump of Deliveries, after there is one message received:
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
Then my application code sends a message to broker. The previous, now fully
settled Delivery, is not freed - here is the dump (there are now two
Deliveries on heap):
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
Continuing, by received one more message and also sending one to broker,
there are now four Deliveries on the heap.
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x01\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
And so on, until it eventually runs out of heap.
I have done an extensive debug session, looking at the refcounts, behavior
inside the pn_delivery_finalize(), places this gets called from, etc.
One thing that hits the eye is the missing pn_full_settle() function, which
is now replaced somehow differently by other code. Also, the tpwork-ers used
to decref the Disposions, this is also modified for 0.9 (compared to 0.8).
I'm not sure (yet) what is going on in there, it also might just be some
error of mine (so I'm not immediately describing this as a bug, and I might
provide more information as the situation unravels).
At this moment, I would appreciate some hints on this topic, and also a
review of the particular functionality (dispositon of Deliveries) in ProtonC
0.9.
Thanks a lot !
(minor edit - text formatting - on 12/21/2014)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-784) Settled Deliveries keep piling up, and do not seem to get freed from heap
[
https://issues.apache.org/jira/browse/PROTON-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14262956#comment-14262956
]
Chuck Rolke commented on PROTON-784:
I built with your last patch but the issue persists.
Settled Deliveries keep piling up, and do not seem to get freed from heap
-
Key: PROTON-784
URL: https://issues.apache.org/jira/browse/PROTON-784
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: German Shepherd (PrE)
Fix For: 0.9
When running the ProtonC 0.8, this issue was not present.
Then, in ProtonC 0.9 (Git trunk of 12/19/2014), there are changes in a way
the deliveries are handled (engine.c).
Correct me if I'm wrong, but given the behavior in 0.8, and keeping the same
application side approach to ProtonC, while running 0.9, I would expect the
Deliveries to be eventually freed from heap. Or is there a new plan on how to
approach this ?
I'm calling pn_messenger_settle with PN_CUMMULATIVE for both input and output
trackers, and the delivery-local.settled gets set to true (verified).
Here is the dump of Deliveries, after there is one message received:
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
Then my application code sends a message to broker. The previous, now fully
settled Delivery, is not freed - here is the dump (there are now two
Deliveries on heap):
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
Continuing, by received one more message and also sending one to broker,
there are now four Deliveries on the heap.
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x01\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
And so on, until it eventually runs out of heap.
I have done an extensive debug session, looking at the refcounts, behavior
inside the pn_delivery_finalize(), places this gets called from, etc.
One thing that hits the eye is the missing pn_full_settle() function, which
is now replaced somehow differently by other code. Also, the tpwork-ers used
to decref the Disposions, this is also modified for 0.9 (compared to 0.8).
I'm not sure (yet) what is going on in there, it also might just be some
error of mine (so I'm not immediately describing this as a bug, and I might
provide more information as the situation unravels).
At this moment, I would appreciate some hints on this topic, and also a
review of the particular functionality (dispositon of Deliveries) in ProtonC
0.9.
Thanks a lot !
(minor edit - text formatting - on 12/21/2014)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-784) Settled Deliveries keep piling up, and do not seem to get freed from heap
[
https://issues.apache.org/jira/browse/PROTON-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257524#comment-14257524
]
Chuck Rolke commented on PROTON-784:
A simple reproducer is available in the Qpid messaging examples. Add
{noformat}
diff --git a/qpid/cpp/examples/messaging/client.cpp
b/qpid/cpp/examples/messaging/client.cpp
index d695dd9..f580d45 100644
--- a/qpid/cpp/examples/messaging/client.cpp
+++ b/qpid/cpp/examples/messaging/client.cpp
@@ -61,12 +61,18 @@ int main(int argc, char** argv) {
Message request;
request.setReplyTo(responseQueue);
+for (int j=0; j5000; j++) {
+std::cout pass j std::endl;
+if (1250 == j) {
+std::cout Break here. Next transmit won't go std::endl;
+}
for (int i=0; i4; i++) {
request.setContentObject(s[i]);
sender.send(request);
Message response = receiver.fetch();
std::cout request.getContentObject() -
response.getContentObject() std::endl;
}
+}
connection.close();
return 0;
} catch(const std::exception error) {
{noformat}
The oddball 1250 comes from a limit set in cpp/src/qpid/broker/amqp/Outgoing.cpp
..., deliveries(5000), ...
Deliveries are supposed to come back from proton through
OutgoingFromQueue::handle
but that function is never called.
Settled Deliveries keep piling up, and do not seem to get freed from heap
-
Key: PROTON-784
URL: https://issues.apache.org/jira/browse/PROTON-784
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.9
Reporter: German Shepherd (PrE)
Fix For: 0.9
When running the ProtonC 0.8, this issue was not present.
Then, in ProtonC 0.9 (Git trunk of 12/19/2014), there are changes in a way
the deliveries are handled (engine.c).
Correct me if I'm wrong, but given the behavior in 0.8, and keeping the same
application side approach to ProtonC, while running 0.9, I would expect the
Deliveries to be eventually freed from heap. Or is there a new plan on how to
approach this ?
I'm calling pn_messenger_settle with PN_CUMMULATIVE for both input and output
trackers, and the delivery-local.settled gets set to true (verified).
Here is the dump of Deliveries, after there is one message received:
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
Then my application code sends a message to broker. The previous, now fully
settled Delivery, is not freed - here is the dump (there are now two
Deliveries on heap):
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
Continuing, by received one more message and also sending one to broker,
there are now four Deliveries on the heap.
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x00\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
{{tag=, local.type=36, remote.type=0, local.settled=1, remote.settled=1,
updated=0, current=0, writable=0, readable=0, work=0}}
{{tag=\x01\x00\x00\x00\x00\x00\x00\x00, local.type=36, remote.type=36,
local.settled=1, remote.settled=1, updated=0, current=0, writable=0,
readable=0, work=0}}
And so on, until it eventually runs out of heap.
I have done an extensive debug session, looking at the refcounts, behavior
inside the pn_delivery_finalize(), places this gets called from, etc.
One thing that hits the eye is the missing pn_full_settle() function, which
is now replaced somehow differently by other code. Also, the tpwork-ers used
to decref the Disposions, this is also modified for 0.9 (compared to 0.8).
I'm not sure (yet) what is going on in there, it also might just be some
error of mine (so I'm not immediately describing this as a bug, and I might
provide more information as the situation unravels).
At this moment, I would appreciate some hints on this topic, and also a
review of the particular functionality (dispositon of Deliveries) in ProtonC
0.9.
Thanks a lot !
(minor edit - text formatting - on 12/21/2014)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-783) proton ignores stolen link attempts
Chuck Rolke created PROTON-783: -- Summary: proton ignores stolen link attempts Key: PROTON-783 URL: https://issues.apache.org/jira/browse/PROTON-783 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.8 Reporter: Chuck Rolke A client tries to create two links with the same name over the same connection/session. Spec section 2.6.1 suggests that the first link is closed with status 'stolen' and the second link is created. Currently the second link attach is ignored [1]. The client attach goes into the broker and no attach or error comes out. The same behavior happens to qpidd and to activemq 5.11 brokers. A trace is available here: https://issues.apache.org/jira/secure/attachment/12687862/qpidd-broker-ignores-link-steal-attempt.htm [1] The client link state is half-half-attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-720) [Windows IO] Prints warning string as %d
[
https://issues.apache.org/jira/browse/PROTON-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved PROTON-720.
Resolution: Fixed
Fix Version/s: 0.8
Fixed with 1633619
[Windows IO] Prints warning string as %d
Key: PROTON-720
URL: https://issues.apache.org/jira/browse/PROTON-720
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Windows
Reporter: Chuck Rolke
Fix For: 0.8
Source code:
{noformat}
fprintf(stderr, Can't load WinSock: %d\n, pn_error_text(io-error));
{noformat}
prints warning
{noformat}
2..\..\proton-c\src\windows\io.c(86): warning C4313: 'fprintf' :
'%d' in format string conflicts with argument 1 of type 'const char *'
{noformat}
using VS2013/x64. VS2008/2010 do not warn.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-720) [Windows IO] Prints warning string as %d
Chuck Rolke created PROTON-720:
--
Summary: [Windows IO] Prints warning string as %d
Key: PROTON-720
URL: https://issues.apache.org/jira/browse/PROTON-720
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Windows
Reporter: Chuck Rolke
Source code:
{noformat}
fprintf(stderr, Can't load WinSock: %d\n, pn_error_text(io-error));
{noformat}
prints warning
{noformat}
2..\..\proton-c\src\windows\io.c(86): warning C4313: 'fprintf' :
'%d' in format string conflicts with argument 1 of type 'const char *'
{noformat}
using VS2013/x64. VS2008/2010 do not warn.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-710) Library cproton.so missing from build
[
https://issues.apache.org/jira/browse/PROTON-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14160282#comment-14160282
]
Chuck Rolke commented on PROTON-710:
Do you have Swig installed on the build host? None of the bindings is built
without it.
{noformat}
find_package(SWIG)
if (SWIG_FOUND)
add_subdirectory(bindings)
endif (SWIG_FOUND)
{noformat}
If you do have Swig installed then please post attach a log of your build and
we can track down where it's failing.
Library cproton.so missing from build
-
Key: PROTON-710
URL: https://issues.apache.org/jira/browse/PROTON-710
Project: Qpid Proton
Issue Type: Bug
Components: php-binding
Affects Versions: 0.7
Environment: Debian 3.2.51-1 x86_64 GNU/Linux
Reporter: Haag Olivier
After the build, there is no *cproton.so* generated although it's what
*cproton.ini* is pointing on.
I check in my module's list and there is no trace of proton.
So I add manualy the *cproton.ini* to my php5/conf.d dir and when I check the
module's list I get:
{quote}PHP Startup: Unable to load dynamic library
'/usr/lib/php5/20100525/cproton.so' - /usr/lib/php5/20100525/cproton.so:
cannot open shared object file: No such file or directory in Unknown on line
0{quote}
There is only those ones:
- libqpid-proton.so
- libqpid-proton.so.2
- libqpid-proton.so.2.0.0
So I try to load them in php but I get this when I get the module's list:
{quote}PHP Warning: PHP Startup: Invalid library (maybe not a PHP library)
‘libqpid-proton.so’ in Unknown on line 0{quote}
I'm probably wrong somewhere so I ask you here what should I do ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (PROTON-709) [proton-c] Windows 64-bit transport issue
[
https://issues.apache.org/jira/browse/PROTON-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke closed PROTON-709.
--
Resolution: Not a Problem
Fix Version/s: 0.8
Other system builds fine. Local machine had corrupted SVN checkout with
dispatcher.h file where it did not belong.
Notes:
1. File was harmless until recent include file ordering changes 'woke it up'.
2. SVN seems to go out of its way to hide stray files.
[proton-c] Windows 64-bit transport issue
-
Key: PROTON-709
URL: https://issues.apache.org/jira/browse/PROTON-709
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Windows
Reporter: Chuck Rolke
Fix For: 0.8
Today's trunk build of qpid and proton yield bad results for 64-bit proton
consumers. Have not gotten to the fundamental issue yet but current analysis
shows:
|| ||32-bit broker||64-bit broker||
|32-bit client| OK | broker crashes|
|64-bit client| client crashes | broker crashes|
In the 64-bit client, 64-bit broker case the broker fails with:
{noformat}
Unhandled exception at 0x7ffa83e39b2b (qpid-protond.dll) in qpidd.exe:
0xC005: Access violation reading location 0x0021.
{noformat}
dereferencing a null transport at
{noformat}
int pn_do_open(pn_dispatcher_t *disp)
{
pn_transport_t *transport = disp-transport;
pn_connection_t *conn = transport-connection; ---
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-706) CMake fails - get_filename_component unknown component DIRECTORY
[ https://issues.apache.org/jira/browse/PROTON-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved PROTON-706. Resolution: Fixed Fix Version/s: 0.8 Resolved by astitcher at r1628503. CMake fails - get_filename_component unknown component DIRECTORY Key: PROTON-706 URL: https://issues.apache.org/jira/browse/PROTON-706 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: windows cmake 2.8.11.2 Reporter: Chuck Rolke Fix For: 0.8 PROTON-705 breaks my CI system. Do we require new cmake now? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-709) [proton-c] Windows 64-bit transport issue
Chuck Rolke created PROTON-709:
--
Summary: [proton-c] Windows 64-bit transport issue
Key: PROTON-709
URL: https://issues.apache.org/jira/browse/PROTON-709
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Windows
Reporter: Chuck Rolke
Today's trunk build of qpid and proton yield bad results for 64-bit proton
consumers. Have not gotten to the fundamental issue yet but current analysis
shows:
|| ||32-bit broker||64-bit broker||
|32-bit client| OK | broker crashes|
|64-bit client| client crashes | broker crashes|
In the 64-bit client, 64-bit broker case the broker fails with:
{noformat}
Unhandled exception at 0x7ffa83e39b2b (qpid-protond.dll) in qpidd.exe:
0xC005: Access violation reading location 0x0021.
{noformat}
dereferencing a null transport at
{noformat}
int pn_do_open(pn_dispatcher_t *disp)
{
pn_transport_t *transport = disp-transport;
pn_connection_t *conn = transport-connection; ---
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-706) CMake fails - get_filename_component unknown component DIRECTORY
Chuck Rolke created PROTON-706: -- Summary: CMake fails - get_filename_component unknown component DIRECTORY Key: PROTON-706 URL: https://issues.apache.org/jira/browse/PROTON-706 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: windows cmake 2.8.11.2 Reporter: Chuck Rolke PROTON-705 breaks my CI system. Do we require new cmake now? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-699) Messenger installed examples send,recv do not compile
Chuck Rolke created PROTON-699: -- Summary: Messenger installed examples send,recv do not compile Key: PROTON-699 URL: https://issues.apache.org/jira/browse/PROTON-699 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Windows and Linux Reporter: Chuck Rolke The cmake packaging of the install directory install/proton/examples/messenger collapses the files from /pncompat/internal into /pncompat. Folder /pncompat/internal is absent. Compiles fails since the sources use '#include internal/getopt.h' and the file is not found. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-699) Messenger installed examples send,recv do not compile
[ https://issues.apache.org/jira/browse/PROTON-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved PROTON-699. Resolution: Fixed Fix Version/s: 0.8 Trivial fix in top level cmake. Messenger installed examples send,recv do not compile - Key: PROTON-699 URL: https://issues.apache.org/jira/browse/PROTON-699 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Windows and Linux Reporter: Chuck Rolke Fix For: 0.8 The cmake packaging of the install directory install/proton/examples/messenger collapses the files from /pncompat/internal into /pncompat. Folder /pncompat/internal is absent. Compiles fails since the sources use '#include internal/getopt.h' and the file is not found. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-643) Malloc result used without testing for null
Chuck Rolke created PROTON-643:
--
Summary: Malloc result used without testing for null
Key: PROTON-643
URL: https://issues.apache.org/jira/browse/PROTON-643
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Reporter: Chuck Rolke
{noformat}
pn_buffer_t *buf = (pn_buffer_t *) malloc(sizeof(pn_buffer_t));
buf-capacity = capacity;
{noformat}
Many calls to malloc are properly checked but not all.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (PROTON-609) Assert in messenger.py test causes core dump
Chuck Rolke created PROTON-609:
--
Summary: Assert in messenger.py test causes core dump
Key: PROTON-609
URL: https://issues.apache.org/jira/browse/PROTON-609
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Windows or Linux
Reporter: Chuck Rolke
This assert:
{noformat}
Index: tests/python/proton_tests/messenger.py
===
--- tests/python/proton_tests/messenger.py (revision 1602460)
+++ tests/python/proton_tests/messenger.py (working copy)
@@ -843,6 +843,7 @@
msg2 = Message()
msg2.address = self.address + /msg2
self.client.put(msg2)
+assert False, Whoops!
self.pump()
assert self.server.incoming == 1, self.server.incoming
assert self.server.receiving == 8, self.server.receiving
{noformat}
causes a core dump in NBMessengerTest.teardown when the code tries to stop the
client. A user may work around this issue by
{noformat}
+ if msgr.outgoing 0:
+msgr.settle()
+ while msgr.incoming 0:
+msgr.get()
+ msgr.stop()
{noformat}
when all he wants is msgr.stop().
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (PROTON-603) Python testReclaimCredit fails on Windows
[
https://issues.apache.org/jira/browse/PROTON-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved PROTON-603.
Resolution: Fixed
Fix Version/s: 0.8
Commit 1602016 from c...@apache.org in branch 'proton/trunk'
[ https://svn.apache.org/r1602016 ]
Python testReclaimCredit fails on Windows
-
Key: PROTON-603
URL: https://issues.apache.org/jira/browse/PROTON-603
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Windows
Reporter: Chuck Rolke
Fix For: 0.8
Attachments: messenger.py.patch
Two loops have a set of asserts between them:
{noformat}
# and none for this new client
client2 = Messenger(client2)
client2.blocking = False
client2.start()
msg3 = Message()
msg3.address = self.address + /msg3
client2.put(msg3)
while client2.work(0):
self.pump()
assert self.server.incoming == 1, self.server.incoming --
assert self.server.receiving == 8, self.server.receiving --
# eventually, credit will rebalance and all links will
# send a message
deadline = time() + self.timeout
while time() deadline:
sleep(.1)
self.pump()
client2.work(0)
if self.server.incoming == 3:
break;
assert self.server.incoming == 3, self.server.incoming
assert self.server.receiving == 6, self.server.receiving
{noformat}
On windows the rebalance starts happening during the while loop at lines 8
and 9, triggering the asserts at line 10 and 11. The proposed fix is to
remove the asserts at lines 10 and 11 and fall through to the timed while
loop that shows the rebalanced values.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (PROTON-606) Python testReclaimCredit exposes test server messenger hang on windows
Chuck Rolke created PROTON-606: -- Summary: Python testReclaimCredit exposes test server messenger hang on windows Key: PROTON-606 URL: https://issues.apache.org/jira/browse/PROTON-606 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Windows Server 2012 R2 Python 2.6.1 Reporter: Chuck Rolke PROTON-603 testCreditReclaim exposes another issue on Windows platforms. After the test failed at some assert then the teardown() function had another assert because the server never stopped. The second assert overwrites the first assert and hides the original error. teardown() can't call client2.work or stimulate client2 to shut down. This leaves the server stuck. The proposed fix is to promote client2 to be a class member and drive it in parallel with client and server. Other miscellaneous tweaks are required to get the package working on windows. Please see the review board entry. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (PROTON-595) Python test function MessengerApp.start fails on Windows
[
https://issues.apache.org/jira/browse/PROTON-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved PROTON-595.
Resolution: Fixed
Fix Version/s: 0.8
Completed: At revision: 1602290
Python test function MessengerApp.start fails on Windows
Key: PROTON-595
URL: https://issues.apache.org/jira/browse/PROTON-595
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Windows ctest
Reporter: Chuck Rolke
Fix For: 0.8
The function uses Popen() where the first cmd arg is the name of a python
file. Windows doesn't honor the #! at the beginning of the file and then
fails with
{noformat}
[Error 193] %1 is not a valid Win32 application
{noformat}
This code could also be improved by printing the exception error text along
with the path setting hint.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (PROTON-603) Python testReclaimCredit fails on Windows
Chuck Rolke created PROTON-603:
--
Summary: Python testReclaimCredit fails on Windows
Key: PROTON-603
URL: https://issues.apache.org/jira/browse/PROTON-603
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Windows
Reporter: Chuck Rolke
Two loops have a set of asserts between them:
{noformat}
# and none for this new client
client2 = Messenger(client2)
client2.blocking = False
client2.start()
msg3 = Message()
msg3.address = self.address + /msg3
client2.put(msg3)
while client2.work(0):
self.pump()
assert self.server.incoming == 1, self.server.incoming --
assert self.server.receiving == 8, self.server.receiving --
# eventually, credit will rebalance and all links will
# send a message
deadline = time() + self.timeout
while time() deadline:
sleep(.1)
self.pump()
client2.work(0)
if self.server.incoming == 3:
break;
assert self.server.incoming == 3, self.server.incoming
assert self.server.receiving == 6, self.server.receiving
{noformat}
On windows the rebalance starts happening during the while loop at lines 8 and
9, triggering the asserts at line 10 and 11. The proposed fix is to remove the
asserts at lines 10 and 11 and fall through to the timed while loop that shows
the rebalanced values.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (PROTON-603) Python testReclaimCredit fails on Windows
[
https://issues.apache.org/jira/browse/PROTON-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke updated PROTON-603:
---
Attachment: messenger.py.patch
Don't assert on values that are in the process of changing
Python testReclaimCredit fails on Windows
-
Key: PROTON-603
URL: https://issues.apache.org/jira/browse/PROTON-603
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Windows
Reporter: Chuck Rolke
Attachments: messenger.py.patch
Two loops have a set of asserts between them:
{noformat}
# and none for this new client
client2 = Messenger(client2)
client2.blocking = False
client2.start()
msg3 = Message()
msg3.address = self.address + /msg3
client2.put(msg3)
while client2.work(0):
self.pump()
assert self.server.incoming == 1, self.server.incoming --
assert self.server.receiving == 8, self.server.receiving --
# eventually, credit will rebalance and all links will
# send a message
deadline = time() + self.timeout
while time() deadline:
sleep(.1)
self.pump()
client2.work(0)
if self.server.incoming == 3:
break;
assert self.server.incoming == 3, self.server.incoming
assert self.server.receiving == 6, self.server.receiving
{noformat}
On windows the rebalance starts happening during the while loop at lines 8
and 9, triggering the asserts at line 10 and 11. The proposed fix is to
remove the asserts at lines 10 and 11 and fall through to the timed while
loop that shows the rebalanced values.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (PROTON-601) Proton-C Windows swig warning: nested union not supported
[
https://issues.apache.org/jira/browse/PROTON-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke closed PROTON-601.
--
Resolution: Later
Fix Version/s: 0.7
Don't use swig 3.0.1 but use swig 2.0.10.
http://sourceforge.net/projects/swig/files/swigwin/swigwin-2.0.10/swigwin-2.0.10.zip/download?use_mirror=iweb
Proton-C Windows swig warning: nested union not supported
-
Key: PROTON-601
URL: https://issues.apache.org/jira/browse/PROTON-601
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: 0.7
Environment: Windows Server 2012 R2
Visual Studio 2010, x86 Win32
Swig 3.0.1
Python 2.6.1
Cmake 2.8.12.2
Ruby 1.8.6
Reporter: Chuck Rolke
Fix For: 0.7
Building the cproton object elicits a warning:
{noformat}
9D:\Users\crolke\svn\proton\proton-c\include\proton\codec.h(87):
warning 312: Nested union not currently supported (ignored).
{noformat}
The fix seems fairly direct: don't nest the union. See review board.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (PROTON-592) Python test function common _ready() fails on windows
[ https://issues.apache.org/jira/browse/PROTON-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke closed PROTON-592. -- Resolution: Fixed Fix Version/s: 0.8 Python test function common _ready() fails on windows - Key: PROTON-592 URL: https://issues.apache.org/jira/browse/PROTON-592 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Windows ctest Reporter: Chuck Rolke Fix For: 0.8 Test code asserts READY\n that never works on windows. Fix by using READY + os.linesep -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (PROTON-596) There is no equivalent to 'config.sh' for windows
[ https://issues.apache.org/jira/browse/PROTON-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved PROTON-596. Resolution: Fixed Fix Version/s: 0.8 There is no equivalent to 'config.sh' for windows - Key: PROTON-596 URL: https://issues.apache.org/jira/browse/PROTON-596 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Proton on windows Reporter: Chuck Rolke Fix For: 0.8 ctest fails to find compiled C tests. Some environment settings are needed in addition to those supplied by cmake/ctest. Linux users have the luxury of config.sh to steer their environment correctly for tests built in proton/build. Windows users need the same. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-601) Proton-C Windows swig warning: nested union not supported
Chuck Rolke created PROTON-601:
--
Summary: Proton-C Windows swig warning: nested union not supported
Key: PROTON-601
URL: https://issues.apache.org/jira/browse/PROTON-601
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: 0.7
Environment: Windows Server 2012 R2
Visual Studio 2010, x86 Win32
Swig 3.0.1
Python 2.6.1
Cmake 2.8.12.2
Ruby 1.8.6
Reporter: Chuck Rolke
Building the cproton object elicits a warning:
{noformat}
9D:\Users\crolke\svn\proton\proton-c\include\proton\codec.h(87):
warning 312: Nested union not currently supported (ignored).
{noformat}
The fix seems fairly direct: don't nest the union. See review board.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (PROTON-598) CProton python binding fails to build Windows debug configuration
Chuck Rolke created PROTON-598: -- Summary: CProton python binding fails to build Windows debug configuration Key: PROTON-598 URL: https://issues.apache.org/jira/browse/PROTON-598 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Windows, Python 2.6.1 Reporter: Chuck Rolke cpython fails to link with file python26_d.lib not found. The issue here is that the windows installer for python does not install the debug versions (identified by the _d suffix) of the python libraries. Wisdom from the web suggests either to build your own debug python or to debug using a release build. Links using the RelWithDebInfo work just fine and I can make progress running ctest. Just a heads up for anyone who wants to run ctest with Debug builds. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-546) C++ Windows warnings: conversions and possible loss of data
[
https://issues.apache.org/jira/browse/PROTON-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14020381#comment-14020381
]
Chuck Rolke commented on PROTON-546:
I confused PROTON-546 and PROTON-596 in a commit message. This commit is for
PROTON-546.
Commit 1601010 from c...@apache.org in branch 'proton/trunk'
[ https://svn.apache.org/r1601010 ]
PROTON-596: Suppress MSVC warnings
This suppression covers:
..\..\proton-c\src\object\object.c(232):
warning C4244: 'argument' : conversion from 'ssize_t' to 'int',
possible loss of data
2..\..\proton-c\src\object\object.c(260):
warning C4267: 'argument' : conversion from 'size_t' to 'int',
possible loss of data
2..\..\proton-c\src\windows\driver.c(777):
warning C4800: 'int' : forcing value to bool 'true' or 'false'
(performance warning)
6..\..\..\..\..\tests\tools\apps\c\msgr-recv.c(90):
warning C4996: 'sscanf': This function or variable may be unsafe.
Consider using sscanf_s instead.
To disable deprecation, use _CRT_SECURE_NO_WARNINGS
This covers the majority of the warnings. A typical 64-bit compile has 172
warnings making real problems harder to see. It also follows the
pattern used in Qpid proper.
* C4244 and C4267 could still be real problems.
Try enabling -Wconversion in GCC if you want to be pedantic in Qpid or
Proton.
* C4800 is probably not a risk as it's a fairly idiomatic pattern in C.
* C4996 is MSVC complaining of functions that consume buffers using
{pointer} and not {pointer, size}. They have been the source of seg
faults and innumerable security vulnerabilities throughout the years.
C++ Windows warnings: conversions and possible loss of data
---
Key: PROTON-546
URL: https://issues.apache.org/jira/browse/PROTON-546
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.6
Reporter: Chuck Rolke
Assignee: Andrew Stitcher
Attachments: PROTON-546-size-warnings.txt
Windows has other warnings similar to PROTON-545, especially during 64-bit
builds.
See attached file for details.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (PROTON-596) There is no equivalent to 'config.sh' for windows
[ https://issues.apache.org/jira/browse/PROTON-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14020390#comment-14020390 ] Chuck Rolke commented on PROTON-596: The previous subversion services comment for Commit 1601010 from c...@apache.org in branch 'proton/trunk' should be in PROTON-546 and not here. Sorry for the noise. There is no equivalent to 'config.sh' for windows - Key: PROTON-596 URL: https://issues.apache.org/jira/browse/PROTON-596 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Proton on windows Reporter: Chuck Rolke ctest fails to find compiled C tests. Some environment settings are needed in addition to those supplied by cmake/ctest. Linux users have the luxury of config.sh to steer their environment correctly for tests built in proton/build. Windows users need the same. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-599) Visual Studio warnings - enumeration update
Chuck Rolke created PROTON-599: -- Summary: Visual Studio warnings - enumeration update Key: PROTON-599 URL: https://issues.apache.org/jira/browse/PROTON-599 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Visual Studio 2008, 2010, 2012, 2013 Reporter: Chuck Rolke After suppressing the 'usual' warnings (see PROTON-546, http://svn.apache.org/r1601010) and running some later compiler versions a new list of errors emerges. Please see attached listing for details. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-599) Visual Studio warnings - enumeration update
[ https://issues.apache.org/jira/browse/PROTON-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated PROTON-599: --- Attachment: vs-proton-warnings.txt Today's crop of Visual Studio warnings. Before suppressing other warnings this list exceeded 3000 lines. Visual Studio warnings - enumeration update --- Key: PROTON-599 URL: https://issues.apache.org/jira/browse/PROTON-599 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Visual Studio 2008, 2010, 2012, 2013 Reporter: Chuck Rolke Attachments: vs-proton-warnings.txt After suppressing the 'usual' warnings (see PROTON-546, http://svn.apache.org/r1601010) and running some later compiler versions a new list of errors emerges. Please see attached listing for details. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-592) Python test function common _ready() fails on windows
Chuck Rolke created PROTON-592: -- Summary: Python test function common _ready() fails on windows Key: PROTON-592 URL: https://issues.apache.org/jira/browse/PROTON-592 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Windows ctest Reporter: Chuck Rolke Test code asserts READY\n that never works on windows. Fix by using READY + os.linesep -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-595) Python test function MessengerApp.start fails on Windows
Chuck Rolke created PROTON-595:
--
Summary: Python test function MessengerApp.start fails on Windows
Key: PROTON-595
URL: https://issues.apache.org/jira/browse/PROTON-595
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Windows ctest
Reporter: Chuck Rolke
The function uses Popen() where the first cmd arg is the name of a python file.
Windows doesn't honor the #! at the beginning of the file and then fails with
{noformat}
[Error 193] %1 is not a valid Win32 application
{noformat}
This code could also be improved by printing the exception error text along
with the path setting hint.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (PROTON-596) There is no equivalent to 'config.sh' for windows
Chuck Rolke created PROTON-596: -- Summary: There is no equivalent to 'config.sh' for windows Key: PROTON-596 URL: https://issues.apache.org/jira/browse/PROTON-596 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Proton on windows Reporter: Chuck Rolke ctest fails to find compiled C tests. Some environment settings are needed in addition to those supplied by cmake/ctest. Linux users have the luxury of config.sh to steer their environment correctly for tests built in proton/build. Windows users need the same. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-587) Proton 0.7 fails to compile with Visual Studio 2008
Chuck Rolke created PROTON-587:
--
Summary: Proton 0.7 fails to compile with Visual Studio 2008
Key: PROTON-587
URL: https://issues.apache.org/jira/browse/PROTON-587
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Visual Studio 2008 x86 (32-bit) debug or relwithdebinfo.
Note: VS2008 x64 (64-bit) works fine; VS2010 x86,x64 work fine.
Reporter: Chuck Rolke
Project recv.c fails to compile with size_t undefined.
{noformat}
6-- Build started: Project: recv, Configuration: Debug Win32 --
6Compiling...
6recv.c
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(60) : error C2016: C
requires that a struct or union has at least one member
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(60) : error C2061: syntax
error : identifier 'size_t'
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(62) : error C2059: syntax
error : '}'
...
{noformat}
The issue if fixed easy enough with the inclusion of stddef.h or stdlib.h in
types.h
{noformat}
diff --git a/proton-c/include/proton/types.h b/proton-c/include/proton/types.h
index 4182f25..d26d6a2 100644
--- a/proton-c/include/proton/types.h
+++ b/proton-c/include/proton/types.h
@@ -23,6 +23,7 @@
*/
#include proton/import_export.h
+#include stddef.h
#include sys/types.h
#include proton/type_compat.h
{noformat}
Apologies for not catching this sooner but I've been using VS2010 almost
exclusively of late. The fix looks harmless enough but I'm wondering if anyone
has an reason to select stddef over stdlib or if there's a better place to have
the #include.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (PROTON-587) Proton 0.7 fails to compile with Visual Studio 2008
[
https://issues.apache.org/jira/browse/PROTON-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved PROTON-587.
Resolution: Fixed
Fix Version/s: 0.8
Proton 0.7 fails to compile with Visual Studio 2008
---
Key: PROTON-587
URL: https://issues.apache.org/jira/browse/PROTON-587
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Visual Studio 2008 x86 (32-bit) debug or relwithdebinfo.
Note: VS2008 x64 (64-bit) works fine; VS2010 x86,x64 work fine.
Reporter: Chuck Rolke
Assignee: Andrew Stitcher
Fix For: 0.8
Project recv.c fails to compile with size_t undefined.
{noformat}
6-- Build started: Project: recv, Configuration: Debug Win32 --
6Compiling...
6recv.c
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(60) : error C2016: C
requires that a struct or union has at least one member
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(60) : error C2061:
syntax error : identifier 'size_t'
6P:\qpid-proton-0.7\proton-c\include\proton/types.h(62) : error C2059:
syntax error : '}'
...
{noformat}
The issue if fixed easy enough with the inclusion of stddef.h or stdlib.h in
types.h
{noformat}
diff --git a/proton-c/include/proton/types.h b/proton-c/include/proton/types.h
index 4182f25..d26d6a2 100644
--- a/proton-c/include/proton/types.h
+++ b/proton-c/include/proton/types.h
@@ -23,6 +23,7 @@
*/
#include proton/import_export.h
+#include stddef.h
#include sys/types.h
#include proton/type_compat.h
{noformat}
Apologies for not catching this sooner but I've been using VS2010 almost
exclusively of late. The fix looks harmless enough but I'm wondering if
anyone has an reason to select stddef over stdlib or if there's a better
place to have the #include.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (PROTON-552) examples fail to build on windows
[ https://issues.apache.org/jira/browse/PROTON-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13957608#comment-13957608 ] Chuck Rolke commented on PROTON-552: This issue is a duplicate of PROTON-547 examples fail to build on windows - Key: PROTON-552 URL: https://issues.apache.org/jira/browse/PROTON-552 Project: Qpid Proton Issue Type: Bug Reporter: Rafael H. Schloming Assignee: Andrew Stitcher -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-547) C Build failure on Windows
Chuck Rolke created PROTON-547:
--
Summary: C Build failure on Windows
Key: PROTON-547
URL: https://issues.apache.org/jira/browse/PROTON-547
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.7
Environment: Visual Studio 2010, 32-bit.
cmake 2.8.11.2
Reporter: Chuck Rolke
Projects send and recv fail.
{noformat}
7-- Build started: Project: recv, Configuration: RelWithDebInfo Win32
--
7Build started 3/28/2014 12:00:02 PM.
7PrepareForBuild:
7 Creating directory P:\build_2010_x86\examples\messenger\c\RelWithDebInfo\.
7InitializeBuildStatus:
7 Creating recv.dir\RelWithDebInfo\recv.unsuccessfulbuild because
AlwaysCreate was specified.
7CustomBuild:
7 Building Custom Rule P:/examples/messenger/c/CMakeLists.txt
7 CMake does not need to re-run because
P:\build_2010_x86\examples\messenger\c\CMakeFiles\generate.stamp is up-to-date.
7ClCompile:
7 recv.c
7P:\proton-c\include\proton/object.h(28): fatal error C1083: Cannot open
include file: 'stdbool.h': No such file or directory
7
7Build FAILED.
7
7Time Elapsed 00:00:00.66
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (PROTON-545) C++ warning converting size_t to float, possible loss of data
Chuck Rolke created PROTON-545: -- Summary: C++ warning converting size_t to float, possible loss of data Key: PROTON-545 URL: https://issues.apache.org/jira/browse/PROTON-545 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Reporter: Chuck Rolke Windows complains on object.c(489) I'm curious that there's a float in proton at all so some serious math must be in play. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-546) C++ Windows warnings: conversions and possible loss of data
Chuck Rolke created PROTON-546: -- Summary: C++ Windows warnings: conversions and possible loss of data Key: PROTON-546 URL: https://issues.apache.org/jira/browse/PROTON-546 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Reporter: Chuck Rolke Windows has other warnings similar to PROTON-545, especially during 64-bit builds. See attached file for details. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-546) C++ Windows warnings: conversions and possible loss of data
[ https://issues.apache.org/jira/browse/PROTON-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated PROTON-546: --- Attachment: PROTON-546-size-warnings.txt Output from a Visual Studio 2010, x64 build. C++ Windows warnings: conversions and possible loss of data --- Key: PROTON-546 URL: https://issues.apache.org/jira/browse/PROTON-546 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Reporter: Chuck Rolke Attachments: PROTON-546-size-warnings.txt Windows has other warnings similar to PROTON-545, especially during 64-bit builds. See attached file for details. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-488) Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application
[ https://issues.apache.org/jira/browse/PROTON-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880309#comment-13880309 ] Chuck Rolke commented on PROTON-488: I never let cmake decide which compiler to use. Even with the x64 Win64 Command Prompt cmake is building a 32-bit solution. Try forcing a 64-bit solution with cmake -G Visual Studio 10 Win64 . Getting the correct solution generated by cmake makes changing properties (steps 3-6) unnecessary. Windows 7 64-bit VS2010 qpid-proton Crash on Startup with Send / Recv Application - Key: PROTON-488 URL: https://issues.apache.org/jira/browse/PROTON-488 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Environment: Windows 7 64-bit VS 2010 Reporter: Frank Quinn Assignee: Cliff Jansen Priority: Critical Attachments: qpid-proton-win64-send-crash.png Steps to recreate: 1. Grab latest 0.6 tarball 2. Start up Visual Studio x64 Win64 Command Prompt (2010) and run cmake . to generate the visual studio files 3. Open Up the newly created Proton.sln in VS2010, right click on qpid-proton and add the path to python to executable directories 4. In the configuration manager, select qpid-proton and select active configuration to be Debug, then select Add to add x64 support, copying win32 configuration in the process. 5. Select qpid-proton properties and remove the hard coded /machine:X86 extra command lines in Linker - Command Line (MACHINE:X64 should already be in the command line above so no need to add here) 6. Right click on qpid-proton and select build Repeat steps 3-6 for send / recv applications. When you run recv, then run send, you'll get a crash with the (soon to be attached) trace. Cheers, Frank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (PROTON-430) cmake install package files created at wrong time and place
Chuck Rolke created PROTON-430:
--
Summary: cmake install package files created at wrong time and
place
Key: PROTON-430
URL: https://issues.apache.org/jira/browse/PROTON-430
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Environment: cmake
Reporter: Chuck Rolke
some files installed to 'lib/' and not to ${INSTALL_LIB_DIR}
file proton-config-version.cmake written to ${LIB_INSTALL_DIR} at cmake
time.This file is better written to ${CMAKE_CURRENT_BINARY_DIR} and installed
at make-install time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-416) Proton needs an icon
Chuck Rolke created PROTON-416: -- Summary: Proton needs an icon Key: PROTON-416 URL: https://issues.apache.org/jira/browse/PROTON-416 Project: Qpid Proton Issue Type: Improvement Affects Versions: 0.5 Reporter: Chuck Rolke The Proton project needs a cool icon. Qpid has the Q with the feather but Qpid Proton doesn't have anything yet. Who has a graphic for us? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-413) [proton-c] Cmake install does not produce package files that work on windows
[
https://issues.apache.org/jira/browse/PROTON-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke updated PROTON-413:
---
Attachment: proton-413-01.patch
This patch splits the library install target from the executable(s) install
target. The library is tagged with 'EXPORT qpid-proton'. Then the EXPORT is
installed along with a version file.
Proton usage:
* Run cmake with -DCMAKE_INSTALL_PREFIX=P:/install
* then 'make install'
Qpid consumer usage:
* in cpp/src/amqp.cmake use find_package(qpid-proton)
* set path to find proton install: SET PATH=P:\install;%PATH%
* run cmake
Result:
Proton is found:
{noformat}
-- qpid-proton_CONFIG ==
P:/install/lib/qpid-proton.cmake/qpid-proton-config.cmake
-- qpid-proton_CONSIDERED_CONFIGS ==
P:/install/lib/qpid-proton.cmake/qpid-proton-config.cmake
-- qpid-proton_CONSIDERED_VERSIONS == 0.5
-- qpid-proton_DIR == P:/install/lib/qpid-proton.cmake
-- qpid-proton_FOUND == 1
-- qpid-proton_VERSION == 0.5
-- qpid-proton_VERSION_COUNT == 2
-- qpid-proton_VERSION_MAJOR == 0
-- qpid-proton_VERSION_MINOR == 5
-- qpid-proton_VERSION_PATCH == 0
-- qpid-proton_VERSION_TWEAK == 0
{noformat}
Comment:
This is not what I really want to check in yet but it gets a windows build
possible.
[proton-c] Cmake install does not produce package files that work on windows
Key: PROTON-413
URL: https://issues.apache.org/jira/browse/PROTON-413
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Environment: Windows
Reporter: Chuck Rolke
Attachments: proton-413-01.patch
Installed proton relies on pkg-config to export the library's location to
consuming projects like Qpid. This doesn't play well on Windows where
pkg-config is not standard.
It would be relatively easy to install export files that enable proton to be
located with find_package(). This feature could be installed in addition to
the pkg-config files and either could be used to find proton.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-413) [proton-c] Cmake install does not produce package files that work on windows
Chuck Rolke created PROTON-413: -- Summary: [proton-c] Cmake install does not produce package files that work on windows Key: PROTON-413 URL: https://issues.apache.org/jira/browse/PROTON-413 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Environment: Windows Reporter: Chuck Rolke Installed proton relies on pkg-config to export the library's location to consuming projects like Qpid. This doesn't play well on Windows where pkg-config is not standard. It would be relatively easy to install export files that enable proton to be located with find_package(). This feature could be installed in addition to the pkg-config files and either could be used to find proton. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-405) [proton-c] Windows install fails to find proton-api.jar file
[
https://issues.apache.org/jira/browse/PROTON-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13745389#comment-13745389
]
Chuck Rolke commented on PROTON-405:
The windows install for proton-api.jar tries to install both the versioned and
unversioned files:
{noformat}
FILE(INSTALL DESTINATION ${CMAKE_INSTALL_PREFIX}/share/java TYPE FILE FILES
D:/Users/crolke/svn/proton/build/proton-j/proton-api/proton-api-0.5.jar
D:/Users/crolke/svn/proton/build/proton-j/proton-api/proton-api.jar
)
{noformat}
In theory there should be a soft link between these two files but in practice
the install just doesn't work.
[proton-c] Windows install fails to find proton-api.jar file
Key: PROTON-405
URL: https://issues.apache.org/jira/browse/PROTON-405
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.4
Environment: Windows install
Reporter: Chuck Rolke
The install script is looking for file
4 CMake Error at proton-j/proton-api/cmake_install.cmake:31 (FILE):
4file INSTALL cannot find
4D:/Users/crolke/svn/proton/build/proton-j/proton-api/proton-api.jar.
but the actual file is versioned
Directory of D:\Users\chug\svn\proton\build\proton-j\proton-api
08/17/2013 10:04 AM 120,690 proton-api-0.5.jar
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-405) [proton-c] Windows install fails to find proton-api.jar file
[ https://issues.apache.org/jira/browse/PROTON-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13743839#comment-13743839 ] Chuck Rolke commented on PROTON-405: Code that handles jave==present and bouncycastle==absent is the issue. A system that has no java at all [log1] works much better than one with java but no bouncycastle [log2]. [log1] This built a system that installs OK S:\Users\chug\svn\Proton\buildcmake -DCMAKE_INSTALL_PREFIX=S:/users/chug/svn/proton/install .. -- Building for: Visual Studio 10 -- Check for working C compiler using: Visual Studio 10 -- Check for working C compiler using: Visual Studio 10 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Visual Studio 10 -- Check for working CXX compiler using: Visual Studio 10 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- PN_VERSION: 0.5 -- Could NOT find Java (missing: Java_JAR_EXECUTABLE Java_JAVAC_EXECUTABLE Java_JAVAH_EXECUTABLE Java_JAVADOC_EXECUTABLE) -- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR (missing: OPENSSL_LIBRARIES OPENSSL_INCLUDE_DIR) -- Looking for clock_gettime -- Looking for clock_gettime - not found. -- Looking for clock_gettime in rt -- Looking for clock_gettime in rt - not found -- Looking for GetSystemTimeAsFileTime -- Looking for GetSystemTimeAsFileTime - found -- Looking for uuid_generate -- Looking for uuid_generate - not found. -- Looking for uuid_generate in uuid -- Looking for uuid_generate in uuid - not found -- Looking for uuid_create -- Looking for uuid_create - not found. -- Looking for UuidToString -- Looking for UuidToString - found -- Looking for strerror_s -- Looking for strerror_s - found -- Looking for atoll -- Looking for atoll - not found. -- Looking for _atoi64 -- Looking for _atoi64 - found -- Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR) -- Found Doxygen: C:/Program Files (x86)/doxygen/bin/doxygen.exe -- Looking for include files INTTYPES_AVAILABLE -- Looking for include files INTTYPES_AVAILABLE - not found. -- Can't locate the valgrind command; no run-time error detection -- Cannot find rspec, skipping rspec tests -- Cannot find both Java and Maven: testing disabled for Proton-J and JNI Bindings -- Configuring done -- Generating done -- Build files have been written to: S:/Users/chug/svn/Proton/build [log2] This is the system that produces the original issue. D:\Users\crolke\svn\proton\buildcmake -DCMAKE_INSTALL_PREFIX=d:/users/crolke/svn/proton/install .. -- Building for: Visual Studio 10 -- Check for working C compiler using: Visual Studio 10 -- Check for working C compiler using: Visual Studio 10 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Visual Studio 10 -- Check for working CXX compiler using: Visual Studio 10 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- PN_VERSION: 0.5 -- Found Java: C:/Program Files/Java/jdk1.6.0_21/bin/java.exe -- Java version: 1.6.0.21. javac is at: C:/Program Files/Java/jdk1.6.0_21/bin/javac.exe Loading Proton's UseJava module -- Locations of Bouncycastle 1.47 jars: BOUNCYCASTLE_BCPROV_JAR-NOTFOUND BOUNCYCASTLE_BCPKIX_JAR-NOTFOUND -- Won't build proton-j-impl because one or more Bouncycastle jars were not found. PROTON_JAR_DEPEND_DIR was: /usr/share/java -- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR (missing: OPENSSL_LIBRARIES OPENSSL_INCLUDE_DIR) -- Looking for clock_gettime -- Looking for clock_gettime - not found. -- Looking for clock_gettime in rt -- Looking for clock_gettime in rt - not found -- Looking for GetSystemTimeAsFileTime -- Looking for GetSystemTimeAsFileTime - found -- Looking for uuid_generate -- Looking for uuid_generate - not found. -- Looking for uuid_generate in uuid -- Looking for uuid_generate in uuid - not found -- Looking for uuid_create -- Looking for uuid_create - not found. -- Looking for UuidToString -- Looking for UuidToString - found -- Looking for strerror_s -- Looking for strerror_s - found -- Looking for atoll -- Looking for atoll - not found. -- Looking for _atoi64 -- Looking for _atoi64 - found -- Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR) -- Found Doxygen: C:/Program Files (x86)/doxygen/bin/doxygen.exe -- Looking for include files INTTYPES_AVAILABLE -- Looking for include files INTTYPES_AVAILABLE - not found. -- Can't locate the valgrind command; no run-time error detection -- Cannot find rspec, skipping rspec tests -- Cannot find both Java and Maven: testing disabled for Proton-J and JNI Bindings -- Configuring done -- Generating done -- Build files have been written to: D:/Users/crolke/svn/proton/build [proton-c] Windows
[jira] [Created] (PROTON-407) [proton-c] Windows install does not install .lib nor .pdb files
Chuck Rolke created PROTON-407: -- Summary: [proton-c] Windows install does not install .lib nor .pdb files Key: PROTON-407 URL: https://issues.apache.org/jira/browse/PROTON-407 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Windows Reporter: Chuck Rolke In current trunk building the INSTALL project in VS2010 does not place the qpid-proton.lib, qpid-proton.pdb files into the install area. Consequently consumers using an installed kit are unable to link to the qpid-proton library. In a dev environment the files are available in the build area as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-408) [proton-c] Windows build does not put d suffix on debug file names
Chuck Rolke created PROTON-408: -- Summary: [proton-c] Windows build does not put d suffix on debug file names Key: PROTON-408 URL: https://issues.apache.org/jira/browse/PROTON-408 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Windows Reporter: Chuck Rolke Visual Studio projects by default put a d suffix on debug version file names. This lets you have qpid-proton.dll and qpid-protond.dll in the same directory making the files easier to integrate with user projects. Cmake provides trivially easy support for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-408) [proton-c] Windows build does not put d suffix on debug file names
[ https://issues.apache.org/jira/browse/PROTON-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved PROTON-408. Resolution: Fixed Resolved in Commit 1515559 from c...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1515559 ] [proton-c] Windows build does not put d suffix on debug file names Key: PROTON-408 URL: https://issues.apache.org/jira/browse/PROTON-408 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Windows Reporter: Chuck Rolke Visual Studio projects by default put a d suffix on debug version file names. This lets you have qpid-proton.dll and qpid-protond.dll in the same directory making the files easier to integrate with user projects. Cmake provides trivially easy support for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-226) Porting Issue -- Heap Corruption using Visual Studio when running client/server proton in debug mode.
[ https://issues.apache.org/jira/browse/PROTON-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736925#comment-13736925 ] Chuck Rolke commented on PROTON-226: Issue PROTON-402 is a duplicate of this issue and is resolved. This issue, too, may be resolved. Porting Issue -- Heap Corruption using Visual Studio when running client/server proton in debug mode. - Key: PROTON-226 URL: https://issues.apache.org/jira/browse/PROTON-226 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Labels: build Fix For: 0.4 Code changes for windows port were added (MinGW and Visual Studio) to the proton codebase recently. Using the new codebase and some additional changes, I ran the proton executable using the Visual Studio toolset as both a server and client. When the client exits, a Windows popup displays: Windows has triggered a breakpoint in proton.exe. This may be due to a corruption of the heap, which indicates a bug in proton.exe or any of the DLLs it has loaded. Still tracking this problem down. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-402) [proton-c] Example proton.c with no args causes segmentation fault
Chuck Rolke created PROTON-402: -- Summary: [proton-c] Example proton.c with no args causes segmentation fault Key: PROTON-402 URL: https://issues.apache.org/jira/browse/PROTON-402 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Reporter: Chuck Rolke In one process run 'proton' In another process run 'proton -c 127.0.0.1' The second process seg faults after receiving 44 bytes into a 32-byte buffer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-402) [proton-c] Example proton.c with no args causes segmentation fault
[ https://issues.apache.org/jira/browse/PROTON-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved PROTON-402. Resolution: Fixed Fix Version/s: 0.5 Fixed with r1512495 [proton-c] Example proton.c with no args causes segmentation fault -- Key: PROTON-402 URL: https://issues.apache.org/jira/browse/PROTON-402 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Reporter: Chuck Rolke Fix For: 0.5 In one process run 'proton' In another process run 'proton -c 127.0.0.1' The second process seg faults after receiving 44 bytes into a 32-byte buffer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-352) python-test passes but details show 20 errors
Chuck Rolke created PROTON-352: -- Summary: python-test passes but details show 20 errors Key: PROTON-352 URL: https://issues.apache.org/jira/browse/PROTON-352 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Linux Fedora 18 Reporter: Chuck Rolke From a fresh checkout mkdir b64; cd b64; cmake ..; make; make test -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
