[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SIGKILL on child spawned with system(), runs fine by hand

Greetings, and thanks again so much for your help with this!

"Carlos O'Donell" <carlos@systemhalted.org> writes:

> On Wed, Feb 3, 2010 at 6:55 PM, Camm Maguire <camm@maguirefamily.org> 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.


>> 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			     		    camm@maguirefamily.org
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Reply to: