[Issue 5517] SEGV: assert(false) in release mode

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=5517



--- Comment #4 from Don <clugdbug at yahoo.com.au> 2011-03-05 18:28:56 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > Some further detail: 0xF4, the HLT opcode, is a privileged instruction; it
> > doesn't actually get executed. Instead, a Privileged Instruction hardware
> > exception is raised. I would expect Linux to turn this into SIGILL. So I would
> > expect an exit code of 132, if nothing is done to process it. There is no way
> > it should give a SEGV.
> >
> 
> If I was going off what I recall, I would have said that when a program
> receives the hlt instruction; it just stops executing instructions until there
> is an interrupt (in other words it just floats off in an undefined space).

That's what it does in ring 0 (ie, inside the kernel). But outside the kernel,
it's a privileged instruction, which generates a hardware 'illegal instruction'
interrupt.


> But I've looked it up, and HLT invokes SIGSEGV signal afterall...

Wow. Then Linux is just wrong. It should definitely be SIGILL. There's no
memory access violation.

> > On Windows, druntime checks the offending instruction, and if it is HLT, it is
> > identified as a runtime assert(0).
> 
> So on Windows, the runtime has a bespoke signal handler?

Everything you'd call a signal on Linux, is just a system exception on Windows.
D's exception handling uses the exact same mechanism. 
On all platforms, main is surrounded by a catch(...) which displays error
messages from any uncaught exceptions.
On Windows, this includes hardware faults as well as D-generated exceptions.

The impression I get from the little I know of Unix signal handling, it seems
to be one of the few things that Unix got horribly wrong. Windows structured
exception handling is brilliant (albeit almost completely undocumented!) I am
extremely impressed with it. For example, there's no restrictions on what you
can do inside an exception handler.
So there's probably more challenges for the *nix implementation of a lot of
this stuff.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------