• Announcements

    • Spaff

      These Forums are closing!   10/04/2019

      After more than a decade of serving this community well, these forums have finally run their course and it's time to close them down. That doesn't mean we want to close the doors on our community, quite the opposite!
      Our discord server grows ever busier by the day, and we encourage all Double Fine fans to meet us over there www.discord.gg/doublefine In a short time these forums will become a read only archive and will remain that way until they become needed again.
      You never know, it might happen.  There is... a prophecy. Thank you all for being part of these forums, and remember that the fun is definitely not over - so please join us on Discord! Love ya, Spaff, Tim, Info Cow, and all of Double Fine.
Sign in to follow this  
person

Crash - [Linux] (Unsupported GL extension & other problems)

Recommended Posts

Upon launching Cq.bin.x86, a Window pops up saying "Your GL driver does not support ARB_half_float_vertex" and after dismissing it, a few other windows come up mentioning other GL extensions. I'm on an i7 laptop using the Intel Sandybridge i915 drivers, running Debian Testing. Any ideas for further diagnosing the problem / what to do about it?

Share this post


Link to post
Share on other sites

Often these kinds of problems are caused by missing 32-bit libraries on a 64-bit architecture, so that might be worth mentioning if it applies.

EDIT: Sorry, didn't see the name of the binary there.

Share this post


Link to post
Share on other sites

By the way,

Linux ... 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux

DMI: Dell Inc. Latitude E6320/087HK7, BIOS A01 03/02/2011

Thanks - am Googling around for 64bit GL unsupported extension posts elsewhere, in case that turns up any hints

Share this post


Link to post
Share on other sites

I just noticed,

Cq.bin.x86: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xcb7eeb0f5d16eea46d01d14a01a8d2a52876dd19, not stripped

Haven't tried to run a 32 bit binary for years. I'm not sure it's even supported on Debian anymore. Could Doublefine release a 64 bit build?

Okay, some other threads suggest using some 32 bit libs works for other 32 bit binaries

eg.

http://forum.winehq.org/viewtopic.php?t=15434

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683853

LIBGL_DRIVERS_PATH=/usr/lib32/dri ./Cq.bin.x86

Unrecognized deviceID 126

Unrecognized deviceID 126

Unrecognized deviceID 126

Unrecognized deviceID 126

And I get the same error dialogs.

Not sure I have the 32 bit libs I need

$ ls /usr/lib32/dri/

i810_dri.so mach64_dri.so r200_dri.so radeon_dri.so swrast_dri.so

i915_dri.so mga_dri.so r300_dri.so savage_dri.so tdfx_dri.so

i965_dri.so r128_dri.so r600_dri.so sis_dri.so unichrome_dri.so

Share this post


Link to post
Share on other sites

We're unlikely to release a 64bit version of these games in the very near future. There's a fair bit of touchy work required to make that happen.

If you get these GL extension errors, it's most likely a driver or GPU issue. We require a small number of extensions for our games, most of them are very common, but that can vary quite a bit on Linux, across different distros, open vs closed source drivers, etc. In general, I'd first make sure your drivers are as up to date as possible, and then also make sure that you have 32bit versions of necessary libraries.

Share this post


Link to post
Share on other sites

Okay, let's see what libs the thing is loading and where it's getting unhappy. I straced Cq.bin.x86 (1) without trying to influence what libs it loaded and (2) with LIBGL_DRIVERS_PATH=/usr/lib32/dri , for comparison

Looks like it has its own copies of some libs,

open("/data/nick/scratch/CostumeQuest/lib/libSDL2-2.0.so.0", O_RDONLY) = 3

For others, it looks in the CostumeQuest/lib directory but failing to find anything loads system ones

open("/data/nick/scratch/CostumeQuest/lib/libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

then in cases (1) and (2) it ends up loading /usr/lib32/libGL.so.1

then tries /data/nick/scratch/CostumeQuest/lib/libGLU.so.1

(it mmaps and closes all these files)

this goes on for

/usr/lib32/libz.so.1

/lib32/libpthread.so.0

/usr/lib32/libstdc++.so.6

/lib32/libm.so.6

/usr/lib32/libgcc_s.so.1

/lib32/libc.so.6 instead

/lib32/librt.so.1

/usr/lib32/libX11.so.6

/usr/lib32/libXext.so.6

/usr/lib32/libXxf86vm.so.1

/usr/lib32/libXdamage.so.1

/usr/lib32/libXfixes.so.3

/usr/lib32/libdrm.so.2

/usr/lib32/libxcb.so.1

/usr/lib32/libXau.so.6

/usr/lib32/libXdmcp.so.6

then it sets up some thread and signal stuff

then we keep going with

/usr/lib32/libXcursor.so.1

/usr/lib32/libXrender.so.1

/usr/lib32/libXinerama.so.1

/usr/lib32/libXi.so.6

/usr/lib32/libXrandr.so.2

/usr/lib32/libXss.so.1

then we open sockets, look for permissions

i think there's some thread that's polling something and keeps getting told -1

(why are we reopening these now?)

/usr/lib32/libXcursor.so.1

/usr/lib32/libXrender.so.1

/usr/lib32/libXinerama.so.1

/usr/lib32/libXi.so.6

/usr/lib32/libXrandr.so.2

/usr/lib32/libXss.so.1

loads locale stuff

okay, for the plain run (1) it calls

open("/usr/lib/dri/tls/i965_dri.so", O_RDONLY) = -1 ENOENT (No such file or directory)

open("/usr/lib/dri/i965_dri.so", O_RDONLY) = -1 ENOENT (No such file or directory)

geteuid32() = 1000

getuid32() = 1000

open("/usr/lib/dri/tls/swrast_dri.so", O_RDONLY) = -1 ENOENT (No such file or directory)

open("/usr/lib/dri/swrast_dri.so", O_RDONLY) = -1 ENOENT (No such file or directory)

the one with the different lib path (2) goes straight to

geteuid32() = 1000

getuid32() = 1000

open("/usr/lib32/dri/tls/i965_dri.so", O_RDONLY) = -1 ENOENT (No such file or directory)

open("/usr/lib32/dri/i965_dri.so", O_RDONLY) = 5

then opens

/usr/lib32/libexpat.so.1

/usr/lib32/libdrm_intel.so.1

then opens

/dev/dri/card0

which looks promising

but then

ioctl(5, 0x80046402, 0xff9d59cc) = 0

poll([{fd=3, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=3, revents=POLLOUT}])

writev(3, [{"\211\2\3\0\274\0\0\0\4\0\0\0", 12}, {NULL, 0}, {"", 0}], 3) = 12

poll([{fd=3, events=POLLIN}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN}])

read(3, "\1X\\\0\0\0\0\0\1\0\0\0\22\177\0\0\0\0\0\1\0\0\0\0\320\260xx\22\177\0\0", 4096) = 32

read(3, 0xadb2988, 4096) = -1 EAGAIN (Resource temporarily unavailable)

ioctl(5, 0xc0246400, 0xad93818) = 0

ioctl(5, 0xc0246400, 0xad93818) = 0

time(NULL) = 1368223575

ioctl(5, 0xc0086446, 0xff9d58a8) = 0

ioctl(5, 0xc0086446, 0xff9d5890) = 0

ioctl(5, 0x80106463, 0xff9d5828) = 0

ioctl(5, 0xc0086446, 0xff9d5838) = 0

ioctl(5, 0xc0086446, 0xff9d5838) = 0

ioctl(5, 0xc0086446, 0xff9d5838) = 0

ioctl(5, 0xc0086446, 0xff9d5848) = 0

mmap2(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff6a3f000

write(2, "Unrecognized deviceID 126\n", 26) = 26

which sounds bad. it also has another write(2, "Unrecognized deviceID 126\n", 26) = 26 after a bunch more of that polling

now we get up to a load of standard signal handlers being installed

and open

/data/nick/scratch/CostumeQuest/DFCONFIG

/data/nick/scratch/CostumeQuest/Data/Config/BuddhaDefault.cfg

and some other cfg files

read stuff from them. Maybe this is threaded because my logs are out of order here. Eep, we clone() a bit

Now a bunch more polling, then we load

/data/nick/scratch/CostumeQuest/CostumeQuest.png

Now a load more interaction with gdm (displaying those error dialogs?)

now rt_sigaction() some more... ah, maybe it's cleaning up before exit

okay, let's ltrace it. Pretty massive output of course... anything I should look for? Hmm. GL ? That extension that was missing? Can't find anything suspicious just by searching and I'm not going to read the output line by line or I'll go crazy.

For the libraries that are loaded, what versions do I have... they all seem to come from 2 packages.

$ dpkg -S /usr/lib32/libGL.so.1

ia32-libs: /usr/lib32/libGL.so.1

Package: ia32-libs

Version: 1:0.4

$ dpkg -S /lib32/libm.so.6

libc6-i386: /lib32/libm.so.6

http://packages.debian.org/search?keywords=ia32-libs&searchon=names&suite=all&section=all

Package: libc6-i386

Source: eglibc

Version: 2.13-38

http://packages.debian.org/search?keywords=libc6-i386&searchon=names&suite=all&section=all

So my only idea at this point is to try and force it to use the system's libSDL2 instead of its own one. As far as I can tell it looks for and finds all the 32 bit libs it's looking for, and I can't see where it's probing for extensions in the strace output, or what it's looking for and can't find.

Share this post


Link to post
Share on other sites
Upon launching Cq.bin.x86, a Window pops up saying "Your GL driver does not support ARB_half_float_vertex" and after dismissing it, a few other windows come up mentioning other GL extensions. I'm on an i7 laptop using the Intel Sandybridge i915 drivers, running Debian Testing. Any ideas for further diagnosing the problem / what to do about it?

I'm using Intel Ivy Bridge hardware on Debian Testing, and I believe that's pretty similar to Sandy Bridge - it certainly should be using the same drivers.

You can check what extensions your drivers support with the "glxinfo" command-line tool. It produces bucket-loads of output, though, so pipe the result to 'less' or 'grep' or something.

For what it's worth, on my machine glxinfo says (among other things):


server glx vendor string: SGI

server glx version string: 1.4

client glx vendor string: Mesa Project and SGI

client glx version string: 1.4

GLX version: 1.4

OpenGL vendor string: Tungsten Graphics, Inc

OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop 

OpenGL version string: 3.0 Mesa 8.0.5

OpenGL shading language version string: 1.30

OpenGL extensions:

   (lots of output skipped)

   GL_ARB_depth_buffer_float, GL_ARB_half_float_vertex, 

...so I definitely do have ARB_half_float_vertex support (Costume Quest still doesn't actually work for me, but it's not because of missing GL extensions). If you have the same versions listed under "OpenGL version string" and you *don't* have those extensions listed, maybe it's a limitation of the hardware, or maybe it's something they haven't implemented yet (there have been two Intel driver releases since the version in Debian Testing, hopefully the new versions will be packaged over the next few weeks now that Wheezy has been released).

If glxinfo says you *do* have those extensions and the game says you *don't*.. well that's going to be very interesting to track down. It might indeed be something to do with not having some 32-bit library installed so it's falling back to software rendering or something (glxinfo won't tell you that, because it's a 64-bit app and can find the 64-bit drivers just fine).

Share this post


Link to post
Share on other sites

Hi - Screwtape thanks for the tip! A complication indeed is that glxinfo will be using 64 bit libraries, so that means it won't tell us what the libs in /usr/lib32 support, doesn't it? I have not done any OpenGL in 10 years, so don't know offhand whether glxinfo reports something to do with the openGL libs or the GPU kernel module.

FWIW

direct rendering: Yes

server glx vendor string: SGI

server glx version string: 1.4

...

OpenGL vendor string: Tungsten Graphics, Inc

OpenGL renderer string: Mesa DRI Intel® Sandybridge Mobile

OpenGL version string: 3.0 Mesa 8.0.5

OpenGL shading language version string: 1.30

GL_ARB_half_float_vertex amongst the list of supported extensions.

Also, can't nm the stripped libs or find any mention of the extension in the normal 62 bit libs let alone the 32 bit ones. Will grab the 64 and 32 bit libs' source after work and have a closer look.

$ objdump -d /usr/lib/x86_64-linux-gnu/libGL.so.1 | grep -i half | wc -l

0

$ objdump -d /usr/lib/x86_64-linux-gnu/libGLU.so.1 | grep -i half | wc -l

0

$ objdump -d /usr/lib32/libGLU.so.1 | grep -i half | wc -l

0

$ objdump -d /usr/lib32/libGL.so.1 | grep -i half | wc -l

0

Share this post


Link to post
Share on other sites
Hi - Screwtape thanks for the tip! A complication indeed is that glxinfo will be using 64 bit libraries, so that means it won't tell us what the libs in /usr/lib32 support, doesn't it? I have not done any OpenGL in 10 years, so don't know offhand whether glxinfo reports something to do with the openGL libs or the GPU kernel module.

The Linux graphics stack is... complicated. Parts of it are in the kernel, libdrm, Mesa, the Xorg core and the Xorg drivers, and I have no idea where the GL extensions list is supplied.

If you're running Debian on AMD64 and have enough i386 libs installed that Costume Quest can start, I assume you have multiarch configured already, so you should be able to just replace your 64-bit glxinfo with a 32-bit one to see what a 32-bit app sees.


sudo apt-get install mesa-utils:i386

Of course, you can install "mesa-utils:amd64" afterward to replace the 32-bit version with the 64-bit version.

Share this post


Link to post
Share on other sites

Hi,

I haven't had much reason to run 32 bit stuff before, so I didn't have multiarch set up (is this the final result of the work they started about 10 years ago to accomodate multiple architectures?) but just a plain 64 bit install.

So I read

http://wiki.debian.org/Multiarch

http://wiki.debian.org/Multiarch/Implementation

And ran

dpkg --add-architecture i386

apt-get update

apt-get install mesa-utils:i386

The following packages will be REMOVED:

mesa-utils

The following NEW packages will be installed:

gcc-4.7-base:i386 libc6:i386 libc6-i686:i386 libdrm-intel1:i386

libdrm-nouveau1a:i386 libdrm-radeon1:i386 libdrm2:i386 libexpat1:i386

libffi5:i386 libgcc1:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx:i386

libglapi-mesa:i386 libglew1.7:i386 libglu1-mesa:i386 libice6:i386

libpciaccess0:i386 libsm6:i386 libstdc++6:i386 libuuid1:i386 libx11-6:i386

libx11-xcb1:i386 libxau6:i386 libxcb-glx0:i386 libxcb1:i386 libxdamage1:i386

libxdmcp6:i386 libxext6:i386 libxfixes3:i386 libxi6:i386 libxmu6:i386

libxt6:i386 libxxf86vm1:i386 mesa-utils:i386 uuid-runtime zlib1g:i386

OK, so now I have a load of 32bit libraries in /usr/lib/i386-linux-gnu/

$ file `which glxinfo`

/usr/bin/glxinfo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26

$ glxinfo | grep half

GL_ARB_half_float_pixel, GL_ARB_point_sprite, GL_ARB_shading_language_100,

GL_ARB_depth_buffer_float, GL_ARB_half_float_vertex,

Start Costume Quest, get a complaint about EXT_texture_compression_s3tc, Google a bit,

apt-get install libtxc-dxtn-s2tc0:i386

And now I can launch the program, start the game and then it crashes. Is this the point where you're at too, Screwtape?

Share this post


Link to post
Share on other sites

I get a variety of weird things. So far, I've had:

- game creates a black window that fills the screen; I can hear menu-type music playing in the background but nothing ever appears, and my mouse-cursor is still visible.

- game switches my desktop resolution to 1280x1024 (of all things), then crashes

- most entertainingly, once the game just created a 1280x1024 window in the *middle* of my desktop, and another 1280x1024 black window at the top-left. Because the two windows were not exactly on top of one another, I could see a blue border at the edges of the 'middle' window, but the 'top-left' window obscured everything else. Unfortunately, the game had grabbed my keyboard and mouse input, so I couldn't alt-tab away or try and move the 'top-left' window completely out of the way.

The other Buddha-engine games (Brutal Legend, Stacking) have similar results, and I haven't tried Psychonauts.

This is all under GNOME 3, by the way. I'm going to try again under a non-compositing window manager and see if that makes any difference... if not, I'm kinda stuck.

Share this post


Link to post
Share on other sites

Thanks for all the ideas so far dude.

I tried stracing again now that I have the multiarch libraries around. Near the end it does a couple of open("/home/nick/.local/share/doublefine/costumequest/CQ_save_0", O_RDONLY) (after I've selcted a slot to resume from the GUI). THen the game appears briefly and then the crash. The only calls I can see after that above open() are looking for things in Data/UI/HUD/Opt. eg. a couple dozen like

stat64("Data/UI/HUD/Opt/Shared/ControllerIcons.gfx", 0xffd21abc) = -1 ENOENT (No such file or directory)

And then a segfault. The Data directory is pretty empty though... not sure what the game is trying to do here.

Data/

└── Config

├── boot.lua

├── Buddha.cfg

├── BuddhaDefault.cfg

├── input.lua

├── SDLGamepad.config

└── user.lua

Share this post


Link to post
Share on other sites
This is all under GNOME 3, by the way. I'm going to try again under a non-compositing window manager and see if that makes any difference...

I logged out of the normal, composited mode of GNOME 3 and logged back in with "GNOME Classic" mode which isn't composited. It turns out that yes, things have indeed changed!

- Stacking now seems to work perfectly - intro movie, music, main menu, etc. even setting resolutions and everything... right up to the point where I pick a save file and enter my name, then it crashes.

- Costume Quest has pretty much the same behaviour. I pick a save-file, it draws a nice cartoony scene of a kid standing in the middle of the road in a suburban neighbourhood, and then it crashes.

- Brutal Legend, too: now the 'Double Fine' logo movie plays, and I can tweak all the options in the menu quite nicely, but I still crash after running around a little bit in the first room.

Now that I look a little closer, I see that at least the Costume Quest binary isn't stripped, which means that getting a gdb backtrace might actually be useful to the porters:


Program received signal SIGSEGV, Segmentation fault.

[switching to Thread 0xe8590b40 (LWP 21446)]

0x08a9fd47 in ParticleVertex::Fill(ParticleSystemData const*, ParticleState const*, float const*, unsigned int, vec3 const&, float const&, mat4 const&, ParticleVertex*) ()

(gdb) bt

#0  0x08a9fd47 in ParticleVertex::Fill(ParticleSystemData const*, ParticleState const*, float const*, unsigned int, vec3 const&, float const&, mat4 const&, ParticleVertex*) ()

#1  0x08a7f85f in ParticleSnapshot::_RenderParticles(RenderContext*, TaskDispatcher*, mat4 const&) ()

#2  0x08a7fe07 in ParticleSnapshot::Render(RenderContext*, TaskDispatcher*, mat4 const&) ()

#3  0x08a1d7d2 in SceneFrame::_RenderShadedSnapshots(RenderContext*, RenderMessagePump*, RenderSnapshot**, unsigned int, GeomFilter, char const*) ()

#4  0x08a22b50 in SceneFrame::_RenderShadedPass(RenderContext*, RenderMessagePump*) ()

#5  0x08a2563f in SceneFrame::RenderShaded(RenderContext*, RenderMessagePump*)

   ()

#6  0x08a52779 in SceneGraph::_RenderThreadMainLoop(Thread*) ()

#7  0x084aedb6 in Thread::Run() ()

#8  0x084af382 in ThreadImpl::_StartFunc(void*) ()

#9  0xf7b2da0d in start_thread () from /lib/i386-linux-gnu/libpthread.so.0

#10 0xf793fe3e in clone () from /lib/i386-linux-gnu/libc.so.6

If there's any other information I can supply that would be helpful, please let me know!

Share this post


Link to post
Share on other sites

Same thing happens to me with KDE4 under Linux Mint 14 (32bit) and nvidia graphics. All the three games (Brütal Legend, Costume Quest and Stacking) crash after the menu.

"Segmentation fault (core dumped)"

I do not know what to do. Psychonauts works without any problems.

Share this post


Link to post
Share on other sites

Running under normal Gnome3 here.

Interesting that it happens with a 32 bit OS too.

Backtrace (same as above pretty much):


Program received signal SIGSEGV, Segmentation fault.

[switching to Thread 0xde753b70 (LWP 4302)]

0x08a9fd47 in ParticleVertex::Fill(ParticleSystemData const*, ParticleState const*, float const*, unsigned int, vec3 const&, float const&, mat4 const&, ParticleVertex*) ()

(gdb) bt

#0  0x08a9fd47 in ParticleVertex::Fill(ParticleSystemData const*, ParticleState const*, float const*, unsigned int, vec3 const&, float const&, mat4 const&, ParticleVertex*) ()

#1  0x08a7f85f in ParticleSnapshot::_RenderParticles(RenderContext*, TaskDispatcher*, mat4 const&) ()

#2  0x08a7fe07 in ParticleSnapshot::Render(RenderContext*, TaskDispatcher*, mat4 const&) ()

#3  0x08a1d7d2 in SceneFrame::_RenderShadedSnapshots(RenderContext*, RenderMessagePump*, RenderSnapshot**, unsigned int, GeomFilter, char const*) ()

#4  0x08a22b50 in SceneFrame::_RenderShadedPass(RenderContext*, RenderMessagePump*) ()

#5  0x08a2563f in SceneFrame::RenderShaded(RenderContext*, RenderMessagePump*)

   ()

#6  0x08a52779 in SceneGraph::_RenderThreadMainLoop(Thread*) ()

#7  0x084aedb6 in Thread::Run() ()

#8  0x084af382 in ThreadImpl::_StartFunc(void*) ()

#9  0xf7b24c39 in start_thread ()

  from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0

#10 0xf796178e in clone () from /lib/i386-linux-gnu/i686/cmov/libc.so.6

Share this post


Link to post
Share on other sites

I get the same ParticleVertex::Fill stack trace as above, in this game and Stacking. Running Kubuntu 12.04 on a Thinkpad T500 using the integrated Intel graphics with mesa drivers. I used driconf to enable s3tc compression with libtxc.

Kernel:

3.2.0-41-generic #66-Ubuntu SMP Thu Apr 25 03:27:11 UTC 2013 x86_64

Graphics card:

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

Linking:

$ ldd Cq.bin.x86

linux-gate.so.1 => (0xf7791000)

libSDL2-2.0.so.0 => /opt/costume-quest/./lib/libSDL2-2.0.so.0 (0xf76af000)

libGL.so.1 => /usr/lib/i386-linux-gnu/mesa/libGL.so.1 (0xf762f000)

libGLU.so.1 => /usr/lib/i386-linux-gnu/libGLU.so.1 (0xf75b9000)

libfmodex-4.42.16.so => /opt/costume-quest/./lib/libfmodex-4.42.16.so (0xf7433000)

libfmodevent-4.42.16.so => /opt/costume-quest/./lib/libfmodevent-4.42.16.so (0xf73a6000)

libfmodeventnet-4.42.16.so => /opt/costume-quest/./lib/libfmodeventnet-4.42.16.so (0xf730c000)

libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf72f6000)

libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf72f0000)

libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf72d5000)

libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf71f0000)

libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf71c4000)

libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf71a6000)

libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf6ffc000)

librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf6ff3000)

libglapi.so.0 => /usr/lib/i386-linux-gnu/libglapi.so.0 (0xf6fdd000)

libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xf6fcb000)

libXdamage.so.1 => /usr/lib/i386-linux-gnu/libXdamage.so.1 (0xf6fc7000)

libXfixes.so.3 => /usr/lib/i386-linux-gnu/libXfixes.so.3 (0xf6fc0000)

libX11-xcb.so.1 => /usr/lib/i386-linux-gnu/libX11-xcb.so.1 (0xf6fbd000)

libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf6e89000)

libxcb-glx.so.0 => /usr/lib/i386-linux-gnu/libxcb-glx.so.0 (0xf6e71000)

libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf6e50000)

libXxf86vm.so.1 => /usr/lib/i386-linux-gnu/libXxf86vm.so.1 (0xf6e49000)

libdrm.so.2 => /usr/lib/i386-linux-gnu/libdrm.so.2 (0xf6e3c000)

/lib/ld-linux.so.2 (0xf7792000)

libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf6e38000)

libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf6e31000)

glxinfo snippet with mesa-utils:i386:

OpenGL vendor string: Tungsten Graphics, Inc

OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset x86/MMX/SSE2

OpenGL version string: 2.1 Mesa 8.0.4

OpenGL shading language version string: 1.20

It crashes in the same spot under Steam, so I assume it's the same problem although I'm not sure how to get the stack trace in that case. I assume Xorg.0.log info is not useful since it will be the 64-bit drivers, but if there's other information I can provide please let me know.

Share this post


Link to post
Share on other sites

Getting the same

"Your GL driver does not support ARB_half_float_vertex" and, in a second message, "ARB_texture_rg"

on Mint 14 Nadia 32 bit for both Costume Quest and Stacking.

Share this post


Link to post
Share on other sites

OK, so no Doublefine posts in this thread for a while, and a few of us have crashes at the same point. Is there some way to file a bug report?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this