activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolaus Klimek <nikolaus.kli...@googlemail.com>
Subject Re: ActiveMQ C++ higher Version 2.2.6 - Segfault by initialization
Date Thu, 13 Mar 2014 11:09:32 GMT
Sorry for the late response. I know we have a special sort of scenario, but
maybe you can help us. I did some debugging, here are some informations:

Program terminated with signal 11, Segmentation fault.
#0  0x000003fffb2fa2d4 in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string() () from /usr/lib64/libstdc++.so.6
(gdb) backtrace
#0  0x000003fffb2fa2d4 in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string() () from /usr/lib64/libstdc++.so.6
#1  0x000003fff74ffb5e in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535) at
activemq/commands/ActiveMQBlobMessage.cpp:31
#2  0x000003fff74ffbfe in global constructors keyed to
ActiveMQBlobMessage.cpp(void) () at
activemq/commands/ActiveMQBlobMessage.cpp:65
#3  0x000003fff757bc1a in __do_global_ctors_aux () from
/var/local/daten/MTP/be02/src/bin/AMQS.so
#4  0x000003fff6a67094 in _init () from
/var/local/daten/MTP/be02/src/bin/AMQS.so
#5  0x000003fffd6a1ec6 in call_init () from /lib/ld64.so.1
#6  0x000003fffd6a1fee in _dl_init_internal () from /lib/ld64.so.1
#7  0x000003fffd6a6ddc in dl_open_worker () from /lib/ld64.so.1
#8  0x000003fffd6a1a96 in _dl_catch_error () from /lib/ld64.so.1
#9  0x000003fffd6a639a in _dl_open () from /lib/ld64.so.1
#10 0x000003fffd4fb0ae in dlopen_doit () from /lib64/libdl.so.2
#11 0x000003fffd6a1a96 in _dl_catch_error () from /lib/ld64.so.1
#12 0x000003fffd4fb53c in _dlerror_run () from /lib64/libdl.so.2
#13 0x000003fffd4faffa in dlopen@@GLIBC_2.2 () from /lib64/libdl.so.2
#14 0x00000000800f6a38 in ?? ()
Backtrace stopped: frame did not save the PC
(gdb) frame 1
#1  0x000003fff74ffb5e in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535) at
activemq/commands/ActiveMQBlobMessage.cpp:31
31      string name;
(gdb) print name
$1 = {static npos = 18446744073709551615, _M_dataplus =
{<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No
data
fields>}, <No data fields>}, _M_p = 0x0}}


AMQS.so is our ActiveMQ C++ client application.

Regards
Nikolaus



2013-12-05 12:36 GMT+01:00 Timothy Bish <tabish121@gmail.com>:

> On 12/05/2013 02:57 AM, Nikolaus Klimek wrote:
>
>> Hello,
>>
>> because our previous SLES Version does not support required apr-version,
>> we
>> used the ActiveMQ C++ Client 2.2.6, which was compiled to a shared
>> object/library and called by a cobol application (via CALL). This
>> combination
>> works fine.
>>
>> Actually we updated our SLES (to 11.2) and a higher apr-version now is
>> supported. So we tried to use a higher-version of the ActiveMQ C++ Client
>> (e.g. 3.0, ... , 3.8.1), which we compiled to a shared object for calling
>> via a cobol application, too. Calling the new version now causes a
>> segmentation fault, the ActiveMQ shared object crashes on initialization,
>> before any command is executed. We think it deals with
>> loading/initialising
>> the activemq library (activemq::library; ActiveMQCPP::
>> initializeLibrary()),
>> because it is new since version 3.0.0.
>> Another point is we reduced our ActiveMQ shared object to only print a
>> line. This certainly works. Adding the command activemq::library;
>> ActiveMQCPP::initializeLibrary() causes the identicall segfault.
>> Bizarrely
>> calling the identical shared object from a C++ application works.
>>
>> We don't understand why calling the ActiveMQ shared object doens't work
>> from cobol, however it works calling from a C++ application. With a
>> release
>> <=2.2.6 both call variations working.
>>
>> We hope you have any ideas for let us understand this issue or to give us
>> some advice for solving this problem.
>>
>> Thanks in regards!
>> Niko
>>
>>  Well the CMS libraries are not tested under this sort of scenario so I
> can't really offer much help without more information.  You should do some
> debugging and try and figure out what the stack trace is at the time of the
> segmentation fault.
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.bish@redhat.com | www.fusesource.com | www.redhat.com
> skype: tabish121 | twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message