digitalmars.D.bugs - [Issue 3208] New: setAssertHandler leads to segfault
- d-bugmail puremagic.com (27/27) Jul 24 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3208
- d-bugmail puremagic.com (28/28) Jul 25 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3208
- d-bugmail puremagic.com (13/15) Jul 25 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3208
- d-bugmail puremagic.com (9/9) Jul 25 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3208
- d-bugmail puremagic.com (12/12) Jul 27 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3208
http://d.puremagic.com/issues/show_bug.cgi?id=3208
Summary: setAssertHandler leads to segfault
Product: D
Version: 2.030
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: sean invisibleduck.org
ReportedBy: lutger.blijdestijn gmail.com
The following code produces a segmentation fault. If compiled with -g this does
not occur.
import core.exception;
void handleAssertion(string file, size_t line, string msg = null) {};
static this()
{
setAssertHandler( &handleAssertion );
}
void main()
{
assert(false);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 24 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3208
nfxjfg gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nfxjfg gmail.com
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 mov ebp,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 pop ebp
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: -------
Jul 25 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3208
Jarrett Billingsley <jarrett.billingsley gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jarrett.billingsley gmail.c
| |om
2009-07-25 07:55:57 PDT ---
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: -------
Jul 25 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3208 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: -------
Jul 25 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3208
Lutger <lutger.blijdestijn gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|druntime |DMD
AssignedTo|sean invisibleduck.org |nobody puremagic.com
Severity|normal |enhancement
PDT ---
Allright, I'd like to propose this as an enhancement.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 27 2009









d-bugmail puremagic.com 