Greetings, and thanks again so much for your help with this! "Carlos O'Donell" <[email protected]> writes:
> On Wed, Feb 3, 2010 at 6:55 PM, Camm Maguire <[email protected]> wrote: >> Greetings! So this is not a kernel error? These messages are >> debugging code only for userland segfaults? My apologies if so for >> misunderstanding. Looked like an oops. > > It is not an oops. It is a debugging aid for application developers, > it's the context when the application faulted. > OK >> I'll try to isolate, but my guess is that this is dependent on the >> memory layout of the parent program. Could some fork be running into >> already used memory? I have a smaller executable from a different gcl >> version which does not trigger this on the same machine. > > I don't know what you mean by "fork be running into already used memory." > I presume system() calls fork or similar. Which can die if memory is not available for some reason. >> Why can't I get a segfault in gdb with an offending address in the >> normal fashion if this is either libc or my program? The sigkill is >> what made me suspect the kernel. > > When run under gdb it doesn't fault? > No. system() returns 9 to the parent. The parent does not fault. >> Can I decode the instruction on paer? If so how? > > Use this program, it takes hex IIR values and converts them into instructions: > http://cvs.parisc-linux.org/build-tools/disasm?revision=1.1&view=markup > > Be careful that some instructions decode to slightly different > variants, but the same instruction non-the-less. > Thanks, I'll check this out. Take care, > Cheers, > Carlos. > > > > -- Camm Maguire [email protected] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
