Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#2212 closed bug (fixed)

r25309 removed desktop icons from first boot

Reported by: luroh Owned by: bonefish
Priority: normal Milestone: R1
Component: Applications/Tracker Version: R1/pre-alpha1
Keywords: Cc: anevilyak, andreasf
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

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.

Change History (16)

comment:1 Changed 11 years ago by anevilyak

Cc: anevilyak added
Owner: changed from axeld to bonefish

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

comment:2 Changed 11 years ago by diver

I have the same problem with reaal hw.

comment:3 Changed 11 years ago by bonefish

Component: - GeneralApplications/Tracker

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.

comment:4 Changed 11 years ago by 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?

comment:5 Changed 11 years ago by luroh

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

comment:6 in reply to:  5 ; Changed 11 years ago by 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)

comment:7 in reply to:  6 Changed 11 years ago by 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.

comment:8 Changed 11 years ago by andreasf

Cc: andreasf added

comment:9 Changed 11 years ago by 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.

comment:10 Changed 11 years ago by axeld

Component: Applications/TrackerServers/registrar

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.

comment:11 in reply to:  10 Changed 11 years ago by 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.

comment:12 Changed 11 years ago by 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.

comment:13 Changed 11 years ago by axeld

Component: Servers/registrarApplications/Tracker
Resolution: fixed
Status: newclosed

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

comment:14 Changed 11 years ago by axeld

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

comment:15 Changed 11 years ago by 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)?

comment:16 Changed 11 years ago by 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.

Note: See TracTickets for help on using tickets.