[Paladin] KDL on "Extensions" menu items

[mr.Noisy]

100% reproducible:

1. Open any file in PalEdit 1.1.

2. Click on any item in 'Extensions' menu.

Tested with hrev34427 GCC4/Hybrid on VirtualBox 3.1.0.

Stack trace attached.

[axeld]

Interesting, this looks like a bug in the port subsystem I recently rewrote. Will check if this is reproducible for me as well.

[axeld]

Not 100% reproducible, but it did happen after some tries. Looking into it now.

[axeld]

Fixed in hrev34681.

[stippi]

Unfortunately, the same panic() happens now 100% reproduceably for me when I just launch MediaPlayer.

[axeld]

Just launching MediaPlayer without any file? That's what I just tried in VMware (dual CPU) but there was no panic.

[stippi]

Yes, but I suppose it tries to open my previous playlist. I definitely had something playing before upgrading.

[bonefish]

Also just encountered it in hrev34684 while restarting the media server. Will review the port code.

[bonefish]

(In #5145) Duplicate of #5119.

[bonefish]

Should be fixed in hrev34687.

[bonefish]

(In #5128) Duplicate of #5119 and fixed in hrev34687.

[korli]

Ingo, I now encounter (on hrev34699) this deadlock on a port read when launching playfile two times. Is it related to your commit, or do I open a new bug?

#0  0xffff0114 in ?? ()
#1  0x0055346a in port_buffer_size_etc () from /boot/system/lib/libroot.so
#2  0x002c439d in BPrivate::LinkReceiver::AdjustReplyBuffer () from /boot/system/lib/libbe.so
#3  0x002c445f in BPrivate::LinkReceiver::ReadFromPort () from /boot/system/lib/libbe.so
#4  0x002c4243 in BPrivate::LinkReceiver::GetNextMessage () from /boot/system/lib/libbe.so
#5  0x002dc951 in BPrivate::ServerLink::FlushWithReply () from /boot/system/lib/libbe.so
#6  0x003386ac in BPrivate::BPrivateScreen::_IsValid () from /boot/system/lib/libbe.so
#7  0x0033825f in BPrivate::BPrivateScreen::_Get () from /boot/system/lib/libbe.so
#8  0x00338171 in BPrivate::BPrivateScreen::Get () from /boot/system/lib/libbe.so
#9  0x0033ec33 in BScreen::BScreen () from /boot/system/lib/libbe.so
#10 0x003101fa in system_colors () from /boot/system/lib/libbe.so
#11 0x002f3f2b in BPrivate::PaletteConverter::_InitializeDefaultAppServer () from /boot/system/lib/libbe.so
#12 0x00568b1d in pthread_once () from /boot/system/lib/libroot.so
#13 0x002f3efa in BPrivate::PaletteConverter::InitializeDefault () from /boot/system/lib/libbe.so
#14 0x00312dcb in _init_interface_kit_ () from /boot/system/lib/libbe.so
#15 0x002bdc3d in BApplication::_InitGUIContext () from /boot/system/lib/libbe.so
#16 0x002bb396 in BApplication::_InitData () from /boot/system/lib/libbe.so
#17 0x002ba810 in BApplication::BApplication () from /boot/system/lib/libbe.so
#18 0x00201685 in main ()

[bonefish]

Replying to korli:

Ingo, I now encounter (on hrev34699) this deadlock on a port read when launching playfile two times. Is it related to your commit, or do I open a new bug?

Please open a new ticket. Also add a bit more info (the stack trace as such just looks like a normal port_buffer_size_etc() syscall). Like full (kernel + user) stack traces of the involved threads, what they are waiting on exactly, as well as the output of the "port" command for the port in question.