OpenGL apps crashes

[Giova84]

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.

[umccullough]

Does it happen on revs prior to hrev45518?

Curious if this is related to the new ASLR enhancements.

[Giova84]

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

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

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

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

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

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

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

[diver]

Interestingly, OpenGL apps work ok in vbox.

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

[kallisti5]

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

[kallisti5]

first shot at a fix

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

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

[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 :)

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

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

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

[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

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

[Giova84]

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

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

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

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

[Giova84]

Hi Kallisti,

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

[kallisti5]

@Giova84

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

[kallisti5]

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

[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

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

[anevilyak]

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

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

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

[Giova84]

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

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

[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?

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

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

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

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

[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 :-)

[Giova84]

Replying to pdziepak:

old port of Quake II should work again.

I can confirm. Well done!