Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#5119 closed bug (fixed)

[Paladin] KDL on "Extensions" menu items

Reported by: mr.Noisy Owned by: axeld
Priority: high Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #5128, #5145
Has a Patch: no Platform: x86

Description

100% reproducible:

  1. Open any file in PalEdit 1.1.
  1. Click on any item in 'Extensions' menu.

Tested with hrev34427 GCC4/Hybrid on VirtualBox 3.1.0.

Stack trace attached.

Attachments (1)

Haiku-KDL.PNG (83.8 KB) - added by mr.Noisy 9 years ago.

Download all attachments as: .zip

Change History (13)

Changed 9 years ago by mr.Noisy

Attachment: Haiku-KDL.PNG added

comment:1 Changed 9 years ago by axeld

Component: Kits/Application KitSystem/Kernel
Priority: normalhigh

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

comment:2 Changed 9 years ago by axeld

Status: newassigned

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

comment:3 Changed 9 years ago by axeld

Resolution: fixed
Status: assignedclosed

Fixed in hrev34681.

comment:4 Changed 9 years ago by stippi

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

comment:5 Changed 9 years ago by axeld

Resolution: fixed
Status: closedreopened

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

comment:6 Changed 9 years ago by stippi

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

comment:7 Changed 9 years ago by bonefish

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

comment:8 Changed 9 years ago by bonefish

Blocking: 5145 added

(In #5145) Duplicate of #5119.

comment:9 Changed 9 years ago by bonefish

Resolution: fixed
Status: reopenedclosed

Should be fixed in hrev34687.

comment:10 Changed 9 years ago by bonefish

Blocking: 5128 added

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

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

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

Note: See TracTickets for help on using tickets.