[fixed]Crash with irrlicht 1.8.2 and gcc 5.2 on linux

[est31]

Hello, minetest dev here,

some of our arch linux users had reported a reproducible crash a few seconds after starting minetest after their last system upgrade. (minetest tracker bug).

We have determined that it was no minetest bug, as they have reported that the irrlicht examples fail as well. Then we found out that only if you compile with gcc 5.2 seems to trigger this crash, and with clang it works fine.

Then, I've got a copy of gcc 5.2 myself, and found out:

• 1. irrlicht 1.8.1 with gcc gives no crash
  2. the hello world example works, but the user interface example fails
  3. the user interface example fails if you select the opengl renderer, but doesn't if you select the software renderer

will provide a stacktrace later.

[CuteAlien]

OK, stacktrace maybe helps. Otherwise... not sure, guess I'd have to install another system then. Both of my current distros are still using gcc 4.

[hendu]

No need, you can very easily do:

# build gcc 5.2 to a prefix
./configure --prefix=/opt/gcc52 --enable-languages=c,c++ --with-default-libstdcxx-abi=gcc4-compatible
make
make install

# build irr
CXX=/opt/gcc52/bin/g++ make

# when running examples, you have to use the newer libstdc++ (use lib if on 32-bit)
LD_LIBRARY_PATH=/opt/gcc52/lib64 ./02.Quake3Map

[est31]

Stacktrace for the user interface example is here: https://gist.github.com/anonymous/4ef001f9cad93d714811

In this setup, I ran with my ubuntu system provided 1.8.1 (perfectly fine) .so binary, only compiling with 1.8.2 headers triggers the bug. Its more though than just an incompatibility between 1.8.1 and 1.8.2 as builds where both 1.8.2 headers and .so binaries are used on runtime and linking time crash as well.

Also, note that I've edited the user interface's makefile to not do any optimisations (and to show line numbers for the backtrace):

Code: Select all

 
CXXFLAGS = -O0  -g
 

It crashes with the default CXXFLAGS as well, but this way we know that if at all, its not the fault of e.g. -O2 optimisations.

There is also a stacktrace on the minetest tracker: https://github.com/minetest/minetest/is ... -104335508

I guess that one is where the binary is 1.8.2 and compiled with gcc, and being compiled with 1.8.1

A note about how I've obtained gcc 5.2: I've downloaded the gcc source zip, extracted it, then ran "configure --prefix=/home/some/installation/root/path --disable-multilib", then make -j something, and then I could reproduce the crash when compiling the user interface example with "make CXX=/home/some/installation/root/path/bin/g++ all", without having to set LD_LIBRARY_PATH (but I got the crash when setting it, as well).

[est31]

Here is a valgrind stacktrace, for the case it is helpful: https://gist.github.com/anonymous/6f49bedfc3a31267c07d

[est31]

Did a git bisect on one of the git mirrors, and found the commit where the crash starts to happen:

Code: Select all

 
Author: cutealien <cutealien@dfc29bdd-3216-0410-991c-e03cc46cb475>
Date:   Wed Aug 26 21:04:11 2015 +0000
 
    Merge branch releases/1.8 revisions 5104:5120 into trunk:
    - Fix compiling on GCC5 on MinGW
diff --git a/changes.txt b/changes.txt
index 3a21dab..53e796a 100644
--- a/changes.txt
+++ b/changes.txt
@@ -116,6 +116,7 @@ Changes in 1.9 (not yet released)
 --------------------------
 Changes in 1.8.2
 
+ - Fix compiling on GCC5 on MinGW (thannks to Slipxy for finding the bug and to osense for reporting it).^M
  - Fix loading of .X and .B3D models with non-normalized quaternion rotations (thanks to JLouisB for a test-model).
  - Fix compiling on Free BSD (thanks to leper for reporting and patch)
  - Fix bug with multiple SetPixelFormat calls. (reported and fixed by anontypist)
diff --git a/include/irrpack.h b/include/irrpack.h
index 3cf643f..ff922d0 100644
--- a/include/irrpack.h
+++ b/include/irrpack.h
@@ -26,7 +26,7 @@
        // it started to be necessary with gcc 4.7 on mingw unless compiled with -mno-ms-bitfields.
        // And I found some hints on the web that older gcc versions on the other hand had sometimes
        // trouble with pragma pack while they worked with __attribute__((packed)).
-#      if (__GNUC__ >= 4 ) && (__GNUC_MINOR__ >= 7)
+#      if (__GNUC__ > 4 ) || ((__GNUC__ == 4 ) && (__GNUC_MINOR__ >= 7))^M
 #              pragma pack( push, packing )
 #              pragma pack( 1 )
 #              define PACK_STRUCT
 

[CuteAlien]

Yeah, that patch would have been my guess. The one to get gcc 5 working on MinGW breaks it on Linux - figures *sigh*.
Well, maybe I can find time for it next weekend. Still tired from the release (that took nearly 2 days last weekend - so I had to get this one free urgently). Anyone who can find out a way to patch it so it works on gcc 4 and 5 on Linux and on MinGW is welcome to help.

[est31]

Hi, from inspecting your patch, and reading docs, I see that after you do pack( push, [n]), you have to pop as well. I've therefore wondered where that pop was done, and found the comment in irrpack.h:

Code: Select all

 
// Always include the irrunpack.h file right after the last type declared
// like this, and do not put any other types with different alignment
// in between!
 

From knowing that the breaking commit adjusted gcc version recognition, I've seen that the version recognition in irrunpack.h remained unaffected and in the old buggy state, where it fails for gcc versions between 5.0 and (non-existing) 5.6. By changing it analogous to the commit, I could fix the crash:

Code: Select all

 
--- a/include/irrunpack.h
+++ b/include/irrunpack.h
@@ -11,7 +11,7 @@
 #elif defined (__DMC__)
 #      pragma pack( pop )
 #elif defined( __GNUC__ )
-#   if (__GNUC__ >= 4 ) && (__GNUC_MINOR__ >= 7)
+#   if (__GNUC__ > 4 ) || ((__GNUC__ == 4 ) && (__GNUC_MINOR__ >= 7))^M
 #          pragma pack( pop, packing )
 #   endif
 #endif
 

Now we properly pop the alignment setting stack, and I can't reproduce the crash anymore.

[CuteAlien]

Ow, I should have seen that. Thanks a lot. It's checked into the 1.8 release branch, but I will have to find time to make a new release. And I think we might have another problem as since shortly a third of our tests are breaking on Debian, but that one was likely some change in Debian not in Irrlicht (they seem to fail suddenly also for older Irrlicht versions).