Tracker Deadlock on AppLooper Port

[bonefish]

r23628, VMware, not really reproducible

The Tracker main thread seems to have managed to deadlock on the full app looper port while initializing the desktop window. Cf. the attached kernel debugger session.

Also somewhat mysterious is that the desktop window thread is already running, although its Show() should not be invoked until a later point in BContainerWindow::Init(const BMessage*).

[axeld]

I've seen this as well, but only after BeGeistert. When it happens here, the Deskbar is locked up, too, and Tracker doesn't show at all. When I then kill the Deskbar, Tracker gets to that point most of the time, sometimes it manages to start completely, though.

It either has something to do with the ProcessController automatism, or with the Registrar changes you did with Michael during BeGeistert. I'm pretty certain, though, that I didn't see this problem before you added ProcessController to the Deskbar.

[stippi]

I was also observing Deskbar lock ups on startup pretty frequently and suspected the automatic ProcessController addition. Tracker always runs fine though.

[bonefish]

Replying to axeld:

I've seen this as well, but only after BeGeistert. When it happens here, the Deskbar is locked up, too, and Tracker doesn't show at all. When I then kill the Deskbar, Tracker gets to that point most of the time, sometimes it manages to start completely, though. It either has something to do with the ProcessController automatism, or with the Registrar changes you did with Michael during BeGeistert.

The only actual change in the registrar was that MIME notification messages are now sent using the message deliverer service, so that the MIME manager thread won't block when the target port is full. This shouldn't have any effect on other apps.

I'm pretty certain, though, that I didn't see this problem before you added ProcessController to the Deskbar.

It may very well be, that the bug shows up (more often) due to this change. I don't know about Deskbar (it looked normal when I encountered the bug, but I didn't try to use it), but Tracker definitely has at least a design problem. Sending messages to your own port is just not a good idea. Though I wonder why the port is used anyway, though -- shouldn't local messages bypass the port?

Anyway, I suppose there's just too much initialization done in ReadyToRun(), so that the port can run full. It would be interesting to know what messages are queue.

[jackburton]

Isnt' this a dup of #1745 ?

[bonefish]

Replying to jackburton:

Isnt' this a dup of #1745 ?

Not really. Here the Tracker main thread sends a message to its own app looper port, which is full. It's a bit weird, why the intra-app messaging shortcut isn't used.

[anevilyak]

Is it possible it's not using the intra-app shortcut because it initializes the BMessenger that it passes to StartWatching by signature rather than by a looper/handler pointer? Bear in mind this code is shared for BFilePanel as well, so it may not necessarily be invoked from Tracker itself, but it seems BMessenger doesn't detect the fact that it's the same app when the signature constructor is used. Perhaps I'm wrong.

[axeld]

That can't be the problem; the BMessenger always only resolves to a combination of team and port - it's not responsible for the intra-app short cut, that all happens in BMessage.

Also, the problem doesn't seem to happen on BeOS R5 which does not have such a shortcut, it always uses the port.

[anevilyak]

Replying to axeld:

That can't be the problem; the BMessenger always only resolves to a combination of team and port - it's not responsible for the intra-app short cut, that all happens in BMessage. Also, the problem doesn't seem to happen on BeOS R5 which does not have such a shortcut, it always uses the port.

In that case it seems we have two bugs here. That having been said, I'm noticing some relatively odd behavior on this one with the debugger. The bug consistently happens here in the latest revs on real hardware, and when I break into it with the debugger, it's waiting to read from the port, which shouldn't be the case if the port is full of waiting data. However, when I then tell it 'continue', it catches a SIGTRAP again for some reason. continue a second time, and suddenly the thread wakes up and all is normal (i.e. Desktop repaints again, etc.). Is it possible it's hitting some edge case/race with respect to waking up the thread when new data is ready for read on the port?

With respect to the other issue (intra-app shortcut), the only way I could see this failing is if BPrivate::current_team() is not resolving to the correct team ID at that point, which wouldn't really make sense though since I thought get_thread_info() should return correct data more or less as soon as the thread is created. Will see if I can add some traces and debug this more since I have it 100% reproducible.

[jackburton]

Is this still valid ?