Well today has been a hoot, trying to narrow down a sigsegv in a legacy application, the issue is that something is currupting memory, but I do not know until the memory that has been currupted is accessed, so the stack trace I get in the final core is not representative of where the root issue is. I have run profilers on the code, boundchecking software (http://www-106.ibm.com/developerworks/rational/library/811.html ) without errors, i.e. nothing of interest found. To add to the complexity, the client that I am working for has a series of inhouse libraries that provide abstractions ontop of abstractions, that make understanding the code, and working thru it a nightmare. There is something to be said for the KISS approach, Keep It Simple Stupid, but very few developers actually take notice, and reveal in the fact that they can write complex code. Case in point is a Logging abstraction, where the idea is to reduce the performance overhead that logging has on an application, so that it can be included with minimal concerns for performance, the issue is that its complicated and poorly documented, which brings me back to my sigsegv, which I am slowling comming to the conclusion that it may have something to do with the logging in the code, but at the moment, I am just shooting in the dark, hoping that I hit something soon, otherwise the Trader's are going to have my head
General stuff.
ldd is a very usefull command, along with cat /proc/[procid]/maps to ensure that the so's you think you are using are actually being used.
ldd is used statically, i.e. run this on the executable you have built, it will show all of the dependancies that the specified excecutable has, and cat /proc/[procid]/maps is used at run time, to further verify that you are running with the correct versions of an so ( shared object )