[haiku-development] Re: BeOS Apps Crashing on Haiku (Bug #889)
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 31 May 2007 17:31:58 +0200
On 2007-05-31 at 16:55:35 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > Besides ignoring the problem I see the following possible solutions:
> >
> > 1) Modify our runtime loader to use the same symbol resolution
> > strategy as
> > Be's. This should fix the problem for all executables (running on
> > BeOS)
> > that suffer from it. As mentioned before, I believe, our current
> > runtime
> > loader behavior is more correct, though.
> >
> > 2) Modify the gcc type info functions to use the type_info returned
> > by the
> > base class type info function instead of resolving it separately.
> > This
> > makes sure the type_info used has been initialized. The change should
> > fix
> > e.g. the file panel problem several of the Be applications have, but
> > --
> > since we only correct the type info functions in our code -- it might
> > not
> > fix all instances of the problem.
> >
> > Opinions?
>
> Nice problem we ran into there :-)
> I would actually think it would be best to implement both options; 1)
> because it'll definitely solve the problem and makes us compatible with
> BeOS - we could make the change a compiler option
Come to think of it, if the loader was able to find out what compiler has
generated the shared objects involved, it could even decide live what
strategy to use.
> - and 2) because it's
> more elegant, anyway :-)
Definitely.
> Also, what about the thread safety problem in the initialization? Is
> that easily solvable? And if not, what could happen in the worst case?
In the worst case the application will crash. It's an extremely unlikely
race condition though: Two threads have to decide to call a type info
function that hasn't been called before at the same time, and the earlier
thread needs to make use of the type_info before the other thread finishes
its initialization. The critical section for a __si_type_info is only about
10 instructions long.
Initialization of function local static variables suffers from the same
problem, BTW. No idea how complex it is to solve, but I would bother. It
seems to work well enough on BeOS and gcc 4 takes care of that anyway.
CU, Ingo
Other related posts:
