Hard Light Productions Forums

General FreeSpace => FreeSpace & FreeSpace Open Support => Topic started by: NedLander on November 04, 2013, 12:20:51 pm

Title: Crash at main hall with intel drivers
Post by: NedLander on November 04, 2013, 12:20:51 pm
Hi all,

Just built a new system, and tried to get FS2 running on it, but I'm getting a segfault at the main hall. This happens in my old (previously working) install folder, and in a clean FS2 install, with 3.7.0 and 3.6.14. The only info I get on the command line is:
"ATTENTION: default value of option force_s3tc_enable overridden by environment.
Segmentation fault"
I'm on openSUSE 13.1 RC1, using the HD 4600 integrated drivers on a 4670K (still waiting on a real graphics card). It looks like these might be the problem, as the gdb backtrace mentions /usr/lib/dri/i965_dri.so. (part of Mesa 9.2.2-61.6.1)
The gdb backtrace and fs2_open.log files are attached. Any help would be appreciated. Thanks!

NedLander

[attachment deleted by ninja]
Title: Re: Crash at main hall with intel drivers
Post by: niffiwan on November 04, 2013, 03:43:20 pm
Here's a couple of things you could try:

1) Do you have "force_s3tc_enable" set in your environment?  If so, try un-setting it before running FSO.

2) When using an Intel GPU you might need to add "-no_glsl" to your command line parameters.
Title: Re: Crash at main hall with intel drivers
Post by: NedLander on November 04, 2013, 04:58:22 pm
Thanks for the reply! I tried both of those things, and am still getting the same problem. Program opens, plays the intro movie, and lets me select a pilot. Then it displays one frame of main hall and instantly crashes with segfault. (It also looks like I don't have 'force_s3tc_enable' set in my env vars if I check the output of 'env'.)
Title: Re: Crash at main hall with intel drivers
Post by: niffiwan on November 04, 2013, 05:52:38 pm
Well, you could maybe try the command line parameter "-nohtl", but that'll probably run very slowly (if at all).  Unfortunately I don't think there's much else that can help right now, FSO tends to have issues with Intel cards due to incomplete/buggy OpenGL support in the drivers.  You might need to wait for that new graphic card :(

BTW - what was the old system that you had where FSO was working?
Title: Re: Crash at main hall with intel drivers
Post by: NedLander on November 04, 2013, 07:13:29 pm
AMD Athlon X2 7850BE with an 8800gt or a GT430 under Nvidia drivers, running openSUSE 12.3. Worked great!  So probably once I get another Nvidia card, that will fix everything...

Another possibility is that my system is 64-bit, but I'm using the 32-bit FSO build. That worked on my previous system, but maybe I should try to compile FSO in 64-bit for this one, rather than using the 32-bit compatibility libraries.
Title: Re: Crash at main hall with intel drivers
Post by: NedLander on November 05, 2013, 09:49:31 pm
niffiwan, I just saw you have openSUSE rpms in your signature, so I just tried the x86_64 build. Same crash, unfortunately. But I think some Intel driver updates are coming soon with Broadwell.

Quote
Program received signal SIGSEGV, Segmentation fault.
0x00007fffeb6b082e in ?? () from /usr/lib64/dri/i965_dri.so
(gdb) bt
#0  0x00007fffeb6b082e in ?? () from /usr/lib64/dri/i965_dri.so
#1  0x00007fffeb19ab36 in _mesa_ReadnPixelsARB () from /usr/lib64/libdricore9.2.2.so.1
Cannot access memory at address 0x7fffffffcf58
Title: Re: Crash at main hall with intel drivers
Post by: niffiwan on November 05, 2013, 10:09:16 pm
If you're feeling really adventurous, you could maybe install the debug packages for the intel driver that you're using and see if they add any more useful info to the backtrace?  But, that'd probably be of most interest to Intel driver developers.  I don't have an Intel card to run any tests with, the desktop has Nvidia, and AMD in my laptop.

Title: Re: Crash at main hall with intel drivers
Post by: NedLander on November 05, 2013, 10:29:08 pm
Actually, just installed some debug packages, so here is a more detailed backtrace:

Quote
    (gdb) run -window -nograb
    Starting program: /data/programs/freespace2/fs2_open_3.7.0_DEBUG_x64 -window -nograb
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib64/libthread_db.so.1".
    Future debug output directed to: /home/nathand/.fs2_open/data/fs2_open.log
    [New Thread 0x7ffff0dfa700 (LWP 25279)]
    [Thread 0x7ffff0dfa700 (LWP 25279) exited]
    [New Thread 0x7ffff0dfa700 (LWP 25280)]
    [New Thread 0x7ffff7f46700 (LWP 25281)]
    [Thread 0x7ffff7f46700 (LWP 25281) exited]
    [Thread 0x7ffff0dfa700 (LWP 25280) exited]
    [New Thread 0x7ffff0dfa700 (LWP 25282)]
    [Thread 0x7ffff0dfa700 (LWP 25282) exited]
    [New Thread 0x7ffff0dfa700 (LWP 25283)]
    [New Thread 0x7ffff7f46700 (LWP 25284)]
    [Thread 0x7ffff7f46700 (LWP 25284) exited]
    [Thread 0x7ffff0dfa700 (LWP 25283) exited]
    [New Thread 0x7ffff0dfa700 (LWP 25285)]
    [Thread 0x7ffff0dfa700 (LWP 25285) exited]
    [New Thread 0x7ffff0dfa700 (LWP 25286)]
    [Thread 0x7ffff0dfa700 (LWP 25286) exited]
    [New Thread 0x7ffff0dfa700 (LWP 25287)]
    [Thread 0x7ffff0dfa700 (LWP 25287) exited]
    [New Thread 0x7ffff0dfa700 (LWP 25288)]
    [New Thread 0x7ffff7f46700 (LWP 25289)]
    [New Thread 0x7fffec574700 (LWP 25290)]
    ATTENTION: default value of option force_s3tc_enable overridden by environment.

    Program received signal SIGSEGV, Segmentation fault.
    0x00007fffeb6b082e in do_blit_readpixels (pixels=0x0, pack=0x25b3b28, type=33639, format=32993, height=1080,
        width=1920, y=0, x=0, ctx=0x25a4a30) at intel_pixel_read.c:94
    94      intel_pixel_read.c: No such file or directory.
    (gdb) bt
    #0  0x00007fffeb6b082e in do_blit_readpixels (pixels=0x0, pack=0x25b3b28, type=33639, format=32993,
        height=1080, width=1920, y=0, x=0, ctx=0x25a4a30) at intel_pixel_read.c:94
    #1  intelReadPixels (ctx=0x25a4a30, x=0, y=0, width=1920, height=1080, format=32993, type=33639,
        pack=0x25b3b28, pixels=0x0) at intel_pixel_read.c:174
    #2  0x00007fffeb19ab36 in _mesa_ReadnPixelsARB (x=0, y=0, width=1920, height=1080, format=32993, type=33639,
        bufSize=bufSize@entry=2147483647, pixels=pixels@entry=0x0) at ../../../src/mesa/main/readpix.c:1042
    #3  0x00007fffeb19ad2a in _mesa_ReadPixels (x=<optimized out>, y=<optimized out>, width=<optimized out>,
        height=<optimized out>, format=<optimized out>, type=<optimized out>, pixels=0x0)
        at ../../../src/mesa/main/readpix.c:1050
    #4  0x00000000004f01f2 in ?? ()
    #5  0x00000000007c0307 in ?? ()
    #6  0x00000000007c0d46 in ?? ()
    #7  0x00000000005dd139 in ?? ()
    #8  0x00000000005c7577 in ?? ()
    #9  0x00000000004da018 in ?? ()
    #10 0x000000000044475a in ?? ()
    #11 0x000000000040d445 in ?? ()
    #12 0x00007ffff5704be5 in __libc_start_main () from /lib64/libc.so.6
    #13 0x0000000000435a19 in ?? ()
Title: Re: Crash at main hall with intel drivers
Post by: el mariachi on December 14, 2013, 01:56:59 pm
I'm having exactly the same issue. Any news on this front? Seems to be the same as: http://www.hard-light.net/forums/index.php?topic=86145.0
Title: Re: Crash at main hall with intel drivers
Post by: NedLander on December 14, 2013, 02:02:27 pm
No updates on my end; I gave up and got an Nvidia card. Works beautifully now, but kind of disappointing, since the Intel graphics probably would have been sufficient had they worked.
Title: Re: Crash at main hall with intel drivers
Post by: el mariachi on December 14, 2013, 02:59:50 pm
FS2 worked on my laptop a year or two ago, can't remember the version. Nothing changed with the laptop, and the GOG.com version works with wine, but I would like to replay some mods again. Oh well...
Title: Re: Crash at main hall with intel drivers
Post by: The E on December 15, 2013, 04:46:49 am
Please post your fs2_open.log file.  Instructions on how to do this can be found in this post.

Always post your logs, even if your error looks similar to one reported by a different person.
Title: Re: Crash at main hall with intel drivers
Post by: el mariachi on December 18, 2013, 03:13:51 pm
here it is
http://pastebin.com/Xn8jCAK3
Title: Re: Crash at main hall with intel drivers
Post by: niffiwan on December 18, 2013, 03:48:06 pm
See if adding -no_glsl on the command line helps you out.

If not, you could try one of the recent nightly builds (or build from latest source if you're comfortable with that)  There were a few issues fixed recently to do with graphics options not being disabled correctly when the video card didn't support the required feature.

Title: Re: Crash at main hall with intel drivers
Post by: el mariachi on December 18, 2013, 04:52:51 pm
no_glsl  does nothing. I'll try building from the latest source and report ;)
Title: Re: Crash at main hall with intel drivers
Post by: el mariachi on December 19, 2013, 12:48:37 pm
SVN 10253 not working either
with -no_glsl
http://pastebin.com/MCz0rep1
Title: Re: Crash at main hall with intel drivers
Post by: niffiwan on December 19, 2013, 04:06:47 pm
:sigh:

Well, moving further into debugging territory, could you please try one of the following.

a) If you have a large amount of cloud based storage, and a good internet upload speed, could you try getting & providing a core dump?

Code: (using a terminal) [Select]
$ ulimit -c unlimited
$ ./fs2_open_DEBUG
$ ls -ltr core*   <-- this will be the core file, pick the most recent, it may be 500-700Mb in size though!

b) Could you provide a stack trace?  See here for details: http://www.hard-light.net/forums/index.php?topic=82688.msg1662031#msg1662031
Title: Re: Crash at main hall with intel drivers
Post by: el mariachi on December 20, 2013, 12:39:23 pm
(gdb) backtrace
Code: [Select]
#0  0x00007fffebb759ce in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#1  0x00007fffeb99fd86 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#2  0x00007fffeb99ff7a in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#3  0x00000000004d5167 in gr_opengl_save_screen () at graphics/gropengl.cpp:1028
#4  0x00000000007ae8ee in popup_do (pi=0x147e2a0 <Popup_info>, flags=67175424) at popup/popup.cpp:821
#5  0x00000000007aef88 in popup (flags=67175424, nchoices=3) at popup/popup.cpp:1013
#6  0x00000000005d1187 in player_tips_popup () at menuui/playermenu.cpp:1347
#7  0x00000000005b856a in main_hall_do (frametime=0.25) at menuui/mainhallmenu.cpp:840
#8  0x00000000004175fe in game_do_state (state=1) at freespace2/freespace.cpp:6466
#9  0x00000000004bbea5 in gameseq_process_events () at gamesequence/gamesequence.cpp:409
#10 0x000000000041841b in game_main (cmdline=0x223acc0 "") at freespace2/freespace.cpp:7062
#11 0x00000000004185ca in main (argc=1, argv=0x7fffffffe628) at freespace2/freespace.cpp:7196

I'll clean up my dropbox and see if I can fit a core dump there
Title: Re: Crash at main hall with intel drivers
Post by: Hellzed on December 22, 2013, 01:21:53 pm
I'm experiencing the exact same bug (Ubuntu 13.10, xorg-edgers mesa 10.0, Intel HD4000)...
If you need some aditional debug info, I can use gdb and install apitrace.
Title: Re: Crash at main hall with intel drivers
Post by: niffiwan on December 22, 2013, 03:21:40 pm
sure, it's always good to get more info. A stacktrace would be good, a coredump would be great (although obviously a bit harder to pass around)
Title: Re: Crash at main hall with intel drivers
Post by: Hellzed on December 23, 2013, 02:21:49 am
Here's the backtrace. I don't currently have the bandwidth to upload a core dump.
Code: [Select]
#0  0x00007fffe9fd18ce in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#1  0x00007fffe9dfb866 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#2  0x00007fffe9dfba5a in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#3  0x00000000004db71b in gr_opengl_save_screen ()
    at graphics/gropengl.cpp:1028
#4  0x00000000007ce20f in popup_do (pi=0x14a63a0 <Popup_info>, flags=67175424)
    at popup/popup.cpp:821
#5  0x00000000007ce8a9 in popup (flags=67175424, nchoices=3)
    at popup/popup.cpp:1013
#6  0x00000000005de142 in player_tips_popup () at menuui/playermenu.cpp:1347
#7  0x00000000005c4e2d in main_hall_do (frametime=0,25)
    at menuui/mainhallmenu.cpp:840
#8  0x0000000000417aa2 in game_do_state (state=1)
    at freespace2/freespace.cpp:6466
#9  0x00000000004c1acf in gameseq_process_events ()
    at gamesequence/gamesequence.cpp:409
#10 0x0000000000418a58 in game_main (cmdline=0x2261cc0 "")
    at freespace2/freespace.cpp:7062
#11 0x0000000000418c58 in main (argc=1, argv=0x7fffffffdfa8)
    at freespace2/freespace.cpp:7196
Title: Re: Crash at main hall with intel drivers
Post by: jr2 on December 24, 2013, 07:49:39 am
Can you 7zip a coredump to a manageable size using the ultra compression settings?  I Googled and apparently, there is possibly also some built in compression options that can be configured for creating core dumps.  Not sure if it will bring the file down to manageable size though.
Title: Re: Crash at main hall with intel drivers
Post by: Hellzed on December 27, 2013, 03:46:57 am
The core dump is not that big in our case :
https://www.dropbox.com/s/fg5znkhc8dzsc6z/core

(does it change anything that it's been compiled with llvm ?)

2nd core, this time with a g++ compiled fs2_open : https://www.dropbox.com/s/3ewifa9t5yzmsph/core_g%2B%2B
Title: Re: Crash at main hall with intel drivers
Post by: Echelon9 on December 29, 2013, 05:43:37 pm
Although support for Intel integrated graphics has been patchy at best, there has been a recent influx of crash reports on Ubuntu 13.10 (64bit) with this hardware.

Investigating to see if there is a recent change in the underlying platform which can be worked around.

Please follow Mantis #2988 (http://scp.indiegames.us/mantis/view.php?id=2988) for updates.
Title: Re: Crash at main hall with intel drivers
Post by: niffiwan on December 29, 2013, 07:40:47 pm
I've added a command line flag to disable the use of Pixel Buffer Objects.  I suspect that there's a bug in the Intel Linux drivers, or they aren't quite following the OpenGL specification.

Anyway: could you please try compiling & running this code to see if that works around the issue?
https://github.com/niffiwan/fs2open.github.com/commits/mantis2988

You will need to set "-disable_pbo" on the command line, or via the launcher (Advanced -> Troubleshooting -> "Disable OpenGL Pixel Buffer Objects")
Title: Re: Crash at main hall with intel drivers
Post by: Hellzed on December 29, 2013, 09:13:31 pm
Still crashes. I'm uploading a core dump right now. Sorry, wrong binary.
Ok, it works around the issue.

(By the way, on a completely different issue, any idea on what this could be ?
http://www.hard-light.net/forums/index.php?topic=83318.msg1725941#msg1725941 )
Title: Re: Crash at main hall with intel drivers
Post by: niffiwan on December 29, 2013, 09:33:40 pm
Hurrah & thanks for testing! :D  I'll see about getting the workaround reviewed & committed to trunk soon.  Or alternatively I'll see if there's some way to reliably auto-detect the use of an Intel driver with the issue & disable PBO automatically...
Title: Re: Crash at main hall with intel drivers
Post by: Hellzed on December 30, 2013, 05:29:21 am
Is this issue somewhere on the intel bugtracker ?
I'm using the xorg-edgers ppa (graphics stack compiled from git for Ubuntu), so if it's a bug in the intel drivers, I'd like to follow this issue and test again once it's fixed in the driver code.
Title: Re: Crash at main hall with intel drivers
Post by: niffiwan on December 30, 2013, 06:18:44 am
I haven't reported the bug upstream yet, I'd like to provide a minimal test case for them but I've got a few other things I need to sort out before moving on to that.
Title: Re: Crash at main hall with intel drivers
Post by: el mariachi on January 03, 2014, 04:58:41 am
This also works for me. Thanks!
Title: Re: Crash at main hall with intel drivers
Post by: notung on May 25, 2014, 09:22:08 pm
I've added a command line flag to disable the use of Pixel Buffer Objects.  I suspect that there's a bug in the Intel Linux drivers, or they aren't quite following the OpenGL specification.

Anyway: could you please try compiling & running this code to see if that works around the issue?
https://github.com/niffiwan/fs2open.github.com/commits/mantis2988

You will need to set "-disable_pbo" on the command line, or via the launcher (Advanced -> Troubleshooting -> "Disable OpenGL Pixel Buffer Objects")
I have the same problem (intel integrated graphics card using i965 driver). However I cannot find the commit in git hub. Is it merged already upstream? Otherwise could you please put the patch again or a new branch?

I am using binary version 3.7.0.

Thanks!
Title: Re: Crash at main hall with intel drivers
Post by: niffiwan on May 25, 2014, 09:55:02 pm
That link was a branch in my forked repo which I removed once the patch was applied upstream:
https://github.com/scp-fs2open/fs2open.github.com/commit/84728de58716e2ecc0b5098270a5bf5cb29327bd

Also, since FSO is still using SVN as the primary repo (and github is just a clone for now) you can find the same commit here as well:
http://svn.icculus.org/fs2open?limit_changes=0&view=rev&sortby=file&revision=10268

Lastly, the patch is also in the 3.7.2RC1 release :)
http://www.hard-light.net/forums/index.php?topic=87500.0
Title: Re: Crash at main hall with intel drivers
Post by: diribative on May 26, 2014, 11:10:41 pm
I haven't used FS2 Open in many years, so forgive me if I'm missing something obvious, but I think I'm facing the same problem. I tried selecting "fs2_open_3_7_2_RC1.exe" in the launcher, but it still crashes when I try to start with, or delete, a profile. Is there a way I can wipe my profiles clean to confirm there's not a problem along those lines that's interfering? Should I make a new thread? Thanks for any instructions/help you can provide.

Edit: It seems I *was* missing something obvious: this thread is about Linux and I'm on Windows 8.
Edit2: http://www.hard-light.net/forums/index.php?topic=87500.msg1747346#msg1747346 mentions that "Launcher 5.5g" doesn't work on Windows8. I'll have to get wxlauncher instead.
Title: Re: Crash at main hall with intel drivers
Post by: niffiwan on May 26, 2014, 11:47:44 pm
:)

That sounds like a wxlauncher issue, so yeah, a new thread in this forum would be good. Providing the wxlauncher debug log would be a good start, see the troubleshooting section of the 1st post in this thread: http://www.hard-light.net/forums/index.php?topic=67950.0