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 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!

Regards
Niko


2014-03-13 13:41 GMT+02:00 artnaseef <art@artnaseef.com>:

> 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 libstdc++.so 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:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-C-higher-Version-2-2-6-Segfault-by-initialization-tp4675173p4678963.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

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