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

[d-bugmail at puremagic.com]

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



--- Comment #5 from Iain Buclaw <ibuclaw at ubuntu.com> 2011-03-06 04:49:31 PST ---
(In reply to comment #4)
> (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.
> 

Well, signals are != exceptions. :)

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

There are 2 alternatives I can think of instead of using 'hlt'

1) Throw an exception (goes against release mode).

2) Raise an alternate interrupt. Like 'hlt', these are single byte opcodes.

- int 0x3;  #BP will invoke SIGTRAP signal handler.
- ud2;      #UD will invoke SIGILL signal handler.

Regards

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