Opened 9 years ago

Last modified 2 years ago

#4846 assigned bug

thread deadlock in BMenuField

Reported by: augiedoggie Owned by: nobody
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

While attempting to diagnose a problem in the BeAE program, I came across some odd behavior within BMenuField. The problem only occurs, on average, around 1 out of every 5 tries. Basically you have a BMenuItem attached to a BMenuField, which when selected, destroys the BMenuField object. The BMenuField destructor then gets stuck in wait_for_thread() waiting for the mouse tracking thread to die. I hope I've made that clear :)

I'm attaching some sample code which might explain it better. I assume that this code and the stuff from BeAE worked on BeOS, but, I no longer have it installed to test.

Attachments (1)

mftest.cpp (1.5 KB) - added by augiedoggie 9 years ago.

Download all attachments as: .zip

Change History (6)

Changed 9 years ago by augiedoggie

Attachment: mftest.cpp added

comment:1 Changed 9 years ago by augiedoggie

As a side note. I don't see the attached menu being deleted anywhere in the BMenuField source. Isn't it supposed to own the attached BMenu?

comment:2 in reply to:  1 Changed 9 years ago by augiedoggie

Replying to augiedoggie:

As a side note. I don't see the attached menu being deleted anywhere in the BMenuField source. Isn't it supposed to own the attached BMenu?

Umm, yeah. Disregard that last comment. I wasn't thinking clearly :) I see the internal menubar and menuitem(s) are added as child views.

comment:3 Changed 4 years ago by jackburton

Still reproduceable ?

comment:4 in reply to:  3 Changed 4 years ago by augiedoggie

Replying to jackburton:

Still reproduceable ?

Yes, still locks up the application. Tested on x86_gcc2 - hrev48282

comment:5 Changed 2 years ago by axeld

Owner: changed from axeld to nobody
Status: newassigned
Note: See TracTickets for help on using tickets.