[jira] [Created] (QPID-3364) Segmentation fault when unloading shared libraries linked with libqpidmessaging
Segmentation fault when unloading shared libraries linked with libqpidmessaging
---
Key: QPID-3364
URL: https://issues.apache.org/jira/browse/QPID-3364
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.10, 0.8, 0.11
Environment: Linux version 2.6.32-5-686 (Debian 2.6.32-34squeeze1)
(da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed May 18
07:08:50 UTC 2011
Linux version 2.6.32-5-amd64 (Debian 2.6.32-34squeeze1) (da...@debian.org) (gcc
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed May 18 23:13:22 UTC 2011
Reporter: Paul Colby
Priority: Minor
Disclaimer: I'm not a dlopen/dlclose expert... I'm perfectly happy to be told
that I don't know what I'm doing! ;)
If I create a shared object (that may or may not implement anything) that links
with libqpidmessaging (ie g++ ... -lqpidmessaging), and then create an
application that dlopen's that library, then dlclose's that library, then that
application will cause a seg-fault, which appears to be in the libqpidmessaging
library itself.
To demonstrate, I have a loadee.cpp file that contains just the following
unimportant code:
{quote}
void foo() { }
{quote}
Then I build a loadee.so shared object like:
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3364) Segmentation fault when unloading shared libraries linked with libqpidmessaging
[
https://issues.apache.org/jira/browse/QPID-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Colby updated QPID-3364:
-
Attachment: Makefile
loader.cpp
loadee.cpp
Attached the sample files mentioned in the issue description, along with a
near-trivial Makefile.
Segmentation fault when unloading shared libraries linked with
libqpidmessaging
---
Key: QPID-3364
URL: https://issues.apache.org/jira/browse/QPID-3364
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.8, 0.10, 0.11
Environment: Linux version 2.6.32-5-686 (Debian 2.6.32-34squeeze1)
(da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed May 18
07:08:50 UTC 2011
Linux version 2.6.32-5-amd64 (Debian 2.6.32-34squeeze1) (da...@debian.org)
(gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Wed May 18 23:13:22 UTC 2011
Reporter: Paul Colby
Priority: Minor
Attachments: Makefile, loadee.cpp, loader.cpp
Disclaimer: I'm not a dlopen/dlclose expert... I'm perfectly happy to be told
that I don't know what I'm doing! ;)
h3. Basic Description
If I create a shared object (that may or may not implement anything) that
links with libqpidmessaging (ie g++ ... -lqpidmessaging), and then create an
application that dlopen's that library, then dlclose's that library, then
that application will cause a seg-fault, which appears to be in the
libqpidmessaging library itself.
To demonstrate, I have a loadee.cpp file that contains just the following
unimportant code:
{code:title=loadee.cpp|borderStyle=solid}
void foo() { }
{code}
Then I build a loadee.so shared object like:
{noformat}
g++ -g -shared -lqpidmessaging -o loadee.so loadee.cpp
{noformat}
Next I have:
{code:title=loader.cpp|borderStyle=solid}
#include stdio.h
#include stdlib.h
#include dlfcn.h
int main(int c, char *argv[]) {
void *handle = dlopen(./loadee.so, RTLD_LAZY); // segfaults in dlclose
below.
//void *handle = dlopen(./loadee.so, RTLD_NOW); // no segfault.
if (!handle) {
fprintf(stderr, %s\n, dlerror());
exit(EXIT_FAILURE);
}
dlclose(handle);
return EXIT_SUCCESS;
}
{code}
Finally I build the loader program like:
{noformat}
g++ -g -rdynamic -o loader loader.cpp -ldl
{noformat}
Now, if I run the resulting loader program, then the program seg-faults in
libqpidmessaging. However, there is no such seg-fault (for me at least), if
I *either* remove the -lqpidmessaging flag from the first g++ command, *or*
change the flopen flags from RTLD_NOW to RTLD_LAZY (as indicated in the code
comments above).
h3. Tested Versions
I've tried this against the 0.8 and 0.10 tags, as well as trunk at r1148263,
with both Autotools and CMake.
h3. GDB
Unfortunately, gdb is not giving me much... very strange.
{noformat}
paul@debian:~/src/simple$ gdb ./loader
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/paul/src/simple/loader...done.
(gdb) run
Starting program: /home/paul/src/simple/loader
[Thread debugging using libthread_db enabled]
Cannot find new threads: generic error
(gdb) bt
Target is executing.
(gdb) bt full
Target is executing.
(gdb) thread apply all bt
Cannot find new threads: generic error
(gdb)
{noformat}
h3. Valgrind
Valgrind is a little more interesting though...
{noformat}
paul@debian:~/src/simple$ valgrind --leak-check=full --show-reachable=yes
./loader
==31992== Memcheck, a memory error detector
==31992== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==31992== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
copyright info
==31992== Command: ./loader
==31992==
==31992== Jump to the invalid address stated on the next line
==31992==at 0x0: ???
==31992==by 0x41A1687: __cxa_finalize (cxa_finalize.c:56)
==31992==by 0x46ED0F3: ??? (in /usr/local/lib/libqpidmessaging.so.2.0.0)
==31992==by 0x473091F: ??? (in /usr/local/lib/libqpidmessaging.so.2.0.0)
==31992==by 0x401271D: _dl_close_worker (dl-close.c:271)
==31992==by 0x4013196: _dl_close (dl-close.c:742)
==31992==by 0x4034CA3: dlclose_doit (dlclose.c:37)
==31992==by 0x400D7F5: _dl_catch_error (dl-error.c:178)
==31992==by 0x403509B: _dlerror_run (dlerror.c:164)
==31992==by 0x4034CD9: dlclose (dlclose.c:48)
[jira] [Commented] (QPID-3027) PHP binding of Qpid Messaging API
[ https://issues.apache.org/jira/browse/QPID-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067633#comment-13067633 ] Paul Colby commented on QPID-3027: -- Regarding the segfault, I've created a very small test case that reproduces the same fault without involving PHP or swig at all, and reported it as a separate issue - https://issues.apache.org/jira/browse/QPID-3364 PHP binding of Qpid Messaging API - Key: QPID-3027 URL: https://issues.apache.org/jira/browse/QPID-3027 Project: Qpid Issue Type: New Feature Components: C++ Client Affects Versions: 0.8 Reporter: Paul Colby Assignee: Ted Ross Attachments: FindPHPDev.cmake, Makefile, cqpid_php.20110220.diff, cqpid_php.20110301.diff, cqpid_php.20110328.diff, cqpid_php.20110415.diff, cqpid_php.diff Working on a PHP binding for the Qpid Messaging API via SWIG. There are several PHP-specific issues with C++ and SWIG which I've managed to workaround, so the binding is starting to take shape, but still very much a work in progress. The rough plan: 1. report relevant bugs / feature requests to SWIG (done). 2. clean-up Qpid php.i SWIG interface file (mostly done - just need to implement PHP namespaces). 3. implement qpid::types::Variant - PHP typemapping (not started). 4. implement printinfo pragma (should be easy, just need to choose what info to include). 5. create relevant [auto]makefile. Of course, there's lots of things to discuss / decide along the way... so I'll post 'em here as they come up. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3365) Improvements to build system to support client-plugins modules
Improvements to build system to support client-plugins modules -- Key: QPID-3365 URL: https://issues.apache.org/jira/browse/QPID-3365 Project: Qpid Issue Type: Improvement Components: Ant Build System, Java Client Reporter: Keith Wall Assignee: Keith Wall Fix For: 0.13 The Ant Build system already builds broker side plugins beneath the broker-plugins. This improvement is to introduce an analogous client-plugins directory to allow for the building optional client side components. An example of such components would be optional transport or security mechanisms. This change does not introduce OSGi onto the client. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3366) qpid get stuck under heavy load
qpid get stuck under heavy load --- Key: QPID-3366 URL: https://issues.apache.org/jira/browse/QPID-3366 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.10 Environment: Linux Reporter: Francesco Emmi Hi all, I' ve been experiencing a very strange behaviour on qpid C++ client that seems to arise just only under heavy load. Basically in the queue named frames inside client::TCPConnector::writebuf somehow a frame arrives which is grater than 65535 bytes. This cause client::TCPConnector::encode not to be able to transform the frame in a AsinchIO buffer and therefore the frame is not pop-ed from frames queue while on the other side e 0 sized buffer is inserted into AynchIO buffers queue. Starting from this moment on, the application using qpid client get stuck no longer sending messages and using 100% CPU. This is becouse the big frame in front of frames queue cannot be elimiated and acts like a cork in the queue. I' ve no idea so far how to handle this, just because I cannot understand who creates this big frame and how to prevent this to happen. I'll continue to investigate and try to give you as more details as possible. Thanks Francesco -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3256) Application which uses Qpid (in my case Excel) hangs on shutdown
[
https://issues.apache.org/jira/browse/QPID-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067897#comment-13067897
]
Steve Huston commented on QPID-3256:
I believe it's an important fix to get in.
Application which uses Qpid (in my case Excel) hangs on shutdown
Key: QPID-3256
URL: https://issues.apache.org/jira/browse/QPID-3256
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.8, 0.10
Environment: OS: Windows.
Qpid is assembled as DLL.
Reporter: Eugene
Assignee: Cliff Jansen
Fix For: 0.13
Attachments: qpid-3256-3.patch, qpid-3256.patch
Hi All
I encountered with strange behavior on shutdown when using qpid 0-8 and 0-10.
When I use qpid in standalone console-application everything is ok. But when
I use qpid in DLL which is loaded into Excel (as RTD module), Excel hangs on
shutdown.
I found out that in standalone application on shutdown I have next stack:
qpidclientd.dll!qpid::client::`anonymous
namespace'::IOThread::~IOThread() Line 138C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x6008, unsigned long
dwReason=0, void * lpreserved=0x0001) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77b9a516()
ntdll.dll!77b9a3b8()
kernel32.dll!77657363()
msvcr90d.dll!__crtExitProcess(int status=0) Line 732 C
msvcr90d.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 644
+ 0x9 bytes C
msvcr90d.dll!exit(int code=0) Line 412 + 0xd bytes C
Test.exe!__tmainCRTStartup() Line 599 C
Test.exe!mainCRTStartup() Line 403 C
kernel32.dll!77653677()
ntdll.dll!77b79f02()
ntdll.dll!77b79ed5()
And in this state all threads of application have been already terminated.
The only thread is:
121720 Main Thread Main Thread
qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
so code from file ConnectionImpl.cpp works well:
~IOThread() {
std::vectorThread threads;
{
ScopedLockMutex l(threadLock);
if (poller_)
poller_-shutdown();
t.swap(threads);
}
for (std::vectorThread::iterator i = threads.begin(); i !=
threads.end(); ++i) {
i-join();
}
}
BUT in Excel I get stack:
qpidclientd.dll!qpid::client::`anonymous namespace'::IOThread::~IOThread()
Line 130 C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x0770, unsigned long
dwReason=0, void * lpreserved=0x) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77ba1525()
ntdll.dll!77b81231()
KernelBase.dll!77281da7()
ole32.dll!75bb9562()
ole32.dll!75bb9593()
ole32.dll!75bb95a7()
ole32.dll!75bb98bf()
ole32.dll!75bb9805()
ole32.dll!75bb9a8c()
EXCEL.EXE!2f3811e9()
EXCEL.EXE!2f6933e8()
EXCEL.EXE!2f32a5af()
EXCEL.EXE!2f34894a()
EXCEL.EXE!2f670001()
MSO.DLL!65bc6ed5()
MSO.DLL!65c26a34()
MSO.DLL!65c30305()
MSO.DLL!65bc910c()
MSO.DLL!65c4f420()
MSO.DLL!65bbf161()
comctl32.dll!7233463d()
user32.dll!762971be()
user32.dll!76297d31()
user32.dll!76297dfa()
EXCEL.EXE!2f324572()
EXCEL.EXE!2f324534()
EXCEL.EXE!2f324441()
MSO.DLL!65b78116()
MSO.DLL!65ba1fd0()
EXCEL.EXE!2f30424b()
[jira] [Commented] (QPID-3256) Application which uses Qpid (in my case Excel) hangs on shutdown
[
https://issues.apache.org/jira/browse/QPID-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067898#comment-13067898
]
Cliff Jansen commented on QPID-3256:
I wanted to see the patch run through Steve's nightly review board automated
build and test.
It started failing precisely at the same time I did the checkin to trunk, not a
good sign. That plus the recent mingw build problem makes me wonder if it is a
good idea to add it to the release at this time. The person who reported the
JIRA has an earlier version of the patch that works for him.
But I can't say for sure if there is a problem. It may be differences between
my setup and Steve's, i.e. Xp versus WS2008, or different versions of boost or
Visual Studio, or 32 vs 64 bit. Or the Riverace build may be failing for some
unrelated reason.
Application which uses Qpid (in my case Excel) hangs on shutdown
Key: QPID-3256
URL: https://issues.apache.org/jira/browse/QPID-3256
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.8, 0.10
Environment: OS: Windows.
Qpid is assembled as DLL.
Reporter: Eugene
Assignee: Cliff Jansen
Fix For: 0.13
Attachments: qpid-3256-3.patch, qpid-3256.patch
Hi All
I encountered with strange behavior on shutdown when using qpid 0-8 and 0-10.
When I use qpid in standalone console-application everything is ok. But when
I use qpid in DLL which is loaded into Excel (as RTD module), Excel hangs on
shutdown.
I found out that in standalone application on shutdown I have next stack:
qpidclientd.dll!qpid::client::`anonymous
namespace'::IOThread::~IOThread() Line 138C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x6008, unsigned long
dwReason=0, void * lpreserved=0x0001) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x6008,
unsigned long dwReason=0, void * lpreserved=0x0001) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77b9a516()
ntdll.dll!77b9a3b8()
kernel32.dll!77657363()
msvcr90d.dll!__crtExitProcess(int status=0) Line 732 C
msvcr90d.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 644
+ 0x9 bytes C
msvcr90d.dll!exit(int code=0) Line 412 + 0xd bytes C
Test.exe!__tmainCRTStartup() Line 599 C
Test.exe!mainCRTStartup() Line 403 C
kernel32.dll!77653677()
ntdll.dll!77b79f02()
ntdll.dll!77b79ed5()
And in this state all threads of application have been already terminated.
The only thread is:
121720 Main Thread Main Thread
qpid::client::`anonymous namespace'::IOThread::~IOThreadNormal 0
so code from file ConnectionImpl.cpp works well:
~IOThread() {
std::vectorThread threads;
{
ScopedLockMutex l(threadLock);
if (poller_)
poller_-shutdown();
t.swap(threads);
}
for (std::vectorThread::iterator i = threads.begin(); i !=
threads.end(); ++i) {
i-join();
}
}
BUT in Excel I get stack:
qpidclientd.dll!qpid::client::`anonymous namespace'::IOThread::~IOThread()
Line 130 C++
qpidclientd.dll!`qpid::client::`anonymous
namespace'::theIO'::`2'::`dynamic atexit destructor for 'io''() + 0xd bytes
C++
qpidclientd.dll!_CRT_INIT(void * hDllHandle=0x0770, unsigned long
dwReason=0, void * lpreserved=0x) Line 449 C
qpidclientd.dll!__DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 560 + 0x11
bytesC
qpidclientd.dll!_DllMainCRTStartup(void * hDllHandle=0x0770,
unsigned long dwReason=0, void * lpreserved=0x) Line 510 + 0x11
bytes C
ntdll.dll!77b79960()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!77ba1525()
ntdll.dll!77b81231()
KernelBase.dll!77281da7()
ole32.dll!75bb9562()
ole32.dll!75bb9593()
ole32.dll!75bb95a7()
ole32.dll!75bb98bf()
ole32.dll!75bb9805()
ole32.dll!75bb9a8c()
EXCEL.EXE!2f3811e9()
EXCEL.EXE!2f6933e8()
[jira] [Commented] (QPID-3304) Tagged federation messages in a transaction can cause subsequent dequeue to fail
[ https://issues.apache.org/jira/browse/QPID-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067926#comment-13067926 ] Kim van der Riet commented on QPID-3304: Checked in Gordon's patch in r.1148503. Also included a set of tests which detect this condition. Tagged federation messages in a transaction can cause subsequent dequeue to fail Key: QPID-3304 URL: https://issues.apache.org/jira/browse/QPID-3304 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.10 Reporter: Gordon Sim Fix For: 0.11 E.g. with Error dequeuing message, persistence id not set (MessageStoreImpl.cpp:1355) (exact error depends on store used). To reproduce, bind a durable queue to an exchange with a given binding key the set up a route between that same exchange on two brokers with the 'source broker' being the one with the durable queue bound to it. Then bind a queue on the 'destination' broker with the same binding key as used for the durable queue. Then publish a transactional message to the source brokers exchange with a matching routing key. The message will be enqueued on both the durable queue and the federation routes temporary bridge queue. However the persistence id for the message, set when enqueueing on the durable queue is lost and subsequent attempts to dequeue to fail. The problem is that the copy-on-write strategy used to workaround QPID-2670 means that the message on which the persistent store id is set is not then pushed onto the appropriate queues, the copy is (and the copy may not have the persistence id set on it). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: svn commit: r1148503 [1/3] - in /qpid/trunk/qpid/cpp: ./ src/qpid/broker/ src/qpid/cluster/ src/qpid/framing/ src/qpid/management/ src/qpid/replication/ src/tests/
On Tue, 2011-07-19 at 19:57 +, kp...@apache.org wrote: Author: kpvdr Date: Tue Jul 19 19:57:06 2011 New Revision: 1148503 URL: http://svn.apache.org/viewvc?rev=1148503view=rev Log: QPID-702656 Patch from Gordon Sim plus tests which detect the condition being solved. Added a make check-long target to the Makefile in the cpp dir to make it easier to run the long tests. ^^^ My mistake, this should be QPID-3304. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
