Hi,
I have a python application that kills X. I.e. the X process terminates,
and all X programs receive broken links to the display and therefore
also exit.
The problem is, this python application is not supposed to kill
anything, so I think it is a bug in X, but I cannot find any way to
trace the fault. Even gdb says the application was killed, so exited
normally, and results in no back trace.
Is there any way in Linux to find out who did the "killing" ?
James
Hi,
On Sun, Jan 15, 2006 at 05:36:59PM +0000, James Courtier-Dutton wrote:
> Hi,
>
> I have a python application that kills X. I.e. the X process terminates,
> and all X programs receive broken links to the display and therefore
> also exit.
>
> The problem is, this python application is not supposed to kill
> anything, so I think it is a bug in X, but I cannot find any way to
> trace the fault. Even gdb says the application was killed, so exited
> normally, and results in no back trace.
>
> Is there any way in Linux to find out who did the "killing" ?
Probably that X was killed because your system encountered an OOM
(out of memory) condition. For instance, if python eats all the
memory, and if you have not set any memory usage limit with ulimit,
then you can get anything killed.
> James
Willy
Willy Tarreau wrote:
> Hi,
>
> On Sun, Jan 15, 2006 at 05:36:59PM +0000, James Courtier-Dutton wrote:
>
>>Hi,
>>
>>I have a python application that kills X. I.e. the X process terminates,
>>and all X programs receive broken links to the display and therefore
>>also exit.
>>
>>The problem is, this python application is not supposed to kill
>>anything, so I think it is a bug in X, but I cannot find any way to
>>trace the fault. Even gdb says the application was killed, so exited
>>normally, and results in no back trace.
>>
>>Is there any way in Linux to find out who did the "killing" ?
>
>
> Probably that X was killed because your system encountered an OOM
> (out of memory) condition. For instance, if python eats all the
> memory, and if you have not set any memory usage limit with ulimit,
> then you can get anything killed.
>
>
>>James
>
>
> Willy
>
>
>
My point is that there is no way to tell what kills me. No messages in
syslog...nothing. Surely the OOM killer would send a message to ksyslog,
or at least dmesg?
James
>
> My point is that there is no way to tell what kills me. No messages in
> syslog...nothing. Surely the OOM killer would send a message to ksyslog, or at
> least dmesg?
>
Yes, OOM usually does printk(). So it depends on how you have syslog set
up (and the console loglevel - which is reponsible for bringing it right
to console).
Jan Engelhardt
--
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/
On Tue, 2006-01-17 at 21:12 +0100, Jan Engelhardt wrote:
> >
> > My point is that there is no way to tell what kills me. No messages in
> > syslog...nothing. Surely the OOM killer would send a message to ksyslog, or at
> > least dmesg?
> >
> Yes, OOM usually does printk(). So it depends on how you have syslog set
> up (and the console loglevel - which is reponsible for bringing it right
> to console).
I think you are missing the point - the problem is almost certainly NOT
an OOM condition as there's nothing in the logs. It's a bug in the X
server. The question is, how does one debug that.
Here is the original question again:
"I have a python application that kills X. I.e. the X process
terminates,and all X programs receive broken links to the display and
therefore also exit.
The problem is, this python application is not supposed to kill
anything, so I think it is a bug in X, but I cannot find any way to
trace the fault. Even gdb says the application was killed, so exited
normally, and results in no back trace.
Is there any way in Linux to find out who did the "killing" ?"
Lee
Jan Engelhardt wrote:
>>My point is that there is no way to tell what kills me. No messages in
>>syslog...nothing. Surely the OOM killer would send a message to ksyslog, or at
>>least dmesg?
>>
>
> Yes, OOM usually does printk(). So it depends on how you have syslog set
> up (and the console loglevel - which is reponsible for bringing it right
> to console).
>
>
> Jan Engelhardt
So, I can conclude that as I am not seeing any OOM messages in dmesg,
that the OOM is not responsible for my kills. Even without syslog set
up, I should see the OOM in dmesg shouldn't I?
So, I have a mystery reason why X getting killed.
Can anyone else suggest any other possible causes for unexpected X
getting killed?
James
On 1/17/06, James Courtier-Dutton <[email protected]> wrote:
> Jan Engelhardt wrote:
> >>My point is that there is no way to tell what kills me. No messages in
> >>syslog...nothing. Surely the OOM killer would send a message to ksyslog, or at
> >>least dmesg?
You may try using strace . It may throw some light on the cause of the problem.
Regards
Ram gupta
On Tue, Jan 17, 2006 at 03:32:11PM -0600, Ram Gupta wrote:
> On 1/17/06, James Courtier-Dutton <[email protected]> wrote:
> > Jan Engelhardt wrote:
> > >>My point is that there is no way to tell what kills me. No messages in
> > >>syslog...nothing. Surely the OOM killer would send a message to ksyslog, or at
> > >>least dmesg?
>
> You may try using strace . It may throw some light on the cause of the problem.
I would particularly suggest using 'strace -tt' both on X and on the
python process. It will make it easier to analyse the causes later. You
might even encounter a bug in the python application causing an explicit
kill of a miscalculated pid (although unlikely, but who knows ?).
> Regards
> Ram gupta
Regards,
Willy
Willy Tarreau wrote:
> On Tue, Jan 17, 2006 at 03:32:11PM -0600, Ram Gupta wrote:
>
>>On 1/17/06, James Courtier-Dutton <[email protected]> wrote:
>>
>>>Jan Engelhardt wrote:
>>>
>>>>>My point is that there is no way to tell what kills me. No messages in
>>>>>syslog...nothing. Surely the OOM killer would send a message to ksyslog, or at
>>>>>least dmesg?
>>
>>You may try using strace . It may throw some light on the cause of the problem.
>
>
> I would particularly suggest using 'strace -tt' both on X and on the
> python process. It will make it easier to analyse the causes later. You
> might even encounter a bug in the python application causing an explicit
> kill of a miscalculated pid (although unlikely, but who knows ?).
>
>
>>Regards
>>Ram gupta
>
>
> Regards,
> Willy
>
I have managed to narrow down the problem. strace did not help at all.
The problem was the Load "freetype" line in xorg.conf.
With it commented out, python wsjt.py runs fine.
That would explain why strace did not help at all.
So, this is not a kernel problem now, it is an Xorg problem.
Section "Module"
# Load "glx"
Load "record"
Load "extmod"
Load "dbe"
Load "dri"
Load "xtrap"
# Load "freetype" ### freetype crashes X in wsjt.py
Load "type1"
Load "speedo"
EndSection
I will have to ask the Xorg people how to run gdb on the freetype module.
James
On 17 Jan 2006, Lee Revell wrote:
> The problem is, this python application is not supposed to kill
> anything, so I think it is a bug in X, but I cannot find any way to
> trace the fault. Even gdb says the application was killed, so exited
> normally, and results in no back trace.
>
> Is there any way in Linux to find out who did the "killing" ?"
It's probably easiest to build the X server with debugging and use the
two-machine procedure outlined in
<http://xorg.freedesktop.org/wiki/DebuggingTheXserver>.
(If you don't have two machines and two displays, debugging it gets
very much harder.)
--
`Logic and human nature don't seem to mix very well,
unfortunately.' --- Velvet Wood