OT: C programs and architectures (use on Fedora)

[Ranjan Maitra]

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

[Fred Smith]

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.

-- 
---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us -----------------------------
                    The Lord detests the way of the wicked 
                  but he loves those who pursue righteousness.
----------------------------- Proverbs 15:9 (niv) -----------------------------

[Ranjan Maitra]

On Sat, 2 Nov 2013 20:19:48 -0400 Fred Smith
<fredex(a)fcshome.stoneham.ma.us&gt; 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!

[Fred Smith]

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.)


-- 
---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us -----------------------------
                         God made him who had no sin
                      to be sin for us, so that in him
                 we might become the righteousness of God."
--------------------------- Corinthians 5:21 ---------------------------------

[Mihai T. Lazarescu]

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

[David G. Miller (aka DaveAtFraud)]

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

[Michael Schwendt]

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.