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

           Summary: Throwing exception or assertion failure causes
                    segfault or memory error due to ASLR on Mac OS X 10.7
           Product: D
           Version: D2
          Platform: x86
        OS/Version: Mac OS X
            Status: NEW
          Keywords: EH, wrong-code
          Severity: blocker
          Priority: P2
         Component: druntime
        AssignedTo: nobody@puremagic.com
        ReportedBy: kennytm@gmail.com


--- Comment #0 from kennytm@gmail.com 2011-07-24 15:29:07 PDT ---
Test case 1

---------------
void main() {
    assert(0);
}
---------------

Running this program on 10.7 causes

  Bus error: 10

while the expected output should be something like

  core.exception.AssertError@y(2): Assertion failure
  ----------------
  5   y                                   0x00009265 onAssertError + 65
  6   y                                   0x000126ca _d_assertm + 30
  ...


Test case 2

---------------
void main() {
    throw new Exception("");
}
---------------

Running this program on 10.7 causes

  y(96008) malloc: *** error for object 0x14b060: pointer being freed was not
allocated
  *** set a breakpoint in malloc_error_break to debug
  Abort trap: 6

while the expected output should be something like

  object.Exception@y.d(2):
  ----------------
  5   y                                   0x00002320 _Dmain + 80
  6   y                                   0x00012dc7 extern (C) int
rt.dmain2.main(int, char**).void runMain() + 23
  ...

I suspect the stack-trace routine has some code depending on having no ASLR, so I've marked it a druntime problem.

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

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



--- Comment #1 from kennytm@gmail.com 2011-07-24 15:33:29 PDT ---
See also discussion in http://thread.gmane.org/gmane.comp.lang.d.general/61384.

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

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


klickverbot <code@klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@klickverbot.at


--- Comment #3 from klickverbot <code@klickverbot.at> 2011-07-24 16:29:15 PDT ---
I can confirm that my problems I reported on the NG seem to be caused by throwing exceptions as well.

As mentioned there, one can run »set disable-aslr off« in GDB to debug with ASLR enabled (otherwise, the crashes don't happen for me).

I have not had time to trace down what exactly is going on, but the issue seems to be related somehow to *throwing* exceptions, not catching them (I might have jumped to the wrong conclusions based off debugger output here, though).

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

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



--- Comment #4 from kennytm@gmail.com 2011-07-25 03:45:24 PDT ---
The segfault for case 2 happens in _d_throwc:

    // this is a catch handler (no finally)

    auto pci = cast(DCatchInfo *)(cast(char *)handler_table + phi.cioffset);
    auto ncatches = pci.ncatches;
    for (int i = 0; i < ncatches; i++)
    {
        auto ci = **cast(ClassInfo **)h;  // <--------- this line, *h == null

        auto pcb = &pci.catch_block[i];

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

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



--- Comment #5 from kennytm@gmail.com 2011-07-25 06:05:42 PDT ---
(In reply to comment #4)
> The segfault for case 2 happens in _d_throwc:
> 
>     // this is a catch handler (no finally)
> 
>     auto pci = cast(DCatchInfo *)(cast(char *)handler_table + phi.cioffset);
>     auto ncatches = pci.ncatches;
>     for (int i = 0; i < ncatches; i++)
>     {
>         auto ci = **cast(ClassInfo **)h;  // <--------- this line, *h == null
> 
>         auto pcb = &pci.catch_block[i];

Actually this is because I compile with -debug. Without -debug, _d_throwc is not no-return, causing originally unreachable statements e.g.

extern (C) void onAssertError( string file = __FILE__, size_t line = __LINE__ )
{
    if( assertHandler is null )
        throw new AssertError( file, line );
    assertHandler( file, line, null);   // <-------- this line
}

to be run.

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

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



--- Comment #6 from kennytm@gmail.com 2011-07-25 10:52:50 PDT ---
Actually my initial guess is right. The bug is due to corruption of the Throwable object -- in particular its classinfo -- from the defaultTraceHandler.

Using this:

    extern (C) void rt_setTraceHandler(Throwable.TraceInfo function(void*
ptr));
    void main() {
        rt_setTraceHandler(null);
        // rest of main

makes the segfault go away (and the stack trace too).

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

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


kennytm@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


--- Comment #7 from kennytm@gmail.com 2011-07-25 11:47:29 PDT ---
druntime pull #42.

https://github.com/D-Programming-Language/druntime/pull/42

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

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


kennytm@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Throwing exception or       |core.thread.thread_scanAll
                   |assertion failure causes    |doesn't scan the stack due
                   |segfault or memory error    |to ASLR on Mac OS X 10.7
                   |due to ASLR on Mac OS X     |
                   |10.7                        |


--- Comment #8 from kennytm@gmail.com 2011-07-26 03:14:47 PDT ---
The classinfo corruption is because the Throwable object is finalized prematurely. This is because the object is placed *on stack*, and the stack is not marked by the GC (!) using core.thread.thread_scanAll. Updated title to reflect the deeper cause.



Test case:
---------------
import core.stdc.stdio;
import core.thread;
void main() {
    void scan(void* from, void* to) {
        printf("%p -> %p\n", from, to);
    }
    size_t stackTop;
    thread_scanAll(&scan, &stackTop);
}
---------------

With ASLR:
   0x201fc0 -> 0x201fe4

Without ASLR:
   0xbffff924 -> 0xc0000000
   0x201fc0 -> 0x201fe4

Note that the stack is > 0xc000_0000 when ASLR is enabled.

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

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



--- Comment #9 from kennytm@gmail.com 2011-07-26 03:22:10 PDT ---
(In reply to comment #8)
> Note that the stack is > 0xc000_0000 when ASLR is enabled.

src/rt/memory.d:

extern (C) void* rt_stackBottom()
{
...
    else version( OSX )
    {
        return cast(void*) 0xc0000000;
    }


Mehhhhhhhhhhhhhh. Now everything is clear.

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

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



--- Comment #10 from kennytm@gmail.com 2011-07-26 04:01:40 PDT ---
Druntime pull #43.

https://github.com/D-Programming-Language/druntime/pull/43

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