How to kill a web browser [LWN.net]

How to kill a web browser

Posted Oct 21, 2004 9:38 UTC (Thu) by nix (subscriber, #2304)
In reply to: How to kill a web browser by nathan
Parent article: How to kill a web browser

Definitely you can. The old `confused by earlier errors, bailing out' message in GCC, and the new `internal compiler error' messages are definitely crashes... Have a look at:
<http://gcc.gnu.org/bugzilla/buglist.cgi?keywords=ice-on-i...;

At the time of writing, that's 689 cases of crashing a C (and C++, Ada, Java, Fortran) compiler with invalid code. Add an &component=c to the end of that URI, and you find 56 examples of crashing the C compiler.

(Log in to post comments)

This is not a crash!

Posted Oct 21, 2004 15:21 UTC (Thu) by spudbeach (guest, #5837) [Link]

A "crash" is when a program completes incorrectly, often with a segfault. A compiler saying "giving up" isn't a crash -- it is a normal termination for bad input. No signal, no possibility of exploitation, and the user got some output that is useful.

This is not a crash!

Posted Oct 22, 2004 13:46 UTC (Fri) by nix (subscriber, #2304) [Link]

The old `bailing out' message was triggered, IIRC, by a SIGSEGV being caught. So there was a signal.

I doubt it could be regarded as exploitable, though. :)

How to kill a web browser

Posted Oct 22, 2004 0:10 UTC (Fri) by JoeBuck (subscriber, #2330) [Link]

Almost all of the GCC crashes occur when GCC itself detects an inconsistency and quits with an internal error. There are a few, though, where the compiler actually crashes because of internal corruption, but those are far rarer.

Cases where the application itself decides to abort aren't security risks (though they could possibly be used to create a denial of service attack if the app can be made to repeatedly shut itself down).

How to kill a web browser

Posted Oct 22, 2004 13:45 UTC (Fri) by nix (subscriber, #2304) [Link]

The internal-corruption crashes certainly are rare, now. I was really thinking of the days of egcs and before, when the `bailing out' message often *was* the result of a SIGSEGV being caught, if memory serves, and was really rather easy to trigger...

... and no, this isn't a security risk. (Who would execute a compiler in a security-critical environment anyway? The security risks are generally in the compiler's output when it succeeds :) )