[haiku-appserver] Re: some help please

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: