On Thu, 2006-11-16 at 22:46 -0800, David Scriven wrote: > I have two programs that when compiled under the latest version of g++: > gcc version 4.1.1 20061011 (Red Hat 4.1.1-30) work perfectly > under FC6 but give the error 'Floating point exception' when run under FC5. > (The version of g++ in FC5 is 4.1.1 20060525 (Red Hat 4.1.1.-1) > > When one runs a gdb (in FC5) on either program you get: > (gdb) run > Starting program: prepdata > Reading symbols from shared object read from target memory...done. > Loaded system supplied DSO at 0x9c8000 > > Program received signal SIGFPE, Arithmetic exception. > 0x00ad2396 in do_lookup_x () from /lib/ld-linux.so.2 > (gdb) where > #0 0x00ad2396 in do_lookup_x () from /lib/ld-linux.so.2 > #1 0x00ad2719 in _dl_lookup_symbol_x () from /lib/ld-linux.so.2 > #2 0x00ad3eca in _dl_relocate_object () from /lib/ld-linux.so.2 > #3 0x00acc840 in dl_main () from /lib/ld-linux.so.2 > #4 0x00adc6f7 in _dl_sysdep_start () from /lib/ld-linux.so.2 > #5 0x00aca2b6 in _dl_start () from /lib/ld-linux.so.2 > #6 0x00ac9847 in _start () from /lib/ld-linux.so.2 > > which seems to be some type of load error, since the program > doesn't seem to have started yet. > > When compiled under FC5 g++, the program also works properly. > The FC6 machine is an Intel Core 2 Duo, the FC5 machines have > Intel 950 (Dual core) chips and are running smp kernels. > > Is this an incompatibility? - a bug? > I don't know exactly what your code is doing at this point, but I suspect somehow you have passed bad arguments to the library function do_lookup_x. This kind of error is typically a result of moving from one kind of integer to another. For instance if int were defined as 16 bit and you move to a new compiler where int is now 32 bit, then the exception will occur when the sign extension results in an overflow condition that didn't exist before. Also, I would normally expect a "lookup" function to be using integer math and not floating point, so there could be an error in variable definition in either the calling or receiving functions. Since generally libraries are used by lots of programs, I tend to examine my own code very closely when tracing this type of error. You might set a trap at the initial call from your code to see exactly what you are passing as arguments. It is interesting to note that in some cases compilers will be set to optimize for execution time and will change some floating point math to integer and so avoid some of these errors for numbers that can be represented as integers. This sometimes causes code that apparently works to fail during an upgrade. Regards, Les H
