Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Following Code Causes Segfault in Clang

llvm.org

Post reply on HN
Print view View original

31–40 of 40 posts

Re: The Following Code Causes Segfault in Clang

#31

Post by andrewchambers »

andrewchambers wrote: post #9

Something tells me C++ isn't the best thing to implement a compiler with.

I guess I was being to harsh on the memory issues in C++.

In practice it is a non issue, because build scripts can run arbitrary code long before a memory corruption in the system compiler. And if you plan on running the code you just compiled, you must already trust the code.

Unless of course its a segfault in LLVM and not just clang. LLVM is used for JIT in web browsers now, not that there are really any suitable replacements for C++ right now.

Re: The Following Code Causes Segfault in Clang

#32

Post by andrewchambers »

Tloewald wrote: post #17
andrewchambers wrote: post #9

Something tells me C++ isn't the best thing to implement a compiler with.

FYI: 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.

I'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.

Re: The Following Code Causes Segfault in Clang

#33

Post by mateo411 »

nly wrote: post #24
golemotron wrote: post #21

Earlier quoted context omitted.

I modded you up because clang is written in C++ and even if I didn't know this I'd suspect it because segfaults in languages that are not weakly typed (i.e., C and C++) are incredibly rare. There are better languages to write compilers in. OCaml is one.

C++ probably isn't 'weakly typed', whatever that means.

C is weakly typed, because you can cast or set any variable to be a void *. Since C is weakly typed, then you can write a C++ program that is also weakly typed.

Re: The Following Code Causes Segfault in Clang

#34

Post by jwatte »

timshen wrote: post #16
jey wrote: post #3

Earlier quoted context omitted.

Yeah, maybe this is just a standard-conforming implementation of undefined behavior.

It's nothing to do with standard-conforming or not. A correct implementation shall never crash.

There 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...

Re: The Following Code Causes Segfault in Clang

#35

Post by archgoon »

udp wrote: post #18

Something I found last week that crashes with clang-503.0.40: template class foo { public: ~ foo() { } foo &operator = (const foo &rhs) { foo::~foo(); new (this) foo (rhs); return *this; } }; int main(int argc, char * argv[]) { foo a, b; b = a; }

This is the same bug.

Re: The Following Code Causes Segfault in Clang

#36

Post by lindig »

If your are looking for code to break a C compiler, you can try my tool 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;
    }

Re: The Following Code Causes Segfault in Clang

#37

Post by darkpore »

andrewchambers wrote: post #32
Tloewald wrote: post #17

Earlier quoted context omitted.

FYI: 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.

I'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.

lol - you're aware that most web browsers are written in C++?

Re: The Following Code Causes Segfault in Clang

#38

Post by andrewchambers »

darkpore wrote: post #37
andrewchambers wrote: post #32

Earlier quoted context omitted.

I'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.

lol - you're aware that most web browsers are written in C++?

Painfully aware.

You do understand what an ever increasing attack surface does?

Re: The Following Code Causes Segfault in Clang

#39

Post by nly »

yzzxy wrote: post #25
nly wrote: post #24

Earlier quoted context omitted.

C++ probably isn't 'weakly typed', whatever that means.

You probably aren't "qualified to make that statement", if you don't know what weak typing is and are too lazy to google it.

https://en.wikipedia.org/wiki/Strong_and_weak_typing

> In general, these terms do not have a precise definition. Rather, they tend to be used by advocates or critics of a given programming language, as a means of explaining why a given language is better or worse than alternatives.

Re: The Following Code Causes Segfault in Clang

#40

Post by hamburglar »

misnome wrote: post #5
hamburglar wrote: post #2

Is there some legitimate reason to want to have A's destructor called twice on a single instance?

Probably not, but the compiler crashing isn't a good way of notifying the user of that!

Ah, 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.
Post reply on HN