Opened 16 months ago

Last modified 6 days ago

#13191 assigned bug

[Flurry] screensaver crashes in __strtod_internal

Reported by: diver Owned by: Alexander von Gluck
Priority: normal Milestone: Unscheduled
Component: Add-Ons/Screen Savers Version: R1/Development
Keywords: Cc: Alexander von Gluck
Blocked By: Blocking: #14023
Has a Patch: no Platform: x86-64

Description

hrev50849 x86_64.

Selecting Flurry screensaver crashes ScreenSaver preflet.

Not reproducible in x86_gcc2.

Attachments (7)

ScreenSaver-9243-debug-10-01-2017-18-16-42.report (20.7 KB) - added by diver 16 months ago.
ScreenSaver-788-debug-16-01-2017-19-04-05.report (19.4 KB) - added by Premislaus 15 months ago.
Another crash report.
0001-Ensure-screen-savers-have-an-active-GL-context.patch (1.9 KB) - added by Andrew Aldridge 4 months ago.
GLInfo-647-debug-14-04-2018-14-20-17.report (25.3 KB) - added by cocobean 11 days ago.
GLInfo crash on exit
ScreenSaver-858-debug-14-04-2018-14-23-28.report (24.5 KB) - added by cocobean 11 days ago.
Flurry crash on hrev51877 x86_64
syslog (153.5 KB) - added by cocobean 11 days ago.
Syslog after crashes hrev51877 x86_64
haiku_flurry_x64.jpeg (225.7 KB) - added by cocobean 8 days ago.
Haiku hrev49856 x86_64 w/Mesa 10.5.2 working properly with GLife, GL Info, and Flurry.

Download all attachments as: .zip

Change History (26)

comment:1 Changed 16 months ago by diver

Owner: changed from Nobody to Alexander von Gluck
Status: newassigned

Changed 15 months ago by Premislaus

Another crash report.

comment:2 Changed 4 months ago by Andrew Aldridge

This is because the FlurryView::AttachedToWindow() logic looks like the following:

void FlurryView::AttachedToWindow() {
  LockGL();
  BGLView::AttachedToWindow(); // Calls UnlockGL()
  // Do stuff assuming a context is active
}

When glGetString(GL_VERSION) is called, it returns a null string. The GLife screensaver has the same problem, but instead of crashing it just renders incorrectly.

For both Flurry and GLife, moving the LockGL call *after* the call to BGLView::AttachedToWindow fixes the problem.

I'll try to create a patch tomorrow.

Changed 4 months ago by Andrew Aldridge

comment:3 Changed 4 months ago by Andrew Aldridge

Has a Patch: set

comment:4 Changed 4 months ago by Andrew Aldridge

(Maybe BGLView::AttachedToWindow() shouldn't unconditionally unlock the GL context; I can persue that route instead if it's preferable)

comment:5 Changed 4 months ago by waddlesplash

What did BeOS do re. locking? We should try to mimic that.

comment:6 Changed 4 months ago by Andrew Aldridge

The BeBook seems to indicate that the existing behavior of the screensavers should be correct, meaning my patch should be rejected. The current BGLView::AttachedToWindow() locking logic was added to Haiku in fafc6e4b776ba7c9eff20696976d9fdb85113682 (2010) without explanation.

There are two options I can see:

  • Revert that part of the change, making Haiku match BeOS more closely based on the BeBook's code samples, but breaking applications written to depend on Haiku's current behavior.
  • Only call UnlockGL() iff the initial state of BGLView::fDisplayLocker::IsLocked() is false. That is, restore the original state right after setting up the glViewport.

I'll pursue the second option as a pull request to the mesa package in haikuports, if that's the right procedure?

comment:7 Changed 4 months ago by Andrew Aldridge

Has a Patch: unset

comment:8 Changed 4 months ago by waddlesplash

Cc: Alexander von Gluck added

CC'ing kallisti5 as he's in charge of Mesa-related stuff.

Yes, that's probably correct. Note that there are 2 versions of Mesa though (Mesa 7 for GCC2 and current Mesa for GCC5+) and both will need to be patched I think.

comment:9 Changed 4 months ago by PulkoMandy

Aren't LockGL() and UnlockGL() recursive locks? (sorry, I'm not familiar with the API)

If they are, then there should be no problem here - AttachedToWindow could safely call LockGL then UnlockGL which would restore the initial state of the lock.

A patch was submitted here: https://github.com/haikuports/haikuports/pull/2070/files Submitting directly to github.com/haiku/mesa (for gcc2) and upstream mesa (for gcc5) would be better than having the patch in haikuports.

comment:10 Changed 4 months ago by Andrew Aldridge

LockGL() and UnlockGL() currently don't behave recursively. I think they probably should?

I appreciate everybody taking the time to help me muddle my way through what a proper fix for this looks like :D

comment:11 Changed 4 months ago by waddlesplash

The Be Book does not specify whether or not they are recursive. Guess someone needs to fire up BeOS and find out...

comment:12 Changed 4 months ago by PulkoMandy

Let's dig out that BeOS machine. Maybe someone has code I could easily test?

comment:13 Changed 7 weeks ago by Skipp_OSX

Blocking: 14023 added

comment:14 Changed 12 days ago by cocobean

Rebuilt Flurry code and tested on hrev51880 x86_64. I can confirm this points to the patchset for Mesa 17.1.7 as the culprit. The only other warning is a "_start" symbol resolving from Flurry.

Confirmed the odd default misrendering with GLife (although GLTeapots rendering looks fine). Mesa 7.9 x86 renders those screensavers fine on Haiku x86. Didn't test Mesa 17.1 on Haiku x86 nor Mesa 7.9 on x86_64.

I can assist work on a 'clean room' Mesa 17.1.10 re-implementation for Haiku - if we all come to the same conclusions.

Last edited 10 days ago by cocobean (previous) (diff)

comment:15 Changed 12 days ago by Alexander von Gluck

The core problem is people keep bumping the version of Mesa in our Haikuports repository without testing if it actually works. Mesa 12-15 were stable, but without the bandwith to work on it bugs creep in.

I've been trying to keep up, but real life and all the other Haiku work I have get in the way.

The SCons build system we use in Mesa is slowly being decommissioned. I've added Haiku support to their new Meson build system... but haven't had time to track down all the bugs.

Help wanted!

And *please* don't start talking of forking Mesa. The project moves fast... lets just not bump versions until we know that the version we bump to is stable + functional :-)

comment:16 Changed 12 days ago by PulkoMandy

We need a release branch at haikuports and not let random people push/merge changes to it; at least for packages required for Haiku to run.

comment:17 Changed 12 days ago by cocobean

Last edited 11 days ago by cocobean (previous) (diff)

comment:18 Changed 11 days ago by cocobean

Issue (Haiku hrev51877, Mesa 17.1.7-7): GLinfo - Segmentation fault on exit with Mesa 17.1.7, GLife - Misrendering (cubes larger than normal), Flurry - fails to start properly.

Note: haiku hrev51880 x86 - Mesa 7.9.2 works and renders fine (i.e. good enough).

This Mesa 17.0.7 setup renders fine with Flurry on Linux:

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV710 (DRM 2.49.0 / 4.10.0-38-generic, LLVM 4.0.0)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.0.7
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.0.7
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.0.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

On Haiku hrev51877 x86_64 with radeon_hd driver and Mesa 17.1.7-7:

Gallium 0.4 on llvmpipe (LLVM 5.0, 128 bits)
VMware Inc.
3.0 Mesa 17.1.7
GLU 1.3, GLU 1.5
Last edited 7 days ago by cocobean (previous) (diff)

Changed 11 days ago by cocobean

GLInfo crash on exit

Changed 11 days ago by cocobean

Flurry crash on hrev51877 x86_64

Changed 11 days ago by cocobean

Attachment: syslog added

Syslog after crashes hrev51877 x86_64

comment:19 Changed 8 days ago by cocobean

See attachment: https://dev.haiku-os.org/attachment/ticket/13191/haiku_flurry_x64.jpeg

Confirming that GLife, GL Info, and Flurry all work, exit, and render properly on Haiku hrev49856 x86_64:

Software Rasterizer
Mesa Project
2.1 Mesa 10.5.2
GLU 1.3, GLU 1.5

Note: A user also confirmed that Haiku x86_64 hrev51173 with mesa_swpipe 17.0.2-2 works.

IMPORTANT: The current nightly ISO x86_64 image builds have the issue.

Last edited 6 days ago by cocobean (previous) (diff)

Changed 8 days ago by cocobean

Attachment: haiku_flurry_x64.jpeg added

Haiku hrev49856 x86_64 w/Mesa 10.5.2 working properly with GLife, GL Info, and Flurry.

Note: See TracTickets for help on using tickets.