Everyone (at least everyone who uses a compiled language) has faced compilation errors but how many times do you get to actually crash the compiler?
I've had my fair share of "internal compiler errors" but most went away just by re-compiling. Do you have a (minimal) piece of code that crashes the compiler?
I write the compiler we use, so it crashes sometimes.
easy.
// -*- C++ -*-
template <int n>
class Foo : public Foo<n+1>
{
};
int main(int, char*[])
{
Foo<0> x;
return 0;
};
ejgottl#luna:~/tmp$ g++ -ftemplate-depth-1000000 -Wall foo.cpp -o foo
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See `<URL:http://gcc.gnu.org/bugs.html>` for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
`<URL:file:///usr/share/doc/gcc-4.2/README.Bugs>`.
I haven't made GHC (a Haskell compiler) crash yet, but I've gotten it to error out with a
My brain just exploded.
I can't handle pattern bindings for existentially-quantified constructors.
It's pretty easy to work around, and you don't hit this unless you have some tricky (and usually wrong) design, but it probably wins as the best compiler error message ever.
VC catches it gracefully now, but in the mid 90's, this would crashed both Microsoft C++ and Borland C++ compilers:
struct MyClass
{
MyClass operator->() { return *this; }
};
int main(int argc, char* argv[])
{
MyClass A;
A->x;
}
An overloaded operator-> is intrinsically recursive. The function is expected to return a pointer, which oper-> is again applied to. This fragment made code generation infinitely recursive.
Actionscript 3.0:
switch(on_some_variable)
{
}
Empty switch = Kaboom!
Visual C++ 9.0 SP1
this just happened to me
------ Build started: Project: pdfp, Configuration: Debug Win32 ------
Compiling...
reader.cpp
xref.cpp
c:\projects\pdfp\xref.cpp(52) : fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'f:\dd\vctools\compiler\cxxfe\sl\p1\c\toil.c', line 8569)
To work around this problem, try simplifying or changing the program near the locations listed above.
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
Generating Code...
Build log was saved at "file://c:\Projects\pdfp\Debug\BuildLog.htm"
pdfp - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Well, this didn't actually crash the compiler -- It was merely a bug were VC++ wouldn't accept perfectly good code. (details provided here).
The odd this about it was that it was only triggered when three fairly obscure conditions were all met. Moving one line of code was all that was needed for an effective workaround. And one of the needed pre-conditions was "using namespace std;" which is widely discouraged in production code.
Nevertheless, messages asking how to fix the problem were a staple on Microsoft VC++ newsgroups. I couldn't figure out how so many people stumbled onto an obscure bug. So, eventually, I asked someone.....
The exact code needed to trigger the bug was an example in Stroustrup's "The C++ Programming Langauge". (*)
(*) Note, I'm not saying he did it on purpose. I sure he tested it under a UNIX variant of C++, and was completely unaware of it's affect on VC++.
I've seen a few compiler bugs in the C# compiler (all edge cases, all reported appropriately) and confirmed some crashes provoked by other people.
The scariest compiler (of a sort) bug I've encountered was a JIT bug in one version of Java. It was quite reproducible, but caused the VM to go down. Adding a fairly no-op statement (I can't remember exactly what offhand - possibly just declaring an extra local variable with an initial value) moved it away from whatever corner case it happened to be - and it was fixed in a later version.
This crashed the C64 BASIC:
PRINT 0 + "" +- 0
Yes, especially when it's an old or undermaintained compiler (GCC 2.95, Tendra in C++ mode). I don't keep the pieces of code around, though.
Visual C++ 5. 'Nuff said.
Oops, forgot an 'e' in typedef and crashed the compiler.
typdef struct kGUIColor GameColor;
c:\source\kgui\samples\space\space.cpp(35) : fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'msc1.cpp', line 2708)
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
Today VS2003SP1 gave me a C1001 (Internal Compiler Error) complaining about compiler file 'msc1.cpp', line 2708) because of this:
struct PATTERN {
…
};
It turns out that the problem was that the structure name I was trying to define (PATTERN) was already a typedef in the GDI for a brush type. However instead of telling me that the symbol is already defined (like it does for most other things) it not only did not point to the structure as the problem—I narrowed the problem down to it by selectively commenting out blocks until the error went away—but it also gave me the aforementioned cryptic error which has nothing to do with the file specified—which I can’t even find to examine the line in question. :|
I was able to reproduce it with the following code:
typedef int SOMETHINGOROTHER;
struct SOMETHINGOROTHER {};
> fatal error C1001: INTERNAL COMPILER ERROR
> (compiler file 'msc1.cpp', line 2708) …
Whereas the following code gives the expected error message:
struct SOMETHINGOROTHER {};
typedef int SOMETHINGOROTHER;
> 'SOMETHINGOROTHER' : redefinition; different basic types
Clearly the problem is in the compiler’s structure handling routine.
I wonder if VS2005+ do better…
Here's a way to crash the VS2003 C++ compiler.
typedef map<int,int> Tmap;
private: Tmap; * m_map;
This will result in a crash and the following error message
fatal error C1001: INTERNAL COMPILER
ERROR (compiler file 'msc1.cpp', line
2708) Please choose the Technical
Support command on the Visual C++ Help
menu, or open the Technical Support
help file for more information
Remove the semicolon immediately after Tmap (second line which defines m_map) to eliminate the error.
In a project I was working in, some specific usages of Boost Lambda expressions could make the Visual C++ compiler crash. (We were using Visual Studio 2003)
The compiler would only crash during the release build, a debug build would work fine.
There had been a religious war raging through the team about the appropriate usage of the lambda libraries, I was almost grateful that the compiler settled it for us. :-)
In version 1.2.x of the Mono C# compiler would crash quite a bit with complicated code (if I remember correctly, nested anonymous delegates). Fortunately with 2.x release, I haven't seen any crashes.
At my previous job we had a simulator which was notorious for being able to crash (ICE) compilers or cause them to generate incorrect code. And when the code actually was generated correctly, ofter the compiler took 15 minutes for a single source file. Visual Studio was never (as long as I worked there) able to compile the simulator core.
The core was automatically generated from a DSL, and the generated code often pushed the compiler to its limits.
Upgrading to a new version of GCC often caused widespread nervosity: will the new version work?
Thanks to #Nick, this crashes VS2005.
template<typename Res, typename T>
Res operator_cast(const T& t)
{
return t.operator Res();
}
int main()
{
return operator_cast<int>(0);
}
I've crashed a compiler before by running it out of memory.
Give a DOS compiler about 0.5mb of source code. Crunch.
When you get a message "Catastrophic Failure" you know you're trying....
Michael
I use both pcc and gcc to compile my old OS project.
I found a bug with how both pcc and gcc handle a non-trivial piece of code and it crashed pcc.
(chars are signed on my platform)
struct{
char myvalue:1;
}mystruct;
pcc crashed because all bitfield values must be int though, so it's really more buggy there, but gcc handles it wrongly. See, if you think about it, it is signed, but only has room for one bit. So therefore, it only can store 0 and -1. Well, gcc handles it wrong by storing 0 or 1.
VC++ has crashed on me when compiling C++ if template usage is messed up (e.g., missing out on a closing ">").
I did. Some Delphi versions (lets say #4) crashed very often with cryptic error messages.
The newer versions (2006 and more) are stable but not rock solid. (7 was great in that case).
Compiler crashes often occur with large edits, and debug sessions of complex projects (lots of dll's). Most of the time a restart of the ide is enough. But sometimes you need to restart the PC.
O and I once crashed OS2 along with the compiler because the swapfile grew too large.
One time when I used the generators example from the Python docs, it broke the version of Python we were using. The same week, one of my colleagues managed to misuse the FFI such that any calculation involving the number 3 would crash python.
The Microsoft Xbox 360 compiler can crash easily. I was given source code with Japanese comments and when converted to regular text one of the last characters on the line was a '\' so it continued the comment onto the next line. If the next line was a switch command, then the compiler crashes.
//wierd japanese characters here %^$$\
switch(n)
{
case 0:
.....
break;
case 1:
.....
break;
}
I have crashed Delphi 7 many times asking it to compile legacy dos code.
The prime culprit seems to be any qualification of something as being in the system unit. This won't always blow it up but when it blows up on such stuff I look through and rewrite anything that requires such an override and the problem goes away.
The blowups are 100% reproduceable but I have never managed to make a simple test case. It doesn't actually crash the compiler most of the time, you usually get an error that has nothing to do with the problem and may be hundreds of lines from it. The environment is destabilized, save and exit is ok but don't think of doing anything else.
Back in the stone age with Borland Pascal 7 (the last dos version) I broke it many times. No crash, just incorrect and inconsistent code emission. I finally learned to keep the .EXE (not counting debug info) below 3mb. The farther beyond that I went the more unstable it got.
I've crashed VC++ a number of times, usually with template code. But that's not the most interesting crash...
I crashed the VS2005 Team System compiler with the /analyze option compiling my shared code library which compiled without error without the switch, and on VS2008 with and without the switch. Of course MS wasn't very interested because it was a bug in the old version of the compiler, but I thought it was pretty interesting.
I managed to segfault the Python interpreter. Of course, I was working on a C extension at the time and getting it not-quite-right.
It doesn't happen as much as it used to, but occasionally the ASP.net precompiler has issues - I haven't seen it personally, but I have fixed a problem on another project once where they had name clashes because they weren't using namespaces properly (caused compiler crashes) during pre-compile.
In the good old days (unmanaged MSVC++) we had the odd compiler crash usually due to linking in external static win32 classes (.lib) and a couple of odd bits of code occasionally caused issues, but these were all picked up very quickly.
I don't know if I would call it crashing, but sdcc (Small Device C Compiler) fails at compiling code formed in a particular way:
Target: 8051
Code had to execute in a 512 byte cache loaded from an external tester
Tester is in control and stores the code - cache can't fetch the next page
No function calls allowed - the PC (program counter) would skip to a place not resident in cache; preprocessor macros were used to accomplish modular coding practice
Jumps (branching) allowed if it doesn't skip out of the cache
No const values - in the data section of the program code which causes code in cache to fetch something not in cache - preprocessor constant (#define) OK here
The preprocessor macros are unrolled resulting in flat, but large code - everything in main(); execution skips the startup code (setting up the stack, etc) and starts at the beginning of main()
Relevant part of this answer:
Occasionally, sdcc would refuse to compile syntactically correct code, with a message about running out of memory. This even happened compiling on 64-bit boxes with 8GB of RAM.
The solution in these cases was to split the firmware into separate pieces and compile them separately and execute them separately. The pieces may have been able to be linked back together, but at that point it didn't matter.
I didn't try it, but the Keil 8051 compiler probably could have handled the problematic code.
Related
I am currently trying to solve a reversing challenge, where c code is compiled for a 32bit linux system.
To solve this challenge I am trying to make use of ghidra but am faced with a few issues. A bit of a summary what I have done up to this point:
I have two OS available to me, one 64bit Linux System on my Laptop and this 64bit Windows 10. Apparantly the programm was compiled with gcc without a -g option making ghidra fail to debug the programm. Manually debugging it with gdb in Terminal is possible but terrible to use (at least for me).
So all I can do is look at the assembler code in the CodeBrowser of Ghidra and its respective decomipled c code. With that I got to understand that some of the instructions are decrypted during the runtime of the programm and in order to further analyse the code, I want to be able to execute parts of the instructions to slowly but surely decrypt and understand the hidden parts of the programm.
That being said, the only issue here is that I do not know how I can do that. I have noticed that ghidra has the ability to run java code, but all the examples I looked at that were provided by ghidra allow me to only patch hardcoded instructions into the programm but not to actually execute/evaluate them.
My specific issue at hand is following part of the programm (green marked part):
Ghidra has all the knowledge it needs to execute this part and I just do not know how to do that. I could of cause do it by hand, but that is just boring and not really why I am doing these challenges and that is the same reason as why I am not looking for finished scripts that unpack this programm for me but for a way to execute my analysis.
Finally to summarize my question: I am asking for a way to execute the green marked decrypting part of the targeted programm in ghidra without starting the debugger (since the ghidra debugger keeps failing on me).
I think you are mixing up a few things here. You say:
the programm was compiled with gcc without a -g option making ghidra fail to debug the programm
The debug information added with -g makes it easier to analyze and debug a program because you have information that would have otherwise have to be recovered by reverse engineering. This should not have an influence on whether you can run the program under a debugger in the first place, and as you noted running it with gdb in the terminal works. The Ghidra debugger basically just runs gdb in the background and attaches to it to exchange information, so it should work.
You have a few options now:
1. Get the Ghidra Debugger to run with this binary
Whatever issue you are encountering with the Ghidra debugger is probably a valid question for https://reverseengineering.stackexchange.com/
From then on you can pursue your initial plan to solve this via debugging.
2. Write a GhidraScript to reimplement the decryption
Understand the basic idea of what you recognized correctly as some kind of decryption loop. Then you can use one of Ghidra's scripting options[0] to write a simple script that reimplements this decryption, but writes the decrypted values to the Ghidra memory directly.
Any scripting language will obviously include basic arithmetic operations like + -, and xor and loops, and the Ghidra API provides the functions byte getByte(Address address) and setByte(Address address, byte value). If you encounter any issues or API questions while writing this script that will also be a valid follow up question for the RE Stack Exchange.
This approach has the advantage that you can then statically analyse the resulting data inside Ghidra again, e.g. disassemble the resulting code.
[0] Ghidra natively supports Python 2.7 and Java based Scripts and a rudimentary Python REPL, but there are other options like Jupyter and Script based Kotlin or Ruby, Kotlin and Clojure Scripts
I wanted to read generated opt codes for my simple program:
function test() {
const i = 2845884;
const k = 3;
return i == 2845884 ? k : 7;
}
test();
I found this gist that says that I need to build d8 from sources and run it with --trace-opt-verbose flag.
https://gist.github.com/kevincennis/0cd2138c78a07412ef21
That approach doesn't work for me neither other approaches I found on the web. Looks like all current solutions are outdated.
How can I see what opt codes will be generated for this program?
How can I see what opt codes will be generated for this program?
For this program, you are already seeing all optimized code, because no optimized code will be generated for it, because it doesn't run anywhere near long enough for optimized compilation to be worth the effort.
In general, to print optimized code that V8 generates, you need three things:
(1) A binary that has disassembler support. This is on-by-default in Debug and "optdebug" builds; for Release builds you need the GN arg v8_enable_disassembler = true.
(2) The command-line flag --print-opt-code.
(3) A function that runs hot enough to get optimized.
Try calling your test() in a loop. If you still don't see anything, run the loop more often.
(The threshold varies depending on V8 version, test program size and behavior, and due to background compilation possibly also your hardware, so there is no general rule-of-thumb number I could state here. For one-liner functions, expect to need several thousand calls.)
To answer your other question: yes, V8's optimizing compiler supports constant folding, and your test program will be folded to just return 3.
Side notes:
I found this gist that says that I need to build d8 from sources and run it with --trace-opt-verbose flag.
--trace-opt-verbose has never printed optimized code, and the gist you linked doesn't claim that it does. (That said, that gist makes a bunch of rather dubious claims, so it's not a particularly good source to begin with.)
Looks like all current solutions are outdated.
Or slightly more accurately: that one gist didn't solve your problem.
On SO alone, you could have found How to print the compiled instructions in V8 engine? or V8 will not print out disassembly or Are there ways to see the assembly code for the code generated by any of the JavaScript jits, especially V8's?, all dealing with variations of this question.
None of this has changed recently; the build flag is a requirement since at least 2014, the command-line flag as well as the fact that optimization only kicks in after a while have been unchanged since at least 2011.
FWIW, the easiest way to build V8 yourself is to follow the official documentation. The gm.py helper script used by that flow even sets the v8_enable_disassembler flag for you automatically.
I have a 64bit MFC application, in which I use crash reporting. The method is based on this article:
http://www.codeproject.com/KB/debug/XCrashReportPt1.aspx?display=Print
So I have a __try - __except wrapper frame around AfxWinMain.
Last year it seemed to work well (I mean on different operating systems and also with 32 bit and 64 bit application).
Let's take this exception providing code part:
void CMyDig::Foo()
{
std::vector<int> v;
int i = v.at(42);
}
When I write this code inside a dialog's message-handler, for example a button's clickhandler called Foo, then the exception is not caught in AfxWinMain.
If I write the same to a global function, it passes the exception to AfxWinMain.
Now we have this strange issue:
On some computers the dialog's case also generates the crash report(enters the __except block in afxwinmain), but others no. I managed to create a crash report on win7 64-bit, but the same program on win8, win8.1 and another win7 64bit doesn't make the report!
I compile with vs2010, and in code generation options, the "enable c++ exceptions" is set to EHsc (as last year, when it was working well).
Thanks for any ideas!
Attila
Wouldn't be easier to just define SetUnhandledExceptionFilter to create the crash report.
In this case you don't need such a __try / __except block
WndProcs have their own __try __except blocks and some of the exceptions are handled by themselves.
But anyhow. I never had problems with an exception filter.
My routines usually create a crash dump (minidump) and terminate. I always felt that this bare information is never enough for our technical stuff to find problems.
I'm using CUDA 5.5 and my compiler is VC2012. My projects consists of 2 .cu files. I need to use dynamic parallelism so I have enabled "Generate relocatable device code" option. As soon as this option is enabled I get the following linking error:
error LNK2001: unresolved external symbol __fatbinwrap_54_tmpxft_0000110c_00000000_8_cuda_device_runtime_cpp1_ii_5f6993ef
If I turn that option off the error disappears. The error does not depend on the contents of the files - if I comment out everything in them (#if 0 .... #endif so that they are essentially empty files) I still get the same error.
Update: I installed VC2010, and I still get the exact same error message!
Update 2: I got really tired with this whole thing so I took a dynamic parallelism sample project from VC2010 from the SDK samples (cdpSimplePrint), replaced the files in it and compiled. The issue is gone. Tried to compare the settings between the two projects, but I couldn't find anything. I don't know what caused it, but frankly, at this stage I don't care already, as long as I have a workaround.
Check that you are linking with the cudadevrt library, see the "Compiling and Linking" section in the CUDA Dynamic Parallelism Programming Guide for more info.
I am attempting to modify a GPL program written in C. My goal is to replace one method with a CUDA implementation, which means I need to compile with nvcc instead of gcc. I need help building the project - not implementing it (You don't need to know anything about CUDA C to help, I don't think).
This is my first time trying to change a C project of moderate complexity that involves a .configure and Makefile. Honestly, this is my first time doing anything in C in a long time, including anything involving gcc or g++, so I'm pretty lost.
I'm not super interested in learning configure and Makefiles - this is more of an experiment. I would like to see if the project implementation goes well before spending time creating a proper build script. (Not unwilling to learn as necessary, just trying to give an idea of the scope).
With that said, what are my options for building this project? I have a myriad of questions...
I tried adding "CC=nvcc" to the configure.in file after AC_PROG_CC. This appeared to work - output from running configure and make showed nvcc as the compiler. However make failed to compile the source file with the CUDA kernel, not recognizing the CUDA specific syntax. I don't know why, was hoping this would just work.
Is it possible to compile a source file with nvcc, and then include it at the linking step in the make process for the main program? If so, how? (This question might not make sense - I'm really rusty at this)
What's the correct way to do this?
Is there a quick and dirty way I could use for testing purposes?
Is there some secret tool everyone uses to setup and understand these configure and Makefiles? This is even worse than the Apache Ant scripts I'm used to (Yeah, I'm out of my realm)
You don't need to compile everything with nvcc. Your guess that you can just compile your CUDA code with NVCC and leave everything else (except linking) is correct. Here's the approach I would use to start.
Add a 1 new header (e.g. myCudaImplementation.h) and 1 new source file (with .cu extension, e.g. myCudaImplementation.cu). The source file contains your kernel implementation as well as a (host) C wrapper function that invokes the kernel with the appropriate execution configuration (aka <<<>>>) and arguments. The header file contains the prototype for the C wrapper function. Let's call that wrapper function runCudaImplementation()
I would also provide another host C function in the source file (with prototype in the header) that queries and configures the GPU devices present and returns true if it is successful, false if not. Let's call this function configureCudaDevice().
Now in your original C code, where you would normally call your CPU implementation you can do this.
// must include your new header
#include "myCudaImplementation.h"
// at app initialization
// store this variable somewhere you can access it later
bool deviceConfigured = configureCudaDevice;
...
// then later, at run time
if (deviceConfigured)
runCudaImplementation();
else
runCpuImplementation(); // run the original code
Now, since you put all your CUDA code in a new .cu file, you only have to compile that file with nvcc. Everything else stays the same, except that you have to link in the object file that nvcc outputs. e.g.
nvcc -c -o myCudaImplementation.o myCudaImplementation.cu <other necessary arguments>
Then add myCudaImplementation.o to your link line (something like:)
g++ -o myApp myCudaImplementation.o
Now, if you have a complex app to work with that uses configure and has a complex makefile already, it may be more involved than the above, but this is the general approach. Bottom line is you don't want to compile all of your source files with nvcc, just the .cu ones. Use your host compiler for everything else.
I'm not expert with configure so can't really help there. You may be able to run configure to generate a makefile, and then edit that makefile -- it won't be a general solution, but it will get you started.
Note that in some cases you may also need to separate compilation of your .cu files from linking them. In this case you need to use NVCC's separate compilation and linking functionality, for which this blog post might be helpful.