Opened 17 years ago

Closed 15 years ago

#1939 closed bug (fixed)

chart demo crashes when moved around

Reported by: the ringmaster Owned by: jackburton
Priority: normal Milestone: R1
Component: Servers/app_server Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Platform: x86

Description

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.

Attachments (2)

Screenshot-Haiku.png (147.2 KB ) - added by the ringmaster 16 years ago.
New Crash - 10/06/2008
haiku-serial-port_ChartDirectWindow.txt (2.6 KB ) - added by aldeck 16 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 by thorn, 17 years ago

Component: - GeneralApplications
Platform: Allx86

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 ?? ()
   

comment:2 by jackburton, 17 years ago

Component: ApplicationsServers/app_server
Owner: changed from axeld to 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.

comment:3 by stippi, 17 years ago

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.

in reply to:  3 comment:4 by jackburton, 17 years ago

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)

comment:5 by the ringmaster, 16 years ago

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.

by the ringmaster, 16 years ago

Attachment: Screenshot-Haiku.png added

New Crash - 10/06/2008

comment:6 by jackburton, 16 years ago

Can anyone check if our Chart crashes on R5 too ?

comment:7 by aldeck, 16 years ago

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

comment:8 by aldeck, 16 years ago

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.

comment:9 by jackburton, 16 years ago

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).

comment:10 by aldeck, 16 years ago

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

comment:11 by jackburton, 16 years ago

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.

comment:12 by jackburton, 15 years ago

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.

comment:13 by jackburton, 15 years ago

Resolution: fixed
Status: newclosed

Fixed in hrev32392.

Note: See TracTickets for help on using tickets.