Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#9685 closed bug (fixed)

OpenGL apps crashes

Reported by: Giova84 Owned by: kallisti5
Priority: high Milestone: R1/beta1
Component: Kits/OpenGL Kit Version: R1/Development
Keywords: opengl applications crash error Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

hrev45525 If i launch GLTeapot or any other app which use OpenGL (eg the game BillardGL or Quake II) i always got an error. Files attached: crash report of BillardGL, GLTeapot and the part of syslog related to error.

Attachments (4)

syslog.txt (4.7 KB) - added by Giova84 6 years ago.
BillardGL-1652-debug-18-04-2013-23-55-14.report (15.4 KB) - added by Giova84 6 years ago.
GLTeapot-1475-debug-18-04-2013-23-53-14.report (14.8 KB) - added by Giova84 6 years ago.
execmem.c (3.9 KB) - added by kallisti5 6 years ago.
first shot at a fix

Download all attachments as: .zip

Change History (44)

Changed 6 years ago by Giova84

Attachment: syslog.txt added

Changed 6 years ago by Giova84

comment:1 Changed 6 years ago by umccullough

Does it happen on revs prior to hrev45518?

Curious if this is related to the new ASLR enhancements.

comment:2 Changed 6 years ago by Giova84

Hi, i've tried with hrev45516 and OpenGL applications works fine.

comment:3 Changed 6 years ago by pdziepak

KERN: vm_page_fault: thread "BillardGL" (1625) in team "BillardGL" (1625) tried to execute address 0x3d2d5e8, ip 0x3d2d5e8 ("heap" +0x415e8)

Mesa attempts to execute a code that is placed on the heap without explicitly setting area protection to executable. The best solution would be probably to fix Mesa so that it creates a new area for this (apparently generated) code with both write and execute flags.

Making the whole heap executable would undoubtedly also fix this problem but that's certainly not a nice solution.

comment:4 Changed 6 years ago by phoudoin

Question is does we have an userland API to create an executable area!? Which, ironically, will make all this ASLR & co security effort quite pointless...

comment:5 in reply to:  4 Changed 6 years ago by bonefish

Replying to phoudoin:

Question is does we have an userland API to create an executable area!?

The B_EXECUTE_AREA flag for create_area() and friends is currently private (though we should change that eventually). However, the <sys/mman.h> API already allows creation of/changing protection to executable memory ranges.

Which, ironically, will make all this ASLR & co security effort quite pointless...

Well, that's a bit exaggerated. It is certainly thinkable that the API is used in an attack vector, but using it is made significantly more difficult due to DEP and ASLR.

comment:6 Changed 6 years ago by phoudoin

Agreed, I was a bit exaggerating.

Anyway, AFAICT, something should be done in Mesa's src/mesa/main/execmem.c to add Haiku's support now that we do have DEP... Currently it fallback to use malloc'ed() memory, hence the permission denied when code is running from there...

Last edited 6 years ago by phoudoin (previous) (diff)

comment:7 Changed 6 years ago by kallisti5

Thanks for finding that phoudoin. I've been out of town so I haven't had a chance to look at this.

If you want to give fixing it a try, there is a bep in haikuports for the gcc2 mesa build package. The change needs to occur in the patch in haikuports for mesa 7.8.2.

http://ports.haiku-files.org/browser/haikuports/sys-libs/mesa

Otherwise I can give fixing it a shot this weekend.

comment:8 Changed 6 years ago by kallisti5

If we need to change the upstream Mesa (Mesa-9.2-dev, gcc4) as well for this, I can commit the change to Mesa mainline once we have a solution.

comment:9 Changed 6 years ago by diver

Interestingly, OpenGL apps work ok in vbox.

comment:10 Changed 6 years ago by anevilyak

This problem would only occur if NX is available/enabled, which might not be the case for whatever CPU vbox emulates in your case.

comment:11 Changed 6 years ago by kallisti5

Priority: normalhigh

Looking into this now. Bumping the priority up as it breaks the OpenGL Kit which should be considered a core OS feature.

Changed 6 years ago by kallisti5

Attachment: execmem.c added

first shot at a fix

comment:12 Changed 6 years ago by kallisti5

attached is my first go at execmem.c. I haven't tested it (or even tried compiling it yet) but wanted to get it somewhere public. I plan on testing this tonight.

comment:13 Changed 6 years ago by bonefish

Is there a particular reason not to use the Linux/*BSD/... code in the first place? I don't know about the other mesa interfaces it uses, but the only system dependency in there seems to be the mmap() call, which should work just fine on Haiku.

comment:14 in reply to:  13 Changed 6 years ago by umccullough

Replying to bonefish:

Is there a particular reason not to use the Linux/*BSD/... code in the first place? I don't know about the other mesa interfaces it uses, but the only system dependency in there seems to be the mmap() call, which should work just fine on Haiku.

Amusingly, we had that same discussion in IRC earlier - and came to the same conclusin :)

comment:15 Changed 6 years ago by kallisti5

mmap used to result in crashes when I first ported Mesa 7.8.2, it seems to work now 100%. I updated the Mesa 7.8.2 haikuports patch to use mmap. (https://bitbucket.org/haikuports/haikuports/commits/a66ef90360d59d72034fb86af336ed50da9bdc84)

I also pushed up an updated gcc2 package and updated the BuildFeatures (hrev45555)

This still needs done for gcc4 so I'm leaving the issue open.

Last edited 6 years ago by kallisti5 (previous) (diff)

comment:16 Changed 6 years ago by Giova84

Hi Kallisti, great work! But i have noticed a thing. I have just upgraded to hrev45555. But i have found that OpenGL apps are slower than before! If i start GLTeapot on hrev45555 i can see a max fps of 290-300, and if i run GLTeapot on Alpha 4.1 and on hrev45516 i can see a max FPS of 400-450. Obviously on the same computer.

comment:17 Changed 6 years ago by Giova84

if i start GLTeapot from a Terminal window, i can read:

Ϟ 14:03:32 Ϟ ~ /boot/home/config/settings/deskbar/Demos/GLTeapot
Mesa: CPU vendor: GenuineIntel
Mesa: CPU name: Pentium(R) Dual-Core  CPU      E5300  @ 2.60GHz
Mesa: Mesa 7.8.2 DEBUG build Apr 24 2013 20:39:02
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
Mesa: MMX cpu detected.
Mesa: SSE cpu detected.
Mesa: Not testing OS support for SSE, leaving enabled.
Ϟ 14:03:45 Ϟ ~

Instead if i start GLTeapot in a Terminal window under Alpha 4.1 there is no output. Maybe is related to debug? p.s: intel_extreme driver is used on an Intel G45 videocard.

comment:18 Changed 6 years ago by Giova84

Sorry for the noise :-) With hrev45555 i am no longer able to run Quake II. syslog:

KERN: instruction fetch attempted on execute-protected area 0x5162 at 0x0234b000
KERN: vm_page_fault: vm_soft_fault returned error 'Permission denied' on fault at 0x234b735, ip 0x234b735, write 0, user 1, thread 0x32c
KERN: vm_page_fault: thread "Quake_Run" (812) in team "Quake2" (806) tried to execute address 0x234b735, ip 0x234b735 ("ref_soft.so_seg0ro" +0x17735)
KERN: debug_server: Thread 812 entered the debugger: Segment violation
KERN: stack trace, current PC 0x234b735  Sys_MakeCodeWriteable + 0x15:
KERN:   (0x45bc914)  0x74666f73  
KERN: vm_soft_fault: va 0x5f666000 not covered by area in address space
KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x5f666572, ip 0x8012546b, write 0, user 0, thread 0x32d
KERN: debug_server: Killing team 806 (/boot/apps/Quake2/Quake2)
KERN: debug_server: TeamDebugHandler::Init(): Failed to get info for team 806: Operation on invalid team
KERN: debug_server: KillTeam(): Error getting info for team 806: Operation on invalid team
KERN: debug_server: Killing team 806 ()
USER: application/x-vnd.id-Quake killed for a problem in DirectConnected(): Operation timed out
KERN: bfs: bfs_stat_index:2118: No such file or directory
Last message repeated 1 time
KERN: Last message repeated 2 times.
USER: application/x-glut-demo killed for a problem in DirectConnected(): Operation timed out
KERN: slab memory manager: created area 0xf1001000 (21615)
KERN: libnetwork.so running in R5 compatibility mode.
KERN: instruction fetch attempted on execute-protected area 0x54ca at 0x0214f000
KERN: vm_page_fault: vm_soft_fault returned error 'Permission denied' on fault at 0x214f735, ip 0x214f735, write 0, user 1, thread 0x38b
KERN: vm_page_fault: thread "Quake_Run" (907) in team "Quake2" (901) tried to execute address 0x214f735, ip 0x214f735 ("ref_soft.so_seg0ro" +0x17735)
KERN: debug_server: Thread 907 entered the debugger: Segment violation
KERN: stack trace, current PC 0x214f735  Sys_MakeCodeWriteable + 0x15:
KERN:   (0x41cb914)  0x74666f73  
KERN: vm_soft_fault: va 0x5f666000 not covered by area in address space
KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x5f666572, ip 0x8012546b, write 0, user 0, thread 0x38c
KERN: debug_server: Killing team 901 (/boot/apps/Quake2/Quake2)
KERN: debug_server: TeamDebugHandler::Init(): Failed to get info for team 901: Operation on invalid team
KERN: debug_server: KillTeam(): Error getting info for team 901: Operation on invalid team
KERN: debug_server: Killing team 901 ()
USER: application/x-vnd.id-Quake killed for a problem in DirectConnected(): Operation timed out
KERN: libnetwork.so running in R5 compatibility mode.
KERN: instruction fetch attempted on execute-protected area 0x58d4 at 0x00dd1000
KERN: vm_page_fault: vm_soft_fault returned error 'Permission denied' on fault at 0xdd1735, ip 0xdd1735, write 0, user 1, thread 0x3b5
KERN: vm_page_fault: thread "Quake_Run" (949) in team "Quake2" (943) tried to execute address 0xdd1735, ip 0xdd1735 ("ref_soft.so_seg0ro" +0x17735)
KERN: debug_server: Thread 949 entered the debugger: Segment violation
KERN: stack trace, current PC 0xdd1735  Sys_MakeCodeWriteable + 0x15:
KERN:   (0x53f1914)  0x74666f73  
KERN: vm_soft_fault: va 0x5f666000 not covered by area in address space
KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x5f666572, ip 0x8012546b, write 0, user 0, thread 0x3b6
KERN: debug_server: Killing team 943 (/boot/apps/Quake2/Quake2)
KERN: debug_server: TeamDebugHandler::Init(): Failed to get info for team 943: Operation on invalid team
KERN: debug_server: KillTeam(): Error getting info for team 943: Operation on invalid team
KERN: debug_server: Killing team 943 ()
USER: application/x-vnd.id-Quake killed for a problem in DirectConnected(): Operation timed out

comment:19 in reply to:  17 Changed 6 years ago by phoudoin

Mesa: Mesa 7.8.2 DEBUG build Apr 24 2013 20:39:02

Seems like Mesa 7.8.2 package was built with DEBUG turn on, which could explain the running performance difference.

comment:20 Changed 6 years ago by Giova84

Ok. And DEBUG turned on is necessary or could be disabled? :-)

comment:21 Changed 6 years ago by kallisti5

odd.. I had DEBUG disabled in the new package build.

https://bitbucket.org/haikuports/haikuports/src/a66ef90360d59d72034fb86af336ed50da9bdc84/sys-libs/mesa/mesa-7.8.2.bep?at=master

Maybe the older Mesa DEBUG check is a #if defined vs an #if. I'll look into it this evening.

comment:22 Changed 6 years ago by phoudoin

I plead guilty: config/beos is broken regarding DEBUG env variable. It doesn't check its value and assume its existence means it's enabled.

comment:23 Changed 6 years ago by kallisti5

The gcc4 Mesa 9.1.1 package was updated with this change as well in hrev45560 + https://bitbucket.org/haikuports/haikuports/commits/8a55428

I have a patch submitted to Mesa mainline and will commit it if no-one pushes back, it may not make it in until Mesa 9.2 or later however.

I'm still leaving this issue open to rebuild / fix the Mesa 7.8.2 DEBUG stuff and to ensure the patch gets accepted upstream.

comment:24 Changed 6 years ago by Giova84

Hi Kallisti,

Some info about this issue https://dev.haiku-os.org/ticket/9685#comment:18 ?

comment:25 Changed 6 years ago by kallisti5

@Giova84

Will fix once I get a little free time to do the work :)

comment:26 Changed 6 years ago by kallisti5

Milestone: R1R1/beta1
Resolution: fixed
Status: newclosed

https://bitbucket.org/haikuports/haikuports/commits/644976f should fix the debug issue.

hrev45581 updated the Mesa package

Should be resolved now, feel free to reopen this if you still see problems.

comment:27 Changed 6 years ago by Giova84

Hi Kallisti, well done! Now OpenGL apps work ok at full performance! But Quake II still crash as before:

KERN: instruction fetch attempted on execute-protected area 0x5162 at 0x0234b000
KERN: vm_page_fault: vm_soft_fault returned error 'Permission denied' on fault at 0x234b735, ip 0x234b735, write 0, user 1, thread 0x32c
KERN: vm_page_fault: thread "Quake_Run" (812) in team "Quake2" (806) tried to execute address 0x234b735, ip 0x234b735 ("ref_soft.so_seg0ro" +0x17735)
KERN: debug_server: Thread 812 entered the debugger: Segment violation
KERN: stack trace, current PC 0x234b735  Sys_MakeCodeWriteable + 0x15:
KERN:   (0x45bc914)  0x74666f73  
KERN: vm_soft_fault: va 0x5f666000 not covered by area in address space
KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x5f666572, ip 0x8012546b, write 0, user 0, thread 0x32d
KERN: debug_server: Killing team 806 (/boot/apps/Quake2/Quake2)
KERN: debug_server: TeamDebugHandler::Init(): Failed to get info for team 806: Operation on invalid team
KERN: debug_server: KillTeam(): Error getting info for team 806: Operation on invalid team
KERN: debug_server: Killing team 806 ()
USER: application/x-vnd.id-Quake killed for a problem in DirectConnected(): Operation timed out
KERN: bfs: bfs_stat_index:2118: No such file or directory
Last message repeated 1 time
KERN: Last message repeated 2 times.
USER: application/x-glut-demo killed for a problem in DirectConnected(): Operation timed out
KERN: slab memory manager: created area 0xf1001000 (21615)
KERN: libnetwork.so running in R5 compatibility mode.
KERN: instruction fetch attempted on execute-protected area 0x54ca at 0x0214f000
KERN: vm_page_fault: vm_soft_fault returned error 'Permission denied' on fault at 0x214f735, ip 0x214f735, write 0, user 1, thread 0x38b
KERN: vm_page_fault: thread "Quake_Run" (907) in team "Quake2" (901) tried to execute address 0x214f735, ip 0x214f735 ("ref_soft.so_seg0ro" +0x17735)
KERN: debug_server: Thread 907 entered the debugger: Segment violation
KERN: stack trace, current PC 0x214f735  Sys_MakeCodeWriteable + 0x15:
KERN:   (0x41cb914)  0x74666f73  
KERN: vm_soft_fault: va 0x5f666000 not covered by area in address space
KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x5f666572, ip 0x8012546b, write 0, user 0, thread 0x38c
KERN: debug_server: Killing team 901 (/boot/apps/Quake2/Quake2)
KERN: debug_server: TeamDebugHandler::Init(): Failed to get info for team 901: Operation on invalid team
KERN: debug_server: KillTeam(): Error getting info for team 901: Operation on invalid team
KERN: debug_server: Killing team 901 ()
USER: application/x-vnd.id-Quake killed for a problem in DirectConnected(): Operation timed out
KERN: libnetwork.so running in R5 compatibility mode.
KERN: instruction fetch attempted on execute-protected area 0x58d4 at 0x00dd1000
KERN: vm_page_fault: vm_soft_fault returned error 'Permission denied' on fault at 0xdd1735, ip 0xdd1735, write 0, user 1, thread 0x3b5
KERN: vm_page_fault: thread "Quake_Run" (949) in team "Quake2" (943) tried to execute address 0xdd1735, ip 0xdd1735 ("ref_soft.so_seg0ro" +0x17735)
KERN: debug_server: Thread 949 entered the debugger: Segment violation
KERN: stack trace, current PC 0xdd1735  Sys_MakeCodeWriteable + 0x15:
KERN:   (0x53f1914)  0x74666f73  
KERN: vm_soft_fault: va 0x5f666000 not covered by area in address space
KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x5f666572, ip 0x8012546b, write 0, user 0, thread 0x3b6
KERN: debug_server: Killing team 943 (/boot/apps/Quake2/Quake2)
KERN: debug_server: TeamDebugHandler::Init(): Failed to get info for team 943: Operation on invalid team
KERN: debug_server: KillTeam(): Error getting info for team 943: Operation on invalid team
KERN: debug_server: Killing team 943 ()
USER: application/x-vnd.id-Quake killed for a problem in DirectConnected(): Operation timed out

comment:28 in reply to:  27 ; Changed 6 years ago by phoudoin

Replying to Giova84:

Hi Kallisti, well done! Now OpenGL apps work ok at full performance! But Quake II still crash as before:

Well, as it doesn't seems to be due to OpenGL kit but to what is done (or not done yet) in Haiku/BeOS port of Quake 2's Sys_MakeCodeWriteable() function.

On other ports, it's calling mprotect() AFAICT. Could you give us from where did you get the Quake2 port crashing here, so one try to follow the lead to the port source code? Thanks.

PS: as it doesn't due to OpenGL Kit, Quake2 being a third party app, maybe this ticket should be closed anyway.

comment:29 Changed 6 years ago by anevilyak

Indeed, that part's simply Quake II needing to be adapted to a DEP world.

comment:30 in reply to:  28 Changed 6 years ago by Giova84

Replying to phoudoin:

Well, as it doesn't seems to be due to OpenGL kit but to what is done (or not done yet) in Haiku/BeOS port of Quake 2's Sys_MakeCodeWriteable() function.

On other ports, it's calling mprotect() AFAICT. Could you give us from where did you get the Quake2 port crashing here, so one try to follow the lead to the port source code? Thanks.

Quake II is available here: http://haikuware.com/directory/view-details/games/3d/quakeii And until 2 months ago i was able to properly start Quake II on Haiku, so this issue could be related to a recent change in some place of Haiku.

comment:31 Changed 6 years ago by anevilyak

Yes, it's because we now enable hardware DEP on CPUs that support it. Consequently if the app wants to generate code to execute on the fly, it needs to map the area containing that code as executable or the CPU won't allow it.

comment:32 Changed 6 years ago by Giova84

Thank you for the explanation, anevilyak! So, for this issue, should i open a new ticket?

comment:33 Changed 6 years ago by anevilyak

If Quake II has a bugtracker, sure. Since it's a third party app, the Haiku bug tracker however isn't the place to be filing tickets against it.

comment:34 in reply to:  28 Changed 6 years ago by Giova84

After a quick search on Google, seems that a bug tracker for Quake II isn't available.

In anyway, for reply to phoudoin:

Replying to phoudoin:

Could you give us from where did you get the Quake2 port crashing here, so one try to follow the lead to the port source code? Thanks.

Seems that the source code is available here: https://github.com/id-Software/Quake-2 shouldn't be too hard port it again on Haiku?

comment:35 Changed 6 years ago by kallisti5

Giova84: It shouldn't be too hard to port again if the code exists. If you want some Haiku programming experience, making a github fork and trying to port it may be good practice :)

Otherwise you'll need to try and talk someone into porting it.

For what it's worth, I re-ported quake3 a while back: https://github.com/kallisti5/quake3

It doesn't run very quickly unless your running the gcc4 image + llvmpipe opengl renderer (which is broken atm, but i'm actively trying to fix that)

comment:36 in reply to:  31 Changed 6 years ago by jackburton

Replying to anevilyak:

Yes, it's because we now enable hardware DEP on CPUs that support it. Consequently if the app wants to generate code to execute on the fly, it needs to map the area containing that code as executable or the CPU won't allow it.

Would be possible to enable or disable DEP selectively by application ? Windows can do this, and can be useful in many cases.

comment:37 Changed 6 years ago by pdziepak

The problem with Quake II is that the runtime loader correctly sets ref_soft.so_seg0ro protection to read and execute but then Quake II sets its protection to read and write (i.e. in an attempt to make it writable it makes it non-executable).

Disabling DEP might indeed be a good solution. Since we have the comfort of having libroot I do believe the best way to do this would be to set B_EXECUTE_AREA for all areas that are created (or have their protection modified) by applications that the runtime loader recognizes as B_HAIKU_ABI_GCC_2_BEOS.

Last edited 6 years ago by pdziepak (previous) (diff)

comment:38 Changed 6 years ago by pdziepak

Just for the record, since hrev45685 DEP is disabled for applications that runtime loader recognizes as B_HAIKU_ABI_GCC_2_BEOS or B_HAIKU_ABI_GCC_2_ANCIENT. For example, that old port of Quake II should work again.

comment:39 Changed 6 years ago by Giova84

Hi pdziepak. nice to know about this implementation! I will test hrev45685 when available on www.haiku-files.org and i will send you a feedback :-)

comment:40 in reply to:  38 Changed 6 years ago by Giova84

Replying to pdziepak:

old port of Quake II should work again.

I can confirm. Well done!

Note: See TracTickets for help on using tickets.