| Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
| Notice: | Welcome to the Digital UNIX Conference |
| Moderator: | SMURF::DENHAM |
| Created: | Thu Mar 16 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 10068 |
| Total number of notes: | 35879 |
We've had a customer report problems with a segmentation
fault, with a very strange stack trace. We saw a similar
problem once before, and it went away, I think when we changed
the debug options on the compiler. (For the record, we
are currently compiling with the -g switch, then stripping
debug symbols from the images).
The stack trace is below - the address on the top of the
stack (the bottom of the list) is unusual - does this
provide any clues as to what is happening? (I think they
are running on some flavor of UNIX 3.2)
#1 PC==0x12015b9fc in void ErmHolder::logIt(void) "erm.cxx":1194 { break }
#2 PC==0x12015cd7c in void ErmHolder::handle(void) "erm.cxx":1655 { break }
#3 PC==0x12015bcc4 in void fatalSigHndlr(int) "erm.cxx":1285 { break }
#4 PC==0x3ff8051d4c4 in ??? { break }
#5 PC==0x400000800000000 in ??? { break }
-Stan Neumann
(Note: this is a different customer from note 9580)
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 9610.1 | QUARRY::neth | Craig Neth | Thu Apr 24 1997 12:08 | 5 | |
It looks like the sort of address you see when broken code corrupts the saved return address on the stack. These can be fun to debug. Check for running off the ends of arrays and mismatched structure assignments, for a start. | |||||
| 9610.2 | Maybe try ATOM 'third degree' ? | DECC::SULLIVAN | Jeff Sullivan | Thu Apr 24 1997 13:55 | 24 |
Re .1: > It looks like the sort of address you see when broken code corrupts the saved > return address on the stack. > These can be fun to debug. Check for running off the ends of arrays and > mismatched structure assignments, for a start. This is probably it and "fun" is in they eye of the beholder. I've sometimes found that using ATOM "third degree" will help point out memory overwrites. This is certainly one of the first things I would try. See man atom(1) and man third(5) on a V4.0* system. See also http://www.zk3.dec.com/dude/program_analysis/ ATOM will probably not uncover a mismatched structure assignment, though, and I've seen those cause this type of problem more than a few times in the past. I think compiling the code -g (-O0) is really just covering up a bug, either in the compiler or more probably, in the source code. Have "fun"! -Jeff | |||||
| 9610.3 | Different customer; strikingly similar problem... :-} | WTFN::SCALES | Despair is appropriate and inevitable. | Thu Apr 24 1997 16:47 | 8 |
.0> this is a different customer from note 9580 *grin* But it IS just the sort of thing which could have resulted in a an illegal instruction fault if the address hadn't been invalid (which is what caused the SEGV) and had instead pointed to data... 8-) Webb | |||||