[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13445235#comment-13445235
]
Andrew Stitcher commented on QPID-3364:
---
There's nothing in that change that could/should have fixed any bug like this -
the // ### Hack Alert is really to point out an API which violates good
practice and shouldn't ever be used!
Additionally, I can't think of any good reason that could explain this bug
except runtime loader error.
So I'm happy to mark this as closed.
If it happens again we can reopen it!
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, 0.14
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: loadee.cpp, loader.cpp, Makefile
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
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13248143#comment-13248143
]
Paul Colby commented on QPID-3364:
--
A not-so-quick heuristically driven binary search has narrowed the fix down to
revision 1297185.
That revision only changed two files - FieldTable.h and FieldTable.cpp. I
suspect that the actual fix has to do with the use of the private
FieldTable::values member variable (the now-removed // ### Hack Alert comment
adds to that suspicion).
Anyway, it's _probably_ safe to say that this issue has been fixed by
r1297185... at least as far as the one test case above is concerned.
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, 0.14
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: ???
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=13242230#comment-13242230
]
Paul Colby commented on QPID-3364:
--
This seems to have been fixed somewhere between the 0.14 release and
r1303144... ?
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, 0.14
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)
==31992==by
