[haiku-development] Re: R5 Epson printer addon and _BMCItem_
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 10 Jul 2008 18:54:34 +0200
On 2008-07-10 at 18:27:34 [+0200], Julun <HOST.HAIKU@xxxxxx> wrote:
> 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?
unload_add_on() first invokes static destructors in the add-on, which could
be a point where application code messes things up.
exit_thread() first calls thread exit callbacks (cf. on_exit_thread()). I.e.
if an exit callback is registered that accesses the looper, it will indeed
make a difference where exit_thread() is called. That would be a problem in
the callback respectively the code installing it, though.
There's also a good synergy for crashes between the two calls. E.g. if you
register a thread exit callback that is located in the add-on and unload the
add-on before the thread exits, exiting the thread afterwards will jump to
code that isn't there anymore.
At any rate the stack trace and some info on when unload_add_on() is called
should help tracking this down.
> I could not find the unload_add_on implementation, will it end up in
> runtime_loader/elf/unload_library ?
unload_add_on() is implemented in src/system/libroot/os/image.cpp. It only
calls the runtime loader, though (cf. src/system/runtime_loader/export.c).
> 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.
Nope, not at all. And manually free()ing the memory for the BLooper object
is just as ugly.
> > 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. :)
Yeah, fRunCalled is a bit misnamed, I suppose. Other parts of the
implementation use it as an indicator whether the thread has been started.
> 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.
Nice. :-)
CU, Ingo
Other related posts:
