I think you are focusing on the symptom rather than the cause.
It is very common for a SF to occur far from its actual cause.
It is very common for a code change near the point of the symptom and very far from the cause to fix the symptom. That creates the illusion that you are looking at the cause.
Looking at code around the symptom is generally fruitless. Experimenting with code changes around the symptom is usually worse.
Most SF's need to be diagnosed with a debugger. Catch the actual SF in action and look at the values of the relevant variables. If you know any asm, it is much more effective to look at the register values and the disassembly of code leading up to the SF. That gives a much more trustworthy answer than having the debugger report local variable values.
Once you know the bad value that caused the SF, you can start backtracking toward the cause.
BTW, do you happen to be converting from 32 bit architecture to 64 bit architecture at the same time you are switching from HP UX to linux and at the same time as I assume you are switching to gcc from either a different compiler or at least a different version of gcc?
If you are switching 32 bit to 64 bit, try not switching. You can build and run 32 bit Linux programs on 64 bit Linux. If that works, it might give you more insight into the nature of the underlying bug.
Last edited by johnsfine; 03-04-2010 at 08:07 PM.