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