segmentation fault

Greetings.... Might anyone provide a clue as to the resolution for segmentation faults ? Certain programs will, at runtime, after successful compilation, spit out this inane error message. It referes to no line in any program, lists no error number. It simply spews "Segmentation fault", with an accompanying coredump. Analysis of that core file reveals nothing unusual. *crossing fingers* thank YOU !!

In article <378C83CA.95D9C0A9@vbws01.ba.ford.com>, Mike Devine <mdevine2@vbws01.ba.ford.com> wrote: >Might anyone provide a clue as to the resolution for segmentation faults Prerequisites: A bottle of ASA, a good debugger, a "Do Not Enter" sign for your cubicle or office, and someone's willingness to authorise your overtime. >Certain programs will, at runtime, after successful compilation, spit >out this inane error message. It referes to no line in any program, >lists no error number. It simply spews "Segmentation fault", with an >accompanying coredump. Analysis of that core file reveals nothing >unusual. Segmentation faults do return an error of sorts, usually signal 11 (assuming a Unix environment). They're not inane, but usually indicate an attempt to use memory that hasn't been allocated against your process. By catching the addressing error, the operating system has prevented your misbehaving process from clobbering other process' memory. A segmentation fault (or violation, often abbreviated SEGV) is often caused by an uninitialised pointer or exceeding some array bound. It will also show up if NULL is not guaranteed to be 0 on your system. It's good to check that a pointer is not null before deallocating the thing referenced by the pointer, but it is not enough to check it against 0 (for example, HP-UX 10 has four different values for NULL, all of which are caught by coding "if ( myPtr != NULL )", but only one of which is caught by "if ( myPtr )"). Cheap, dirty, and occasionally fun way: Run lint (if you're using C on a Unix box). Fix its legitimate complaints ("there are some things you just can't get lint to shut up about"). If the SEGV still occurs, bring out the heavy artillery. Compile a debuggable image with source references and run that. Examine the resulting core file with the debugger and get a source line. If you can run the program via the debugger, set a breakpoint just before the SEGV is reported. Examine the values of all pointers and array indices that are being used at the time, identify the offender, fix it, and you're one step closer to a clean program. If the fault is in another routine that you don't own (such as an Informix client library), make sure that you're passing in all of the parameters (and necessary global or environment variables) in accordance with the documented interface, and read the documentation for side effects that you have to work around. Expensive (and ISO 900x process in some shops) way: Get Purify from Rational/Pure Atria/Pure Software/whatever they're calling themselves this year. Re-compile your executable for use with Purify and link it with the Purify libraries. Run that in the Purify profiling environment, and pay heed to every fault it reports. Neither way is quick. Hope this helps. Jim -- W. Jim Jordan, Nortel Networks, Stop 29CA3A08 | +1 613 763 1568 PO Box 3511 Stn C, Ottawa, ON K1Y 4H7 Canada | wjjordan@nortelnetworks.com Opinions expressed are not necessarily those of Nortel Networks. Inbound spam filtering is in place. Don't send what I won't see.

How about more info, like OS or 4gl version?

Seg faults in an application are always application errors. Usually writing to or reading from an uninitialized pointer. I had one today. I had cut and pasted an error logging function from one utility to another and the new app was seg faulting. Turned out the cloned function was checking the sqlind field of the sqlda->sqlvar structure to see if any of the columns fetched were null and the new app had not assigned a data pointer to that field. Look for things like this or for overwritten pointers particularly caused by overflowing array boundaries in automatic variables. Another common cause in ESQL programs is freeing the memory allocated to the text of a statement that has been PREPARED or overwriting the text while the PREPARED statement is still in use. This usually results in a SEGV at the point of OPENing or FETCHing a cursor. But one of my programmers recently had one of these that we beat on for a week and it turned out to be an fprintf with no file pointer argument. Art S. Kagel Mike Devine wrote: > > Greetings.... > > Might anyone provide a clue as to the resolution for segmentation faults > ? > > Certain programs will, at runtime, after successful compilation, spit > out this inane error message. It referes to no line in any program, > lists no error number. It simply spews "Segmentation fault", with an > accompanying coredump. Analysis of that core file reveals nothing > unusual. > > *crossing fingers* > > thank YOU !!