[haiku-appserver] Re: some help please
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Mon, 19 Sep 2005 01:14:08 +0200
On 2005-09-19 at 00:53:54 [+0200], Adi Oanca wrote:
> Adi Oanca wrote:
> > Now, how to reproduce:
> > - take main.cpp and link against our libbe.so (I use R5, so
> > libopenbeos.so)
> > - run the server, run the app.
> > - move (quickly) the floating window around.
> > (if you are not able to reproduce this, I will submit the WIP that I
> > have related to input stuff, and when this is enabled by a define in
> > Layer.h, it crashes a lot more often)
> >
> > NOTE: I'm using GeekGadgets' compiler. (never had a problem with it)
>
> I tried Oliver Tappe's compiler and something funny is happening.
> When I compile with:
> $ jam haiku_app_server
> and run the test, the bug won't appear anymore. I tried this several
> times but the debugger has not been called. So, thank you Oliver.
>
> However, when compiling with:
> $DEBUG=1 jam haiku_app_server
> the bug appears immediately.
>
> I'm guessing this is a compiler problem. What do you think? Should we
> mail Oliver? Has anyone reproduced this bug? (to reproduce faster,
> activate NEW_INPUT_HANDLING)
I haven't tried yet, but getting different behavior when compiling with and
without optimization is often a sign of using uninitialized
variables/memory. In my experience when running an executable compiled with
debugging, uninitialized stuff is often zero'd out, while it may contain
arbitrary values otherwise.
Anyway, I'll try to reproduce your problem now, although I won't promise
anything, since I had a couple White Russians this evening ("election
party" :-).
CU, Ingo
PS: Please use Oliver's gcc. Even if you personally haven't had problems
with the GG version, there are proven examples where things go wrong. IIRC
it doesn't compile the kernel utils unit tests. Though that's a relatively
harmless problem. There are cases where optimization > -O1 simply produces
incorrect code.
Other related posts:
