Opened 9 years ago
Closed 6 years ago
#12726 closed bug (fixed)
[GLife] crashes in _mesa_resize_framebuffer
Reported by: | diver | Owned by: | kallisti5 |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Kits/OpenGL Kit/Software Rasterization | Version: | R1/Development |
Keywords: | Cc: | kallisti5 | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
GLife crashes after walking through the list of screensavers up and down.
Attachments (1)
Change History (10)
by , 9 years ago
Attachment: | ScreenSaver-419-debug-14-04-2016-13-22-53.report added |
---|
comment:1 by , 9 years ago
Component: | Add-Ons/Screen Savers → Kits/OpenGL Kit/Software Rasterization |
---|
comment:3 by , 9 years ago
Yes, for gcc2 we are still using an old Mesa version which has only one rasterizer.
And for gcc4, both renderer are still supported, often you have to try both as they will work or crash in different places, so even there we aren't fully ready to switch to using only the new softpipe.
comment:4 by , 9 years ago
Then why gcc2 only mesa_swrast code was deleted from Mesa source?
comment:6 by , 9 years ago
Cc: | added |
---|
comment:7 by , 9 years ago
The Mesa used for gcc2 is here: https://github.com/haiku/mesa_legacy/commits/7.9 For gcc4 the upstream Mesa repo is used, all our work has been upstreamed.
(or alternatively, TinyGL could be used, but there wasn't much testing of this so I wouldn't recommend it)
comment:8 by , 9 years ago
Thanks. I guess somewhere a sub object is not allocated due to initial width and height being zeros but when it's resized _mesa_resize_framebuffer try to deference renderbuffer which were never allocated in the first place.
Will try to spot where and why.
comment:9 by , 6 years ago
GLife/Mesa 17.1.10-2 x86_64 and Mesa 7.9.2-11 gcc2 passed with no crash issues with screensavers.
comment:10 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Seems to be with the old mesa_swrast OpenGL renderer, which is not anymore used. Could you check if using mesa_swpipe OpenGL renderer trigger the same issue ?
Check with GLInfo the default renderer is now LLVM swpipe.