On 06/01/2012 08:29 AM, Roger Oberholtzer wrote:
On Thu, 2012-05-31 at 12:28 -0400, Jerry Feldman wrote:
So it does appear that libz is threadsafe. I have not worked on threads in a while. I always assume library functions are not threadsafe unless I learn otherwise. Could possibly be that the GPS code has a bug. At this point I am just guessing not knowing your app. One of the real beauties of Purify http://www-01.ibm.com/software/awdtools/purify/unix/ is that it is able to find a lot of issues that other debugging options miss. The type of issues you are having are perfect for purify. While the product is pricery, you could use the trial version. A few years ago, when I was at Compaq, a guy at one of our meetings described a problem with his software. He had used other tools, but none found his problem. At my suggestion he tried Purify, it found the problem very quickly and his company decided to pay for a license. Very strange. In purify, my application stops with a segmentation violation before it starts. That is, the program loaed seems to be loading a library (libkakadu which is a very fast JPEG2000 decoder). It is still in the startup code. The entry point in the library is _init (if I understand what purify is telling). My main() has not been called.
Hard to debug a program when you never get a chance to start...
Maybe it is because I am not running a supported kernel. No openSUSE kernels are supported by purify.
I think I will see what ElectricFence tells.
I've seen this before. There is a lot of code that gets executed before
the actual main() function. I don't think this has to do with the
kernel, but possibly the loader. ElectricFence is also a good tool. One
of the things that is normally done before main is memory allocation.
Some times, libraries need to allocate some memory. Also, remember that
Purify likes to tram mmap(2).
--
Jerry Feldman