Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: [apple scitech] GDB debug fortran code
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apple scitech] GDB debug fortran code



I seem to have missed a few emails -- not sure what -C does, but I recall that Fortran is all pass-by-reference... how would you overrun a buffer in Fortran?
Anyhoo, another approach would be to step through the errant code in a debugger and watch for when the filename buffer becomes corrupt. Presumably at one point it has a good value, then that gets overwritten. At that point you would very likely find your culprit.


One thing I guarantee:  it's NOT a compiler bug.  Keep looking!

On Dec 13, 2007, at 3:48 PM, Bruce Truax wrote:

This is a typical symptom for a memory allocation error. Somewhere you are
writing over a return address on the stack or corrupting a pointer. The
for_get_s funtion is attempting to read something from an variable which no
longer exists in the program's memory map. Adding another line of code
probably moves stuff in memory just enough to avoid the conflict.


Bruce


On 12/13/07 4:06 PM, "David Gohara" <email@hidden> wrote:


On Dec 13, 2007, at 12:42 PM, Rich Cook wrote:


That's not my obvious thought! :-) That kind of "this can't be real" behavior makes me think that maybe you have some sort of linking issue -- are there several objects getting linked together? Can you do a "make clean" and rebuild and does that help?


There is a step where a bunch of object files are put into an archive for linking, but I always remove all of the object files and archive file before doing a rebuild.

Another "obvious" thought to me is that perhapss you have a buffer
overflow error in a stack or heap variable.


Similar to what Eddie posted, I tried compiling an executable with
all checking turned on ( -C ) and when I do this and compile the code,
the executable runs to completion without any problems.


If you leave the write statement out, I forget, what happens?  Your
program crashes?  Where does it crash?  What call is being made?


The program crashes with a:

forrtl: severe (174): SIGSEGV, segmentation fault occurred

   And in gdb it tells me where:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000014d7fffff
0x00000001001fc8cd in for__get_s ()
(gdb) backtrace
#0  0x00000001001fc8cd in for__get_s ()
#1  0x000000010021337b in for_read_seq_fmt ()
#2  0x0000000100148b27 in getprm () at getprm.f:108
#3  0x0000000100146851 in field () at field.f:57
#4  0x000000010019f6fb in mechanic () at mechanic.f:54
#5  0x0000000100001467 in analyze () at analyze.f:50
#6  0x00000001000013e4 in main ()

   The last two function calls originate from the Intel libraries
itself.

   The same code builds and run as a 32-bit executable. Everything I
try to do to see if the problem is originating in the code causes the
problem to go away. But I don't want to say it's a compiler bug until
I show more conclusively that something stupid in the code is causing
this.

   The same code also compiles and runs fine (as a 32-bit or 64-bit
executable) with gfortran and the Portland Compilers on Mac OS X.

   I'm simply at a loss as to what to try next.

   Thanks to everyone for their help so far.

Dave

David W. Gohara, Ph.D.
Center for Computational Biology
Washington University School of Medicine
http://gohara.wustl.edu
http://www.macresearch.org
314-362-1583 (phone)
617-216-8616 (cell)




_______________________________________________ Do not post admin requests to the list. They will be ignored. Scitech mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden

-- ____________________________________________________________ Bruce E. Truax email: email@hidden Optical Engineering Consultant

             Diffraction Limited Design LLC
388 Wedgewood Road             voice:  860-276-0450
Southington, CT  06489         fax:    860-620-9026
http://www.dld-llc.com
_____________________________________________________________


_______________________________________________ Do not post admin requests to the list. They will be ignored. Scitech mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden

--
✐Richard Cook
✇ Lawrence Livermore National Security
Bldg-453 Rm-4037, Mail Stop L-557
7000 East Avenue, Livermore, CA, 94550, USA
☎ (office) (925) 423-9605
☎ (fax) (925) 423-6961
---
Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept.
(opinions expressed herein are mine and not those of LLNS)


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Scitech mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: [apple scitech] GDB debug fortran code (From: Bruce Truax <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.