I can freeze the system reproducibly in 2.6.35-rc2 and 2.6.34 when I simply try
to strace a running X. strace-ing other processes is no problem. Nothing in the
logs unfortunately. This happens with nosmp and with smp. I would like to track
this down. What should I be looking for? Apart from trying to bisect it, which I
will try.
Ortwin
Linux mithril 2.6.35-rc2 #6 SMP PREEMPT Mon Jun 7 07:37:03 CEST 2010 i686
Intel(R) Core(TM)2 CPU T7600 @ 2.33GHz GenuineIntel GNU/Linux
On Wed, Jun 09, 2010 at 08:38:23PM +0200, Ortwin Gl?ck wrote:
> I can freeze the system reproducibly in 2.6.35-rc2 and 2.6.34 when I simply try
> to strace a running X. strace-ing other processes is no problem. Nothing in the
> logs unfortunately. This happens with nosmp and with smp. I would like to track
> this down. What should I be looking for? Apart from trying to bisect it, which I
> will try.
Just to make sure, you're not trying to strace X from within X, are you?
--
Matthew Garrett | [email protected]
On 09.06.2010 21:52, Matthew Garrett wrote:
> Just to make sure, you're not trying to strace X from within X, are you?
Oh... now that you mention it... Is that a silly thing to do?
strace X from a different terminal works fine :-)
But freezing the system because of that? I mean an error message, log, anything
would be "nice".
On Wed, Jun 09, 2010 at 10:02:21PM +0200, Ortwin Gl?ck wrote:
> On 09.06.2010 21:52, Matthew Garrett wrote:
> > Just to make sure, you're not trying to strace X from within X, are you?
>
> Oh... now that you mention it... Is that a silly thing to do?
> strace X from a different terminal works fine :-)
>
> But freezing the system because of that? I mean an error message, log, anything
> would be "nice".
strace needs to output text via X, which generates output which needs to
be output via X... and you'll tend to deadlock. If X is holding any
interesting kernel locks at that point then it wouldn't surprise me if
the machine ends up dead.
--
Matthew Garrett | [email protected]
On 09.06.2010 22:06, Matthew Garrett wrote:
> strace needs to output text via X, which generates output which needs to
> be output via X... and you'll tend to deadlock. If X is holding any
> interesting kernel locks at that point then it wouldn't surprise me if
> the machine ends up dead.
Alright. It *is* a silly thing to do. Sorry.
On Wed, 9 Jun 2010, Matthew Garrett wrote:
> On Wed, Jun 09, 2010 at 10:02:21PM +0200, Ortwin Gl?ck wrote:
> > On 09.06.2010 21:52, Matthew Garrett wrote:
> > > Just to make sure, you're not trying to strace X from within X, are you?
> >
> > Oh... now that you mention it... Is that a silly thing to do?
> > strace X from a different terminal works fine :-)
> >
> > But freezing the system because of that? I mean an error message, log, anything
> > would be "nice".
>
> strace needs to output text via X, which generates output which needs to
> be output via X... and you'll tend to deadlock. If X is holding any
> interesting kernel locks at that point then it wouldn't surprise me if
> the machine ends up dead.
Nothing to do with kernel locks. strace hooks into the syscall and
intercepts the data, so X is stopped at that point. Now try to send
output to a program which you stopped yourself :)
Thanks,
tglx
On Wed, Jun 09, 2010 at 10:47:23PM +0200, Thomas Gleixner wrote:
> On Wed, 9 Jun 2010, Matthew Garrett wrote:
> > strace needs to output text via X, which generates output which needs to
> > be output via X... and you'll tend to deadlock. If X is holding any
> > interesting kernel locks at that point then it wouldn't surprise me if
> > the machine ends up dead.
>
> Nothing to do with kernel locks. strace hooks into the syscall and
> intercepts the data, so X is stopped at that point. Now try to send
> output to a program which you stopped yourself :)
Oh, yeah, and ctrl+alt+fwhatever is handled by X.
--
Matthew Garrett | [email protected]