r25309 removed desktop icons from first boot

[luroh]

SW: 32-bit Ubuntu 8.04, Vmware Player 2.0.3, vmware-image built with gcc 2.95 HW: Lenovo T60 laptop

Since hrev25309, with a freshly built .vmdk, the Haiku desktop icons (Haiku, Trash, Home) don't appear until after first reboot.

[anevilyak]

This was one of Ingo's changes I believe, reassigning.

[diver]

I have the same problem with reaal hw.

[bonefish]

I've seen that problem earlier, so I don't think my changes are to blame. They might cause the bug to occur more frequently though. Maybe the incoming MIME update messages cause some message queue to run full and result in a deadlock. Might be related to #1715.

[anevilyak]

Hi, a minor observation to add to this bug: I looked into this with gdb, and Tracker's desktop window thread was waiting on a port read, which I assume is normal since it should normally wait for app_server messages. After telling it to continue however, it woke up again and the Desktop repainted and worked normally. Any ideas?

[luroh]

Fwiw, the bug does not appear when running haiku.image in (unaccellerated) qemu.

[jackburton]

Replying to luroh:

Fwiw, the bug does not appear when running haiku.image in (unaccellerated) qemu.

It does here (unaccelerated qemu under ubunty Hardy)

[luroh]

Replying to jackburton:

Replying to luroh:

Fwiw, the bug does not appear when running haiku.image in (unaccellerated) qemu.

It does here (unaccelerated qemu under ubunty Hardy)

It does here too now.

[emitrax]

I don't know if this is useful information or not, but the icons are actually there, although they don't get displayed. In fact, if you try to drag them around you'll see them, or if you right click on them the related menu will come up.

BTW: Still happens with latest hrev25698, vmplayer on linux.

[axeld]

I've investigated this a bit, and the Desktop window's message port is filled up with B_META_MIME_CHANGED messages - caused by the script that updates all MIME information upon first start.

Not sure why it didn't manage to keep up. I think the solution to this problem in general should be to change the registrar to reporting in less detail when adding whole MIME types.

[bonefish]

Replying to axeld:

I've investigated this a bit, and the Desktop window's message port is filled up with B_META_MIME_CHANGED messages - caused by the script that updates all MIME information upon first start.

Not sure why it didn't manage to keep up. I think the solution to this problem in general should be to change the registrar to reporting in less detail when adding whole MIME types.

Optimizing the MIME update message mechanism is certainly a good idea. I disagree, however, that this is the solution to this bug. That a port runs full should be rather harmless. That it isn't emptied is a real problem, though, and should be fixed. Until that happened, I wouldn't do anything that makes the bug less reproducible.

[axeld]

I just tried it on my quad core, and came to the same conclusion :-) It still happens there, even though there should be plenty of CPU power free to empty that message port. I'll check tomorrow what this window is up to.

[axeld]

Fixed in hrev25719. I'll open a new ticket about the registrar improvements.

[axeld]

Ticket #2286 tracks the registrar's part in this problem.

[stippi]

What I am wondering though... shouldn't the Tracker window recover after a while? Was nothing drawn because of the app_server bug (when the return code of SendMessage() was still not checked)?

[axeld]

After the app_server fix, the Tracker window would recover after a while, but I'm not sure how exactly - I mean I don't know who triggered the next update message that finally arrived.