6 ms·
The Following Code Causes Segfault in Clang
- hamburglar 12y agoIs there some legitimate reason to want to have A's destructor called twice on a single instance?
- jey 12y agoYeah, maybe this is just a standard-conforming implementation of undefined behavior.
- timshen 12y agoIt's nothing to do with standard-conforming or not. A correct implementation shall never crash.
- Pacabel 12y agoThat's a pretty broad and idealistic claim to be making. "Correctness" itself isn't an absolute. While something either does or does not conform to whatever has been defined as "correct", it's perfectly fine for the defined "correct" behavior in a given situation to be a crash. In some cases a crash is the best that can be hoped for. Continuing on, even in an attempt to handle the failure more gracefully, can potentially be more harmful than just crashing.
- mikeash 12y agoI think you're confusing a crash in the generated program with a crash in the compiler itself. The latter is what's happening here.
- jwatte 12y agoThere is lots of undefined behavior that causes crashing, although usually of the target program, not the compiler. Crashing compilers is nothing new though. I can't count how many ICEs I used to run into in certain versions of certain other compilers...
- misnome 12y agoProbably not, but the compiler crashing isn't a good way of notifying the user of that!
- hamburglar 12y agoAh, I didn't realize the segfault was in the compiler itself. The title ("segmentation fault on calling destructor in member function") made it sound like the generated code crashed. Now that there's a gist of a callstack it's clearer.
- plorkyeran 12y agoThe usual reason for explicitly calling the destructor is if you then follow it up with a call to placement new to construct a new object in the same memory, but presumably that part was not relevant to the crash and so was not included in the minimal test case.
- danieljh 12y agoWhile we're at segfaulting compiler's, here's what I found just a few days ago: python -S -c 'print("void f(){} int main(){return (" + "*"*10**7 + "f)();}")' | gcc -xc - (This is legal C -- look it up. Don't argue with me over the practical relevance of this please)
- gizmo686 12y agoWhat were you doing that lead to you finding this?
- Torn 12y agoprinting lots of stars?
- deathanatos 12y agoThe C program doesn't print stars. It appears to just call f. It just dereferences f quite a bit before eventually calling it. (He's printing stars in Python simply because it's a more concise way to represent a million stars.)
- chrisdevereux 12y agoStack overflow?
- danieljh 12y agoYes, you're able to confirm this by setting: ulimit -s unlimited
- deathanatos 12y agoI will point out that there is a section called "Translation limits" that discusses how compilers can't really be excepted to compile every legal program, because they run in a machine with a finite amount of memory. > Both the translation and execution environments constrain the implementation of language translators and libraries. The following summarizes the language-related environmental limits on a conforming implementation; the library-related limits are discussed in clause 7. > The implementation shall be able to translate and execute at least one program that contains at least one instance of every one of the following limits: > 4095 characters in a logical source line Of course, it notes: > Implementations should avoid imposing fixed translation limits whenever possible. Note that these aren't strict limits, and don't really have an effect on the legality of your program, I feel it's more of a discussion of the limits imposed by reality, and what compilers must handle at a bare minimum. And honestly, I would hope most modern compilers would do better than the noted limits and I'd also hope for a decent error message, not "gcc: internal compiler error: Segmentation fault (program cc1)" (which is what the program generates). Last, > This is legal C Is it? You're returning the result of a function that returns void in a function that returns int (and even if main were void, I still don't think that's legal). Were gcc able to handle the abusive number of stars, it would say, <stdin>: In function ‘main’: <stdin>:1:23: error: void value not ignored as it ought to be (which is what it says if you remove some of the stars.) Granted, this can be corrected, and your example will still cause the same output. (Which doesn't seem nearly as interesting as the linked C++ code. I'd like to know why that causes a segfault. With yours, I'd like to know why you were doing that.)
- andrewchambers 12y agoSomething tells me C++ isn't the best thing to implement a compiler with.
- Tloewald 12y agoFYI: someone has modded you down because the compiler is crashing when it compiles the C++ code, not because it is written in any particular language.
- andrewchambers 12y agoI'm aware, I care because LLVM is being integrated in web browsers as part of the JIT engine, and clang uses LLVM as its backend. So any segfaults related to LLVM (though not this one in particular) make me worried about browser security.
- darkpore 12y agolol - you're aware that most web browsers are written in C++?
- andrewchambers 12y agoPainfully aware. You do understand what an ever increasing attack surface does?
- millstone 12y agoThis looks to be an assertion failure, i.e. code that was thought to be unreachable is not. So there's no evidence that any of the negatives of C++ (memory safety, etc.) are in play here.
- andrewchambers 12y agoIf that's the case I was being too harsh on clang.
- 12y ago
- archgoon 12y agoHmm... Unable to find instantiation of declaration! UNREACHABLE executed at SemaTemplateInstantiateDecl.cpp:4384! Not quite so unreachable... https://gist.github.com/cwgreene/d689f010619310dbbc77 https://gist.github.com/cwgreene/d689f010619310dbbc77 https://github.com/llvm-mirror/clang/blob/b310439121c875937d78cc49cc969bc1197fc025/lib/Sema/SemaTemplateInstantiateDecl.cpp#L4384 https://github.com/llvm-mirror/clang/blob/b310439121c875937d...
- udp 12y agoSomething I found last week that crashes with clang-503.0.40: template<class T> class foo { public: ~ foo() { } foo &operator = (const foo &rhs) { foo::~foo(); new (this) foo (rhs); return *this; } }; int main(int argc, char * argv[]) { foo<int> a, b; b = a; }
- archgoon 12y agoThis is the same bug.
- lindig 12y agoIf your are looking for code to break a C compiler, you can try my tool Quest https://github.com/lindig/quest https://github.com/lindig/quest. It tries to to generate code that shows that a C compiler handles parameter passing wrong. I usually run it in a loop, like here on Mac OS X 10.9.4 witch gcc: :quest $ gcc --version Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.3.0 Thread model: posix :quest $ while true; do > ./main.native -test gcc -n 1 > foo.c > gcc -O2 -o foo foo.c > ./foo || break > echo -n . > done ................................................................ ................................................................ ................................................. Assertion failed: (b32 == b43), function callee_b0f, file foo.c, line 128. Abort trap: 6 This means the tool found C code where parameter passing is not compiled properly. It took about 10 seconds to find this. The test case is pretty small: :quest $ wc foo.c 140 444 3485 foo.c The generated code that where the assertion checks that parameters are received correctly looks like this: static union bt8 * callee_b0f(struct bt4 *bp7, double *bp8, struct bt6 bp9, float bp10, struct bt7 bp11, double bp12, short int bp13, ...) { va_list ap; typedef int bd0; typedef struct bt0 bd1; typedef int bd2; typedef union bt3 bd3; bd0 b41; bd1 b42; bd2 b43; bd3 b44; /* seed: 2040 */ va_start(ap, bp13); QUEST_ASSERT(b34 == bp7); QUEST_ASSERT(b35 == bp8); QUEST_ASSERT(b36.b24.b18 == bp9.b24.b18); QUEST_ASSERT(b36.b24.b19 == bp9.b24.b19); QUEST_ASSERT(b36.b24.b20 == bp9.b24.b20); QUEST_ASSERT(b36.b24.b21 == bp9.b24.b21); QUEST_ASSERT(b36.b24.b22 == bp9.b24.b22); QUEST_ASSERT(b36.b24.b23 == bp9.b24.b23); QUEST_ASSERT(b36.b25 == bp9.b25); QUEST_ASSERT(b36.b26 == bp9.b26); QUEST_ASSERT(b37 == bp10); QUEST_ASSERT(b38.b27 == bp11.b27); QUEST_ASSERT(b39 == bp12); QUEST_ASSERT(b40 == bp13); b41 = va_arg(ap, bd0); b42 = va_arg(ap, bd1); b43 = va_arg(ap, bd2); b44 = va_arg(ap, bd3); QUEST_ASSERT(b30 == b41); QUEST_ASSERT(b31.b0 == b42.b0); QUEST_ASSERT(b32 == b43); QUEST_ASSERT(b33.b10.b1 == b44.b10.b1); va_end(ap); return b29; }