The apitrace size is bigger than the attachment size limit.
External link: http://swarm.cs.pub.ro/~cbadea/freedroid/freedroid_llvmpipe.tar.gz

Created attachment 53197 [details]
Bug reproduced in gdb.

Added the gdb log separately. The apitrace does not fully reproduce the bug - replaying it doesn't trigger the bug. I've tried keeping the game running past the SIGFPE signals, but the apitrace ends at the first SIGFPE signal.

The game says

  Hello, this is FreedroidRPG, version 0.14.1+svn.
  This seems to be a development version, so we'll exit on floating point exceptions.

And it appears the game is going out of its way to enable floating point exceptions, from freedroid/src/init.c:

        // Let's see if we're dealing with a real release or rather if
        // we're dealing with a svn version.  The difference is this:
        // Releases shouldn't terminate upon a floating point exception
        // while the current svn code (for better debugging) should
        // do so.  Therefore we check for 'svn' in the current version
        // string and enable/disable the exceptions accordingly...
        if (strstr(VERSION, "svn")) {
                DebugPrintf(-4, "\nThis seems to be a development version, so we'll exit on floating point exceptions.");
                // feenableexcept ( FE_ALL_EXCEPT );
                // feenableexcept ( FE_INEXACT ) ;
                // feenableexcept ( FE_UNDERFLOW ) ;
                // feenableexcept ( FE_OVERFLOW ) ;
                feenableexcept(FE_INVALID);
                feenableexcept(FE_DIVBYZERO);
        } else {
                DebugPrintf(-4, "\nThis seems to be a 'stable' release, so no exit on floating point exceptions.");
                fedisableexcept(FE_INVALID);
                fedisableexcept(FE_DIVBYZERO);
        }

But I'm not sure which is the default though.

llvmpipe uses the cpu for rendering, and it often needs to process extra padding data, for alignment reasons. It's very likely that that data is invalid. Also, applications can provide invalid floating point data themselves.

Did you build the game yourself? And if so, can you comment this code to see wheather it makes a difference?

I'm using the development version. Commenting feenableexcept(FE_INVALID); in src/init.c fixes the crash.

The driver crashing due to legal operations in the application looks like an odd behaviour to me. Is this the expected behaviour or is it a bug in llvmpipe?

(In reply to comment #4)
> The driver crashing due to legal operations in the application looks like an
> odd behaviour to me. Is this the expected behaviour or is it a bug in llvmpipe?

I'm not 100% sure this is a legal operation.

Floating point exception mode and rounding mode have usually effect for the whole process/thread.

It's fine for an application to change floating point behavior whithin itself, but it's probably good practice to reset to their system defaults when calling into third party libraries (such as OpenGL).

Unless the OpenGL ABI spec dictates the driver needs to be robust against this, I'm more inclined to consider this as an application bug.

This affects llvmpipe more than hardware OpenGL drivers because llvmpipe uses the CPU for everything. And there is no way to prevent floating point exceptions without disabling them, and doing so every GL call would affect performance for all apps.

I need to research a bit more on what's the right thing here.

I don't think there's anything we can do here. The app must not do this.