Hi Don! > I've just gotten full access to a server with RedHat Linux and g77. > Succeeded in getting PMX compiled after changing the two lines with getarg, > no other changes needed. Works OK with a small file but with a bigger one I Well my output shows a lot of warnings, don't know if that is important. > get a segmentation fault. Could one of the Linux gurus out there help a > little? I uploaded the FORTRAN source and the larger pmx source to > ftp://ftp.logicon.com/ongoing/dswacwe/pmx/g77test.zip . Can anyone compile Ok I got them, compiled it with g77 (-O2, -Wall) and stripped it. I get the same error as you (at the same bar). > the source as is, run it on xxx.pmx and get the segmentation fault at Bar > 134 on the second pass? (Note its a developmental version that makes some > extra output files). Second, any ideas what's wrong? (Naturally I tested Using strace, the last lines before the error look like this: write(1, "\n", 1 ) = 1 write(1, " Bar 134", 9 Bar 134) = 9 write(4, "\n Bar 134", 10) = 10 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ ltrace has quite a different output, if you try it the last lines before the crash look like this: fputs(" Bar 134", 0x08218bf8) = 1 fflush(0x08218bf8) = 0 fputs("\xbar\n", 0x08218f38) = 1 drem(0x60000000, 0x40480010, 0, 0x40000000, 0) = 16416 log(0, 0x40200000, 0xbfffcfd8, 0xbfffcfd9, 0xbfffcfd9) = 288 log(0, 0x40200000, 0xbfffcfd8, 0xbfffcfd9, 0xbfffcfd9) = 288 log(0, 0x40200000, 0xbfffcfd8, 0xbfffcfd9, 0xbfffcfd9) = 288 drem(0x60000000, 0x40480010, 0, 0x40000000, 0) = 16416 log(0, 0x40100000, 0xbfffcfd8, 0xbfffcfd9, 0xbfffcfd9) = 288 log(0, 0x40100000, 0xbfffcfd8, 0xbfffcfd9, 0xbfffcfd9) = 288 log(0, 0x40200000, 0xbfffcfd8, 0xbfffcfd9, 0xbfffcfd9) = 288 drem(0xc0000000, 0x40300020, 0, 0x40000000, 0) = 16416 log(0, 0x40100000, 0xbfffcfd8, 0xbfffcfd9, 0xbfffcfd9) = 288 log(0, 0x40100000, 0xbfffcfd8, 0xbfffcfd9, 0xbfffcfd9) = 288 log(0, 0x40200000, 0xbfffcfd8, 0xbfffcfd9, 0xbfffcfd9) = 288 sprintf("1.41", "%#.*f", 2, ...) = 4 log(0, 0x40100000, 0x08073438, 0xbfffc443, 0x080963f8) = 288 drem(0x20000000, 0x40000106, 0, 0x3ff00000, 0x40027fdc) = 16416 log(0, 0x40affe00, 0, 1, 10) = 288 log(0, 0x40100000, 2, 0, 2) = 288 log(0, 0x40100000, 0x080957e8, 0xbfffc3d4, 0x080963f8) = 288 drem(0x20000000, 0x40000106, 0, 0x3ff00000, 0x40027fdc) = 16416 fputs("\pnotes{1.41}\Figu{0}{4}\qlp{''D"..., 0x08218f38) = 1 fputs("\tbbl3\qb3{'a}\en%\n", 0x08218f38) = 1 sprintf("2.00", "%#.*f", 2, ...) = 4 log(0, 0x40100000, 0x08073438, 0xbfffc443, 0x080963f8) = 288 drem(0x20000000, 0x40000106, 0, 0x3ff00000, 0x40027fdc) = 16416 fputs("B\n", 0x08218b30) = 1 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ ltrace traces the funktion calls of a program. Closer examination is only possible using a debugger like gdb. As it is years since I last used gdb (I have not even installed it on my system), I'm not a big help concerning debugging. I can only send you a core file for closer examination if you wish to ;) If you don't get one you probably you have to set it using ulimit or limit: limit coredumpsize 100000 or ulimit -c 100000 Of course core dumps are only useful in conjunction with a debugger like gdb (which has frontends as well). > the same sources in my normal DOS/Windows environment and they worked OK). > Sorry I don't have enough patience to wade through the info pages and climb > the debugger learning curve, but before giving up on that I did notice a > disclaimer somewhere that gdb has difficulting extracting values of > variables from FORTRAN programs compiled with g77...not very promising :-( Oh well, I hope at least my tracing output can help you a bit. Greets, Reinhard -- E-Mail: [EMAIL PROTECTED] Current Projects: Linux-Installation RH6.1 (90% finished) Java-DB and -Interface for Pincity Bach & H�ndel Trio Sonatas
