activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolaus Klimek <>
Subject Re: ActiveMQ C++ higher Version 2.2.6 - Segfault by initialization
Date Wed, 26 Mar 2014 15:25:26 GMT
Thank you for your prompt response!
Our Problem seems to be solved. The Solution in our case was to change the
dlopen() call. We added the flag RTLD_DEEPBIND and it seems to work.
Thanks a lot for your hints!


2014-03-13 13:41 GMT+02:00 artnaseef <>:

> Hmm, a segfault in std::basic_string points to something troubling.  Two
> ideas coming to mind - the library is not being initialized properly, or
> there is corruption earlier (probably due to pointer problems) that's
> causing this later call to fail.
> In the case of initialization not being correct - I would check the
> documentation for the technology of the main program (cobol?) on
> interoperation with Shared Libraries and initialization.
> The second case is harder to track down.  It usually involves finding the
> inconsistent point of state in the program (e.g. a variable that is wrong)
> and using a watch point in a debugger (like gdb) to tell when that's
> changing.  And then repeating until the original point of corruption is
> located.
> Really, the next step is to see just what is causing the segfault in
> std::basic_string.  I wonder if there's a version of the STL library
> (libstdc++) with full debugging symbols which can be used.  It's possible
> to
> look through the disassembled machine instructions and work back to the
> original code (get the original code, capture the compile command for the
> source file, modify the command to produce the assembly output with
> original
> source code mixed in).
> ...
> Looking at the trace more carefully, I see the fault is inside
> _dl_init_internal(), so initialization should be correct.  Perhaps try
> forcing load of the directly from the application in the same
> way the activemq SO is being loaded to see if that helps.  I think dlopen()
> should handle initialization of all the dependent libraries properly.
> Can you provide the details of the dlopen() call.  There are flags to that
> call which might be part of the problem, such as RTLD_LAZY.
> ...
> Another idea to work-around this problem: can you consider reworking the
> solution so that the ActiveMQ client is not in the cobol program?  Perhaps
> using SYSV queues to move the data from the cobol program to a separate
> ActiveMQ client program.  Or, have the cobol program read/write files (if
> the messaging volume is not too great) and use a camel route to exchange
> between the files and JMS messages.
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

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