OT: C programs and architectures (use on Fedora)

[Ranjan Maitra]

On Sat, 2 Nov 2013 20:19:48 -0400 Fred Smith
<fredex at 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!