[plug] odd file manager hangs

[Craig Ringer]

James Devenish wrote:
> In message <41230784.8070208 at postnewspapers.com.au>
> on Wed, Aug 18, 2004 at 03:38:44PM +0800, Craig Ringer wrote:
 >
>>So of course, now that I've posted I manage to catch it.
> 
> Before you posted this, I was going to suggest that maybe the graphical
> browsers 'lock' each other when generating thumbnails (for instance). I
> know that this seems unlikely, but I wasn't sure if you'd discounted it
> yet.

I don't think it's the case. For one, I'm now fairly sure it's /not/ 
just happening when multiple file browsers access the directory, though 
it does seem to happen more often in that case.

>>craig    25840 25820 T finish_stop       nautilus --no-desktop
> 
> 
> Now, we've seen finish_stop before, haven't we? I don't know of its
> significance (or lack thereof), but it seems to crop up in your e-mails
> when you have these problems. Maybe it's just because of strace? I don't
> know.

I'm pretty sure it's a result of strace. Here's what I have (differently 
formatted, sorry) from before I attached strace to that process:

  1000 25819 wait4                   strace -o /tmp/trace-22333 nautilus
  1000 25820 rt_sigsuspend           nautilus --no-desktop
  1000 25840 schedule_timeout        nautilus --no-desktop
  1000 25841 rt_sigsuspend           nautilus --no-desktop
  1000 25842 rt_sigsuspend           nautilus --no-desktop
  1000 25845 rt_sigsuspend           nautilus --no-desktop
  1000 25846 rt_sigsuspend           nautilus --no-desktop
  1000 25847 rt_sigsuspend           nautilus --no-desktop
  1000 25848 rt_sigsuspend           nautilus --no-desktop
  1000 25849 rt_sigsuspend           nautilus --no-desktop
  1000 25850 rt_sigsuspend           nautilus --no-desktop
  1000 25851 rt_sigsuspend           nautilus --no-desktop
  1000 25852 rt_sigsuspend           nautilus --no-desktop

this is what I really /meant/ to post the first time, actually, but 
re-listed it using more sensible options. I hadn't noticed the state 
change caused by tracing the process until later.

I should also note that it looks like the nautilus hang from which this 
info was collected was in some way different to the normal freezes. In 
the normal freezes that it recovers from, the GUI continues to update, 
the context menu works, and if closed nautilus terminates normally. When 
I collected this info, I note that the GUI failed to update (except for 
the spinner - odd) and it requred a kill -9 to terminate.

In other words, possibly because the process was being traced it was 
behaving differently and this info probably can't be relied on. Drat.

>>poll([{fd=21, events=POLLIN}], 1, 2000) = 0
> 
> [...]
> 
>>that pipe is attached to:
>>nautilus  25841    craig   21r  FIFO        0,7             8476683 pipe
>>nautilus  25841    craig   22w  FIFO        0,7             8476683 pipe
> 
> 
> So...you say that 25841 is "not doing anything"? Is it doing a different
> type of "nothing" to all the other children of 25840?

Yes. When attaching strace to the other threads/processes, I get 
absolutely no output. This may be normal for threads; I really don't know.

> I don't know if
> I've understood the situation correctly, but is the parent waiting for
> I/O from its child?

I /suspect/ it's just a pipe used for parent/child communications.

> If so, I would wonder what is wrong with the child.
> Does the parent "free up" when you kill the child? (I guess this will be
> your last resort.)

The parent looks like it's just monitoring things - when the child dies, 
it dies shortly afterwards.

To be honest, I'm now suspecting at least the possiblity of a 
kernel/glibc issue (threading related?) as I've been able to spot this 
in konqueror (KDE 3.3) as well. Disabling fam had no effect. Most 
threaded apps on this machine work well (Mozilla, Evolution, etc) though.

Anyway, it's time for some upgrades and then I'll see what happens.

--
Craig Ringer