Hi Andrew, thanks for your reply.
Sorry for the delay in replying - I was waiting for it to crash again :) And it has. (I tried mem=nopentium but it still locks up). This time it locked up just after I started a 'find . -name sa1100*' on a big directory structure. No mouse pointer either. Not sure if this is relevant tho. It is possible that this is related because the last time it locked up was when I hit 'tab' with the advanced bash autocompletion script (and I imagine that does some sort of filesystem search too). I did an strace -p 241 (241 is the pid of the XFree86 process at this time). I get this: --- SIGALRM (Alarm clock) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) --- sigreturn() = ? (mask now []) --- SIGALRM (Alarm clock) --- sigreturn() .... [repeats ad nauseum, and very quickly too] I also tried ltrace - same syscall over and over again. Nothing else of interest there it would seem. Also (let it run for 10 seconds or so): :~$ sudo strace -c -p 241 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.002046 3 590 sigreturn ------ ----------- ----------- --------- --------- ---------------- 100.00 0.002046 590 total > Next time you get to ssh in to the machine in this state, > you could try strace'ing the X process, which might give us a clue as to > where the problem is. > > There is a modified version of gdb, which understands XFree86 > driver modules, an old version (for gdb 4.17) at: > ftp://ftp.xfree86.org/pub/xpert/gdb/ > and a newer one (for gdb 5.1..) at: > ftp://people.redhat.com/mharris/gdb-xfree86/ > You can use the standard gdb, but unless you have a statically > built server, gdb wont understand the Xfree86 modules, so wont > help if it is looping inside a driver. How exactly should I use this? > Can you try attaching the debug to the looping process, and get some idea > of where it looping ? If you can get a core dump, try to see where that is > too, but it sounds as if the processes doesn't die. Can't get it to die - unless you know of a way of forcing a process to die and core-dump? Thanks for the help - any more thoughts? Cheers, David. _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
