X killed

X killed

[James Courtier-Dutton]

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

Re: X killed

[Willy Tarreau]

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

Re: X killed

[James Courtier-Dutton]

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

Re: X killed

[Jan Engelhardt]

>
> 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/

Re: X killed

[Lee Revell]

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

Re: X killed

[Nix]

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

Re: X killed

[James Courtier-Dutton]

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

Re: X killed

[Ram Gupta]

On 1/17/06, James Courtier-Dutton <James@superbug.demon.co.uk> 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

Re: X killed

[Willy Tarreau]

On Tue, Jan 17, 2006 at 03:32:11PM -0600, Ram Gupta wrote:
> On 1/17/06, James Courtier-Dutton <James@superbug.demon.co.uk> 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

Re: X killed

[James Courtier-Dutton]

Willy Tarreau wrote:
> On Tue, Jan 17, 2006 at 03:32:11PM -0600, Ram Gupta wrote:
> 
>>On 1/17/06, James Courtier-Dutton <James@superbug.demon.co.uk> 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