FreeLists / haiku-appserver / [haiku-appserver] Re: some help please

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On 2005-09-18 at 00:31:48 [+0200], Adi Oanca wrote:
> Adi Oanca wrote:
> >>> What happens is, as you can see in Screen1.tga, 'this' pointer is NULL.
> >>> 'this' should've pointed to "RootLayer 1". This is VERY strange as, in
> >>> the previous call, Layer::move_layer(), 'fParent' is valid!
> 
>     Can somebody tell me if at least he can reproduce this bug?

I can. And while I also have seen discrepancies in the stack frames, I 
wouldn't rule out that BDB simply doesn't display the non-innermost stack 
frames correctly. It wouldn't harm to test this under Haiku with gdb, which, 
to my knowledge, does a very good job at that.

That being said, it looks very much like an algorithmical problem in the 
BRegion code, which the failing ASSERT reveals. I haven't dug deep enough 
into the code to understand it completely -- I guess, it's much easier for 
Stefano to have a look -- but what I have understood so far is that 
BRegion::Support::OrRegionComplex() slices the plane into horizontal bands, 
and invokes ROr() for each one. What apparently can happen is, that such a 
band doesn't intersect with any of the rects in the two given regions. Which 
is exactly the case when the ASSERT is violated.

I added a few debug output statements, which produced the following output 
(with comments), which should help to understand the problem:

BRegion::Support::OrRegionComplex(0xfd1c1ebc, 0x803e4700, 0xfd1c1e30)
[entered OrRegionComplex()]
[band finding loops:]
  first.data[0].bottom: 215, top: 215
  second.data[0].bottom: 213, top: 193
  second.data[1].bottom: 215, top: 215

BRegion::Support::ROr(193, 213, 0xfd1c1ebc, 0x803e4700, 0xfd1c1e30, 0, 0)
[ROr() invoked for band: top: 193, bottom: 213]
[rect finding loops:]
  first.data[0].bottom: 215, top: 215
  after first loop: foundCount: 0, indexA: 0
  second.data[0].bottom: 213, top: 193
  second.data[1].bottom: 215, top: 215
  after second loop: foundCount: 1, indexB: 0

[back in OrRegionComplex(), second iteration]
[band finding loops:]
  first.data[0].bottom: 215, top: 215
  second.data[0].bottom: 213, top: 193
  second.data[1].bottom: 215, top: 215

BRegion::Support::ROr(214, 214, 0xfd1c1ebc, 0x803e4700, 0xfd1c1e30, 0, 0)
[ROr() invoked for band: top: 214, bottom: 214]
  first.data[0].bottom: 215, top: 215
  after first loop: foundCount: 0, indexA: 0
  second.data[0].bottom: 213, top: 193
  second.data[1].bottom: 215, top: 215
  after second loop: foundCount: 0, indexB: 1
ASSERT!


The solution would either be to check for empty bands in OrRegionComplex() 
and skip them, or instead of the ASSERT in ROr() simply return in case of 
foundCount == 0 at that point. I tried the latter, and it seems to work well 
enough.

CU, Ingo