Bug 56926 - Crash (without ICE) while compiling Boost.Math
Summary: Crash (without ICE) while compiling Boost.Math
Status: WAITING
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.8.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-11 19:13 UTC by Ruben Van Boxem
Modified: 2015-05-23 02:22 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-04-12 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ruben Van Boxem 2013-04-11 19:13:47 UTC
When compiling the file libs\math\build\..\src\tr1\assoc_laguerre.cpp from Boost 1.52.0 or 1.53.0 (perhaps any other version is affected too), GCC causes a dirty crash providing me no way of getting a sensible backtrace or providing a preprocessed source for reproduction. The compile command is:

"g++"  -ftemplate-depth-128 -O0 -fno-inline -Wall -g -mthreads -fvisibility=hidden -Winvalid-pch -DBOOST_ALL_NO_LIB=1 -DBOOST_BUILD_PCH_ENABLED -I"bin.v2\libs\math\build\gcc-mingw-4.8.1\debug\link-static\threading-multi\..\src\tr1" -I"." -I"libs\math\src\tr1" -c -o "bin.v2\libs\math\build\gcc-mingw-4.8.1\debug\link-static\threading-multi\assoc_laguerre.o" "libs\math\build\..\src\tr1\assoc_laguerre.cpp"

This does not happen with GCC 4.7. If there is anything I can try to give more output, please let me know. The crash happens before -save-temps outputs anything.

The binaries are for Windows 64-bit and available here (but require Win64, I haven't tested the Linux binaries built with the exact same build process):
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-release/x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z/download
Comment 1 Richard Biener 2013-04-12 08:42:20 UTC
Don't use PCH.  But we still need a testcase.
Comment 2 Ruben Van Boxem 2013-05-13 13:48:56 UTC
As bugzilla has a file size limit of 1000kB, here's a link to my dropbox containing a zipped gch file that I believe is responsible for the crash.

https://dl.dropboxusercontent.com/u/58715553/pch.hpp.gch.zip

This file was created with GCC 4.8.1 20130425.

Alternatively (if you have a 64-bit Windows (virtual)box) just download
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-release/x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z

and Boost
http://sourceforge.net/projects/boost/files/boost/1.53.0/

and add the mingw64/bin extracted directory to PATH, and run
bootstrap toolset=gcc
b2 toolset=gcc

which will slowly compile Boost up to Boost.Math, which will result in several crashes.
Comment 3 asmwarrior 2013-10-10 01:38:54 UTC
We meet this issue when building wxWidgets trunk and Codeblocks using PCH, see http://forums.codeblocks.org/index.php/topic,18383.msg125964.html#msg125964
Comment 4 asmwarrior 2013-10-15 00:57:49 UTC
There is a test case in this post: http://sourceforge.net/p/mingwbuilds/mailman/message/29214215/
Comment 5 baltic 2013-12-27 22:10:45 UTC
Experience the same while trying to build a project with massive amounts of Qt headers in a pch. Happens with mingw64 builds for versions 4.8.0 4.8.1 and 4.8.2
Can upload the pch, if needed. worked fine with 4.6
Comment 6 asmwarrior 2013-12-28 09:22:38 UTC
It is very simple to reproduce this bug. Here is the steps I do
1, download the GCC 4.8.2 from MinGW-w64 site, I'm using i686-4.8.2-release-posix-dwarf-rt_v3-rev1

2, download the boost source package, I'm using boost_1_55_0.7z download from boost official site, extract its source to some folder like: D:\mingw-builds\boost_1_55_0.  (Note, no need to build boost library, only the boost header files are needed for testing)

3, create a simple file named "pch.h", which contains following:
--------------------
#ifndef pch_h
#define pch_h

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdelete-non-virtual-dtor"

#include <boost/asio.hpp>
#include <boost/iostreams/filtering_stream.hpp>
#include <boost/program_options.hpp>
#include <boost/thread.hpp>

#pragma GCC diagnostic pop
#endif
-------------------- 

4, create a simple "test.cpp" file, which contains following:
--------------------
#include "pch.h"

int main()
{
	int a;
	int b;
	int c;
	a++;
	b++;
}
--------------------

5, build the pch file by running the command.

g++.exe -Wall -fexceptions  -g  -march=core2 -Wall -ID:\mingw-builds\boost_1_55_0  -c pch.h -o pch.h.gch

6, now, you will see a file named "pch.h.gch" was generated, its size is bigger than 200M.

7, compile the test.cpp file by running the command:
g++.exe -v -Wall -fexceptions  -g  -march=core2 -Wall -ID:\mingw-builds\boost_1_55_0  -Winvalid-pch -include pch.h -c test.cpp -o test.o

8, I see some verbose messages, but no "test.o" file was generated in the working directory, also I see no crash dialog shown.

So, this is indeed a bug.

Now, if you comment out some lines in the pch.h file, e.g. only leave the first #include directive: #include <boost/asio.hpp>, and comment out the later three include directive, and run the steps again, you get a 47M pch.h.gch and a 206K test.o file.

I try to use GDB to catch the errors, but failed.
Try use GDB, I did such thing:
gdb g++.exe [enter]
then
set args -v -Wall -fexceptions  -g  -march=core2 -Wall -ID:\mingw-builds\boost_1_55_0  -Winvalid-pch -include pch.h -c test.cpp -o test.o [enter]
then
r [enter]

GDB can't catch anything, just the same as I run the command in the Command line, the last message from GDB is: [Inferior 1 (process 2000) exited with code 01]

Does exit code "01" has some special meaning?

BTW: I have test the GCC 4.9 snapshot i686-4.9.0-snapshot-20131119-rev205009-posix-dwarf-rt_v4.7z from mingw-w64 site, it has the same bug.
Comment 7 baltic 2013-12-28 13:42:05 UTC
(In reply to baltic from comment #5)
> worked fine with 4.6
This is not true anymore :) was probably working fine with previous versions of the Qt, because headers were smaller back than. Now 4.6 version of MinGW-64 doesn't work with the PCH's full of Qt headers either.
Comment 8 Emma 2014-02-26 01:14:44 UTC
Probably I'd better add some comments here, even though the problem was not caused by compiling boost. Well, it is crashed because compiling large precompiled header file. Any progress to solve the problem?
Comment 9 Andre Netzeband 2014-10-15 22:48:18 UTC
Hello

I'm using MingW64 with GCC 4.9.1 (x86_64-4.9.1-posix-seh-rt_v3-rev1) and tried to precompile some Boost Headers to speed up compiling.
Unfortunately I get the same error described here: It crashed and windows just show the following information:

  Problemereignisname:	APPCRASH
  Anwendungsname:	cc1plus.exe
  Anwendungsversion:	0.0.0.0
  Anwendungszeitstempel:	00000000
  Fehlermodulname:	cc1plus.exe
  Fehlermodulversion:	0.0.0.0
  Fehlermodulzeitstempel:	00000000
  Ausnahmecode:	c0000005
  Ausnahmeoffset:	0000000000923688
  Betriebsystemversion:	6.1.7601.2.1.0.256.48
  Gebietsschema-ID:	1031
  Zusatzinformation 1:	50fa
  Zusatzinformation 2:	50fa4f6a0bed1a7f9bb7018c9ff4ca3f
  Zusatzinformation 3:	7510
  Zusatzinformation 4:	751099e505bceb2fa8cbac2f21c93fb2

This issue was reported over one year ago. Was there any progress?
Comment 10 Andre Netzeband 2014-11-08 22:00:44 UTC
Once again the question: The original error report is around 1,5 years old. I can hardly believe that there has been absolutely no progress so far.
Comment 11 asmwarrior 2015-05-20 13:42:01 UTC
Today, I did the same test as in comment 6 with a more recent gcc 5.1(http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/dongsheng-daily/5.x/gcc-5-win32_5.1.1-20150512.7z/download), but I still get the same bad result.
Comment 12 asmwarrior 2015-05-22 02:37:58 UTC
Hi, I just did a test on the cygwin 32bit tool chain.
1, download the cygwin installer.
2, install  gcc-g++ 4.9.2 and boost 1.57 package
3, run the steps in comment 6, except that you don't need to add the "-ID:\mingw-builds\boost_1_55_0" in the build command, because we can use the boost library installed from the previous step. 
4, when building the pch files, I get a 318M pch.h.gch file
5, when building the object file, I get a 365K test.o file

So, this bug doesn't happen in the cygwin tool chain, and it looks like the bug only happens in the MinGW and MinGW-W64 tool chain.

Any ideas what is the reason of this bug? Maybe, someone can supply a debug version of g++, and let help to run under GDB.
Comment 13 asmwarrior 2015-05-22 07:31:12 UTC
I did some further test with the condition I stated in comment 11. That is gcc 5.1.
Now, I have pch.h.gch file (about 200M) already generated.
First thing, I try to see whether preprocessor works OK, so I add the "-E" option.
For test.cpp file
------
#include "pch.h"

int main()
{
	int a;
	int b;
	int c;
	a++;
	b++;
}
------
Run the command:
g++.exe -v -E -Wall -fexceptions  -g -march=core2 -Wall -ID:\mingw-builds\boost_1_55_0  -Winvalid-pch -include pch.h test.cpp -o have-include.i

Then I comment out the first line
------
//#include "pch.h"

int main()
{
	int a;
	int b;
	int c;
	a++;
	b++;
}
------
Then run the command below:
g++.exe -v -E -Wall -fexceptions  -g -march=core2 -Wall -ID:\mingw-builds\boost_1_55_0  -Winvalid-pch -include pch.h test.cpp -o no-include.i

Then I compare the result:
Both "have-include.i" and "no-include.i" are about 7M, I see the they are nearly the same, expect the "have-include.i" have two extra lines.

Here is the have-include.i
------
...
...
#pragma GCC diagnostic pop
# 1 "<command-line>" 2
# 1 "test.cpp"
# 1 "pch.h" 1
# 2 "test.cpp" 2

int main()
{
 int a;
 int b;
 int c;
 a++;
 b++;
}
-------
Here is no-include.i
------
...
...
#pragma GCC diagnostic pop
# 1 "<command-line>" 2
# 1 "test.cpp"



int main()
{
 int a;
 int b;
 int c;
 a++;
 b++;
}
------

Now, I try to build those .i files to object files with those command:
g++.exe -v -Wall -fexceptions  -g -march=core2 -Wall -c no-include.i -o no-include.o
g++.exe -v -Wall -fexceptions  -g -march=core2 -Wall -c have-include.i -o have-include.o
Result is:
I get the same result "no-include.o" and "have-include.o". (Yes, they are exactly same in every bytes)

Now, I did other test like below:
g++.exe -v -Wall -fexceptions  -g -march=core2 -Wall -ID:\mingw-builds\boost_1_55_0  -Winvalid-pch -include pch.h -c test.cpp -o have-include-c.o -save-temps

Here, I have "-save-temps" put in the command option, I get no "have-include-c.o" file generated, also I get an empty "test.ii" generated.
Here is the log:
------
...
...
 D:\mingw-builds\boost_1_55_0
 e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../include/c++/5.1.1
 e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../include/c++/5.1.1/i686-w64-mi
ngw32
 e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../include/c++/5.1.1/backward
 e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/include
 e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/include-fixed
 e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../i686-w64-mingw32/include
End of search list.


------

Now, if I remove the "-save-temps" option, and run below:
g++.exe -v -Wall -fexceptions  -g -march=core2 -Wall -ID:\mingw-builds\boost_1_55_0  -Winvalid-pch -include pch.h -c test.cpp -o have-include-c.o

Still no "have-include-c.o" file, but this time, the log message has some extra lines:
------
...
...
 D:\mingw-builds\boost_1_55_0
 e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../include/c++/5.1.1
 e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../include/c++/5.1.1/i686-w64-mi
ngw32
 e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../include/c++/5.1.1/backward
 e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/include
 e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/include-fixed
 e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../i686-w64-mingw32/include
End of search list.
GNU C++ (GCC) version 5.1.1 20150512 (i686-w64-mingw32)
        compiled by GNU C version 5.1.1 20150512, GMP version 5.1.3, MPFR version 3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: af290162d8f9d7b22486b8d9679fb0bb

------

So, it looks like happens after the preprocessor has successfully read the pch file, when it(cc1plus.exe) try to start the parsing, it get crashed, but under my Windows XP, I don't see any message or dialog shown up when it crashed.
Comment 14 asmwarrior 2015-05-23 02:22:41 UTC
The bug can be seen when "-E" and "-fpch-preprocess" is used together to generate a preprocessed file.
If I have a small pch file named "spch.h" and "spch.h.gch"(note the spch.h.gch size is about 47M), and if I have a test.cpp like below:
------
#include "spch.h"

int main()
{
	int a;
	int b;
	int c;
	a++;
	b++;
}
------

Then, run the command:
g++.exe -v -E -Wall -fexceptions  -g -march=core2 -Wall -ID:\mingw-builds\boost_1_55_0  -Winvalid-pch -include spch.h test.cpp -fpch-preprocess -o xxx.ii -ftime-report

I will get a xxx.ii containing such contents:
------
# 1 "test.cpp"
# 1 "D:\\mingw-builds\\test-51//"
# 1 "<built-in>"
# 1 "<command-line>"
#pragma GCC pch_preprocess "./spch.h.gch"
# 1 "test.cpp"
# 1 "spch.h" 1
# 2 "test.cpp" 2

int main()
{
 int a;
 int b;
 int c;
 a++;
 b++;
}
------

You see, the line "#pragma GCC pch_preprocess "./spch.h.gch"" is generated correctly, which means G++ load the pch file correctly. (That's what the -fpch-preprocess option used for, see: https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html)

But if I use a big pch file "pch.h.gch", and run the similar command line like above, I don't see any .ii file generated, which means G++ crashed before log out the line "#pragma GCC pch_preprocess ...".

By reading the source code, I see that in gcc-4.9.2\gcc\c-family\c-ppoutput.c, there is a function:

/* Load in the PCH file NAME, open on FD.  It was originally searched for
   by ORIG_NAME.  Also, print out a #include command so that the PCH
   file can be loaded when the preprocessed output is compiled.  */

static void
cb_read_pch (cpp_reader *pfile, const char *name,
	     int fd, const char *orig_name ATTRIBUTE_UNUSED)
{
  c_common_read_pch (pfile, name, fd, orig_name);

  fprintf (print.outf, "#pragma GCC pch_preprocess \"%s\"\n", name);
  print.src_line++;
}

So, the bug happens before the fprintf() function, maybe inside the c_common_read_pch function call. 

I would like to see anyone can supply a debug version of 32bit cc1plus.exe, so that I can hunt the bug further under GDB, because building the whole gcc tool chain is too difficult for me.