chart demo crashes when moved around

[the ringmaster]

How to reproduce:

This is recreated by setting the animation to fast movement, setting the display to directwindow and selecting two threads. You then move the window around the screen (especially to areas beyond the screen) and the app will crash.

Experienced behavior:

Application crashes

Expected behavior:

Application redraws nicely.

[thorn]

I can reproduce this

backtrace:

This GDB was configured as "i586-pc-haiku"...(no debugging symbols found)
Thread 172 caused an exception: Segment violation
.. . . .
[Switching to team /boot/beos/demos/Chart (167) thread chart animation (172)]
0x00208717 in EraseStar ()
(gdb) bt
#0  0x00208717 in EraseStar ()
#1  0x0020883a in RefreshStarPacket ()
#2  0x002142a8 in ChartWindow::RefreshStars ()
#3  0x002125f0 in ChartWindow::Animation ()
#4  0x0049d548 in thread_entry () from /boot/beos/system/lib/libroot.so
#5  0x70080fec in ?? ()
   

[jackburton]

Looks like the visible region passed to BDirectWindow from the app_server doesn't take into account the fact that the window is off screen.

[stippi]

It probably does, but I am suspecting a synchronization bug in this code. It is probably the same reason why BDirectWindows sometimes draw over other windows.

[jackburton]

Replying to stippi:

It probably does, but I am suspecting a synchronization bug in this code. It is probably the same reason why BDirectWindows sometimes draw over other windows.

Does it ever happen ? I thought it happened only with BGLView in direct mode (which is a slightly different test case)

[the ringmaster]

This is still a problem. I just tried to reproduce this and I got a crash. This happened without the "2 Threads" checked. With it checked the stars just stop moving.

[the ringmaster]

New Crash - 10/06/2008

[jackburton]

Can anyone check if our Chart crashes on R5 too ?

[aldeck]

Hmm this backtrace looks like there's another victim of #2956 or whatever causes it :)

[aldeck]

Can reproduce here hrev28361 real hw, 2 cpus. Happens only with DirectWindow rendering. If the window overlaps the right end of the screen, it draws black pixels on the left of the screen. If the window overlaps the bottom end, it crashes, with the same backtrace as in the first comment. I had to find the crashed thread with kdl (due to #2956), see attached file.

[jackburton]

I asked if it happens on hrev5 too, because this could be a bug in Chart itself, since other BDirectWindow based test apps don't crash nor misbehave (GLTeapot, DirectGLTest). If Chart clipping code is buggy (doesn't respect the window bounds, or it doesn't check if the window is out of screen) it will crash. On other hand, this could be a problem of our BDirectWindow implementatation (or better said, of the server side part, where it could pass invalid/incorrect data).

[aldeck]

You're right, but i can't test on hrev5 at the moment, it would be nice if someone else can check.

As for other BDirectWindow based apps, well some misbehave, i just created a new ticket for GLTeapot/GLDirectTest, as there's a new crash by moving the window (not sure at all it's related though). see #3001

[jackburton]

Then could be that the problem is in the lib/server, and not in the app, and then #3001 would be a dup of this one. Unfortunately I can't test on hrev5 at the moment either. I tried to track down this once, but testing on hrev5 would make this much easier, as you could see how the passed data would look like, when the window is out of the screen bounds.

[jackburton]

After some debugging, I found out that the app is killed by the app_server. More specifically, what happens is that, when the window is moved beyond the left bound of the visible screen, Chart (but also the DirectWindowTest application, based on Stars) blocks inside DirectConnected(), so the app_server, which is waiting on a semaphore with a timeout (cf. ServerWindow::HandleDirectConnection()), kills the app. Since these applications just do some calculations inside DirectConnected, why this is happening is beyond me.

[jackburton]

Fixed in hrev32392.