[haiku-development] Re: R5 Epson printer addon and _BMCItem_

Hi Ingo,

Ingo Weinhold schrieb:

On 2008-07-07 at 18:21:57 [+0200], Julun <HOST.HAIKU@xxxxxx> wrote:

The second one is a bit different, it happens when one is going to
create a epson printer. While calling unload_add_on(id) in the
print_server i get the crash with (see stack trace attached). What i
need here is some advice how to track that down or where to start
looking at. I already had a look a BLoopers Quit().


I prepared a patch that fixes the crash for me, but before I'm going to
apply it I would like to ask to review it from some person that have a
deeper knowledge of BLooper and BApplication.

What happened in unload_add_on was that Loopers::Quit was calling delete
this and when returning from destructor calling exit_thread() which
failed. After moving it into the destructor everything works as
expected. I adjusted BApplication to take that into account. It seems
also that BHandler's destructor is not executed in case fRunCalled is true.
Maybe I miss something obvious, but why would exit_thread() fail? And why would moving it to the destructor help in this case?
It fails only in combination with unload_add_on, I'm even unsure if exit_thread fails here. I simply noticed that if an add-on creates a window, after closing that window it will crash if the exit_thread call is not in the destructor. Maybe unload_add_on or exit_thread will access something in the already freed looper?
I could not find the unload_add_on implementation, will it end up in runtime_loader/elf/unload_library ? 

 I even think it is
harmful to exit_thread() in the destructor, since neither will the BHandler destructor be invoked, nor will the memory for the object be freed.
Seems this is what i noticed, but we still should be able to call the BHandler destructor manually then. Anyway, sounds not clean at all.
Regarding BLooper::Run() moving the fMsgPort check up makes sense IMO, but I don't think moving "fRunCalled = true" before the thread has been created successfully does.
This was just a feeling, even if we couldn't spawn the thread we still have called run on the looper. But i will leave it as it is. :)
There is at least one good outcome so far, i think i found why Cortex and IconOMatic will crash on close with gcc4. Will send a diff soon. 


Thanks for your comments, I'm still looking for some input on that.  :)

Regards,
Karsten

Other related posts: