James Kuyper <James.R.Kuyper@xxxxxxxx> writes: > At optimization level 2, as indicated by the following output from gdb, > scan_time is optimized out of the function call interface for > process_a_scan(). The address for SD_start_time is simply > passed directly to compute_SD_start_time(). The problem is that it is > sometimes the incorrect address. In this particular case, 33 scans were > processed without a hitch, and then it failed for the 34th: IIRC, "<value optimized out>" can mean that the value was passed to the function with the usual mechanism, but the function no longer needs it at that point, so the compiler has reused the register or memory location for some other purpose. I am thus not convinced that any link-time optimization occurred. Can you reproduce the SIGSEGV with the same input? If so, you could try breaking at the 34th entry to process_a_scan and checking whether the pointer is correct at that time. If you have a buffer overflow or underflow that corrupts the pointer in memory, then you might be able to track that down with a watchpoint in GDB, perhaps coupled with breakpoints that run commands to set the watchpoint on entry to a function and remove it again when the function is about to return.
