On Sat, 2 Nov 2013 20:19:48 -0400 Fred Smith <fredex@xxxxxxxxxxxxxxxxxxxxxx> 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! -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
