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 <a...@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. >
