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

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

Greetings!  In case this helps, at least under gdb, the parent is
dying before we even get to execve.  If a sleep is put in the child at
the top of main(), it is never reached.  We can break at system(),

Take care,

"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."
>> 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?
>> 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.
> Cheers,
> Carlos.

Camm Maguire			     		    camm@maguirefamily.org
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Reply to: