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(),
though.
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: