[Issue 3208] setAssertHandler leads to segfault

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=3208

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #5 from Dmitry Olshansky  ---
This now works but setAssertHandler is deprecated, heh:

//
import core.exception;

nothrow void handleAssertion(string file, size_t line, string msg = null) {}

static this() 
{ 
setAssertHandler(   ); 
}

void main() 
{ 
assert(false); 
}

--

[Issue 3208] setAssertHandler leads to segfault

[d-bugmail]

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


nfx...@gmail.com changed:

   What|Removed |Added

 CC||nfx...@gmail.com




--- Comment #1 from nfx...@gmail.com  2009-07-25 07:27:03 PDT ---
My guess is that the compiler generates code, that doesn't expect
assert(false); to actually return normally.

The assert(false) statement generates the following function, which apparently
does the job of actually calling _d_assert, if the assertion condition wasn't
fulfilled:

080495a8 _D2rt8__assertFiZv:
 80495a8:   55  push   ebp
 80495a9:   8b ec   movebp,esp
 80495ab:   50  push   eax
 80495ac:   ff 35 98 6a 06 08   push   DWORD PTR ds:0x8066a98
 80495b2:   ff 35 94 6a 06 08   push   DWORD PTR ds:0x8066a94
 80495b8:   e8 a7 8e 00 00  call   8052464 _d_assert
 80495bd:   5d  popebp
 80495be:   c3  ret

As you can see, the stack after the call _d_assert isn't cleaned up. There are
still 3 parameters on the stack. As far as I know, it's the caller's job to
clean up (_d_assert is declared as extern(C) and this is on Linux). This means
the ret statement would jump to a bogus memory position.

But I could be wrong.

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

[Issue 3208] setAssertHandler leads to segfault

[d-bugmail]

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


Jarrett Billingsley jarrett.billings...@gmail.com changed:

   What|Removed |Added

 CC||jarrett.billings...@gmail.c
   ||om




--- Comment #2 from Jarrett Billingsley jarrett.billings...@gmail.com  
2009-07-25 07:55:57 PDT ---
(In reply to comment #1)
 My guess is that the compiler generates code, that doesn't expect
 assert(false); to actually return normally.

You're probably right.  In my investigation I found the only way to *not* have
it crash was to throw an exception from the assertion handler.

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

[Issue 3208] setAssertHandler leads to segfault

[d-bugmail]

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





--- Comment #3 from Sean Kelly s...@invisibleduck.org  2009-07-25 11:33:31 
PDT ---
Yeah, DMD requires the assert handler to throw.  It's not an optimization I'm
particularly fond of, but it doesn't seem likely that this will change.  Since
this isn't a library issue, I suggest either closing the ticket or redirecting
it to Walter as an enhancement request for DMD.

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