Hi,
I have obtained a set of open-source programs from
http://petertoft.dk/PhD/Recon2D.tar.gz
uncompressed, etc, and it all goes through fine.
When I compile, the programs work fine on my old 32-bit machine (results make sense), however there is a segmentation fault on my 64-bit laptop.
I compile using:
gcc -c -I../include -O3 -finline-functions -Winline -Wall -falign-loops=2 -falign-jumps=2 -falign-functions=2 -Wstrict-prototypes .....
(Note that I had to fix the makefiles in there.)
Btw, I don't know if this could have anything to do with it, but this set of programs were written in 1996 (when 64-bit probably did not even exist at all). Also, all the code uses single-precision (floats) rather than my preferred doubles. (Which makes me ask: is it possible to go into all the many files and convert all the floats into doubles using some command? )
Many thanks, Ranjan
____________________________________________________________ FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth
On Sat, Nov 02, 2013 at 05:55:37PM -0500, Ranjan Maitra wrote:
Hi,
I have obtained a set of open-source programs from
http://petertoft.dk/PhD/Recon2D.tar.gz
uncompressed, etc, and it all goes through fine.
When I compile, the programs work fine on my old 32-bit machine (results make sense), however there is a segmentation fault on my 64-bit laptop.
I compile using:
gcc -c -I../include -O3 -finline-functions -Winline -Wall -falign-loops=2 -falign-jumps=2 -falign-functions=2 -Wstrict-prototypes .....
(Note that I had to fix the makefiles in there.)
Btw, I don't know if this could have anything to do with it, but this set of programs were written in 1996 (when 64-bit probably did not even exist at all). Also, all the code uses single-precision (floats) rather than my preferred doubles. (Which makes me ask: is it possible to go into all the many files and convert all the floats into doubles using some command? )
rather than blindly hacking all the floats to doubles (which could itself cause more problems if someone did kludgey things in the program) you'd be better off ot run it under a debugger and find out where it segfaults, and backtrack from there to see why.
On Sat, 2 Nov 2013 20:19:48 -0400 Fred Smith fredex@fcshome.stoneham.ma.us wrote:
On Sat, Nov 02, 2013 at 05:55:37PM -0500, Ranjan Maitra wrote:
Hi,
I have obtained a set of open-source programs from
http://petertoft.dk/PhD/Recon2D.tar.gz
uncompressed, etc, and it all goes through fine.
When I compile, the programs work fine on my old 32-bit machine (results make sense), however there is a segmentation fault on my 64-bit laptop.
I compile using:
gcc -c -I../include -O3 -finline-functions -Winline -Wall -falign-loops=2 -falign-jumps=2 -falign-functions=2 -Wstrict-prototypes .....
(Note that I had to fix the makefiles in there.)
Btw, I don't know if this could have anything to do with it, but this set of programs were written in 1996 (when 64-bit probably did not even exist at all). Also, all the code uses single-precision (floats) rather than my preferred doubles. (Which makes me ask: is it possible to go into all the many files and convert all the floats into doubles using some command? )
rather than blindly hacking all the floats to doubles (which could itself cause more problems if someone did kludgey things in the program) you'd be better off ot run it under a debugger and find out where it segfaults, and backtrack from there to see why.
Sorry, I was not clear: I did not change the floats to doubles. Also, I forgot to add that the program segfaults at a printf statement. I am not understanding what the problem is at all. valgrind goes through just fine on the 32-bit machine:
==15081== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
but not for the 64-bit machine.
==29284== Process terminating with default action of signal 11 (SIGSEGV) ==29284== Access not within mapped region at address 0x1 ==29284== at 0x36CFC48E29: vfprintf (in /usr/lib64/libc-2.17.so) ==29284== by 0x4048CE: Print (in /home/maitra/PET/PToft/Recon2D/RadonAna/RadonAna) ==29284== by 0x4027A6: init (in /home/maitra/PET/PToft/Recon2D/RadonAna/RadonAna) ==29284== by 0x4014BE: main (in /home/maitra/PET/PToft/Recon2D/RadonAna/RadonAna) ==29284== If you believe this happened as a result of a stack ==29284== overflow in your program's main thread (unlikely but ==29284== possible), you can try to increase the size of the ==29284== main thread stack using the --main-stacksize= flag. ==29284== The main thread stack size used in this run was 8388608. 0 : type===29284== .....
What i don't understand is why valgrind's behaviour is so different for the two cases.
Ranjan
____________________________________________________________ FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family! Visit http://www.inbox.com/photosharing to find out more!
On Sat, Nov 02, 2013 at 08:41:03PM -0500, Ranjan Maitra wrote:
On Sat, 2 Nov 2013 20:19:48 -0400 Fred Smith
<snip>
Sorry, I was not clear: I did not change the floats to doubles. Also, I forgot to add that the program segfaults at a printf statement. I am not understanding what the problem is at all. valgrind goes through just fine on the 32-bit machine:
==15081== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
but not for the 64-bit machine.
==29284== Process terminating with default action of signal 11 (SIGSEGV) ==29284== Access not within mapped region at address 0xAccess not within mapped region at address 0x1u1 ==29284== at 0x36CFC48E29: vfprintf (in /usr/lib64/libc-2.17.so) ==29284== by 0x4048CE: Print (in /home/maitra/PET/PToft/Recon2D/RadonAna/RadonAna) ==29284== by 0x4027A6: init (in /home/maitra/PET/PToft/Recon2D/RadonAna/RadonAna) ==29284== by 0x4014BE: main (in /home/maitra/PET/PToft/Recon2D/RadonAna/RadonAna) ==29284== If you believe this happened as a result of a stack ==29284== overflow in your program's main thread (unlikely but ==29284== possible), you can try to increase the size of the ==29284== main thread stack using the --main-stacksize= flag. ==29284== The main thread stack size used in this run was 8388608. 0 : type===29284== .....
What i don't understand is why valgrind's behaviour is so different for the two cases.
sounds as if there's SOMETHING in there that's assuming a 32-bit machine. that statement "Access not within mapped region at address 0x1" is definitely suspicious. if you change the compile command to so that it uses "-O0 -g" rather than whatever it is using, you may find that Valgrind gives actual line numbers, if it still fails when compiled that way.
if you use GDB (or other debugger of your preference) you can get a backtrace, once it segfaults, that may help you track where it got a bad parameter (that 0x1 as an address is definitely suspicous.)
On Sat, 2 Nov 2013 20:41:03 -0500, Ranjan Maitra wrote:
==29284== Process terminating with default action of signal 11 (SIGSEGV) ==29284== Access not within mapped region at address 0x1 ==29284== at 0x36CFC48E29: vfprintf (in /usr/lib64/libc-2.17.so)
You may need to check carefully that the vfprintf call is done with a format string that matches the variable arguments list. In particular the size of the arguments.
On Sat, Nov 02, 2013 at 05:55:37PM -0500, Ranjan Maitra wrote:
Hi,
I have obtained a set of open-source programs from
http://petertoft.dk/PhD/Recon2D.tar.gz
uncompressed, etc, and it all goes through fine.
When I compile, the programs work fine on my old 32-bit machine (results make sense), however there is a segmentation fault on my 64-bit laptop.
I compile using:
gcc -c -I../include -O3 -finline-functions -Winline -Wall -falign-loops=2 -falign-jumps=2 -falign-functions=2 -Wstrict-prototypes .....
(Note that I had to fix the makefiles in there.)
Btw, I don't know if this could have anything to do with it, but this set of programs were written in 1996 (when 64-bit probably did not even exist at all). Also, all the code uses single-precision (floats) rather than my preferred doubles. (Which makes me ask: is it possible to go into all the many files and convert all the floats into doubles using some command? )
You can add -m32 to gcc arguments.
Mihai
Mihai T. Lazarescu <mtlagm <at> gmail.com> writes:
On Sat, Nov 02, 2013 at 05:55:37PM -0500, Ranjan Maitra wrote:
Hi,
I have obtained a set of open-source programs from
http://petertoft.dk/PhD/Recon2D.tar.gz
uncompressed, etc, and it all goes through fine.
When I compile, the programs work fine on my old 32-bit machine (results make sense), however there is a segmentation fault on my 64-bit laptop.
I compile using:
gcc -c -I../include -O3 -finline-functions -Winline -Wall -falign-loops=2 -falign-jumps=2 -falign-functions=2 -Wstrict-prototypes .....
(Note that I had to fix the makefiles in there.)
Btw, I don't know if this could have anything to do with it, but this set of programs were written in 1996 (when 64-bit probably did not even exist at all). Also, all the code uses single-precision (floats) rather than my preferred doubles. (Which makes me ask: is it possible to go into all the many files and convert all the floats into doubles using some command? )
You can add -m32 to gcc arguments.
Mihai
I have to second Mihai's advice. I'm currently doing some contract work porting a rather large and very crufty C application from Solaris to Linux for a national telecom. The program actually was running under OS/2 at one time and had it's roots on PrimOS.
We initially started out also going to 64 bit and had to backtrack. See how your program runs on the 64 bit box when compiled as a 32 bit application. Then decide whether to change the floats to longs first or to port it to 64 bit.
The other advice on debugging is spot on. Compile with -g and run it under the debugger of your choice. gdb works fine for this.
Cheers, Dave
-
David G. Miller (aka DaveAtFraud) -
Fred Smith -
Michael Schwendt -
Mihai T. Lazarescu -
Ranjan Maitra