paltest_pal_sxs_test1 failing on NetBSD

[krytarowski]

Currently paltest_pal_sxs_test1 is disabled on FreeBSD. I would like to know why?

Should I disable it on NetBSD as well? Is it testing crucial functionality?

[krytarowski]

@jkotas @janvorli

Related to https://github.com/dotnet/coreclr/issues/2090. That issue has up-for-grabs label, so we can probably take a stab at it.

[krytarowski]

Thanks. For now I will push a patch to disable this test on NetBSD as well and try to work with @mikem8361 towards investigating it.

[krytarowski]

This functionality is critical for CoreFX tests.

Part of dlltest1.cpp.i

extern "C"
int DllTest1()
{
    Trace("Starting pal_sxs test1 DllTest1\n");

    { void* __param = 0; auto tryBlock = [](void* unused) {
    {
        volatile int* p = (volatile int *)0x11;

        bTry = 1;
        *p = 1;

        Fail("ERROR: code was executed after the access violation.\n");
    }
    }; const bool isFinally = false; auto finallyBlock = []() {}; EXCEPTION_DISPOSITION disposition = -1; auto exceptionFilter = [&disposition, &__param](PAL_SEHException& ex) { disposition = 1; do { if (!(disposition != -1)) { PAL_fprintf ((PAL_get_stderr(0)), "ASSERT FAILED\n" "\tExpression: %s\n" "\tLocation:   line %d in %s\n" "\tFunction:   %s\n" "\tProcess:    %d\n", "disposition != EXCEPTION_CONTINUE_EXECUTION", 40, "/tmp/pkgsrc-tmp/wip/coreclr-git/work/coreclr/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/dlltest1.cpp", __FUNCTION__, GetCurrentProcessId()); DebugBreak(); } }while (0); return disposition; }; try { CatchHardwareExceptionHolder __catchHardwareException; auto __exceptionHolder = NativeExceptionHolderFactory::CreateHolder(&exceptionFilter); __exceptionHolder.Push(); tryBlock(__param); } catch (PAL_SEHException& ex) { if (disposition == -1) { exceptionFilter(ex); } if (disposition == 0) { throw; }
    {
        if (!bTry)
        {
            Fail("ERROR: PAL_EXCEPT was hit without PAL_TRY being hit.\n");
        }


        if (ex.ExceptionRecord.ExceptionInformation[1] != 0x11)
        {
            Fail("ERROR: PAL_EXCEPT ExceptionInformation[1] != 0x11\n");
        }

        bExcept = 1;
    }
    }; if (isFinally) { try { tryBlock(__param); } catch (...) { finallyBlock(); throw; } finallyBlock(); } };

    if (!bTry)
    {
        Trace("ERROR: the code in the PAL_TRY block was not executed.\n");
    }

    if (!bExcept)
    {
        Trace("ERROR: the code in the PAL_EXCEPT block was not executed.\n");
    }


    if(!bTry || !bExcept)
    {
        Fail("DllTest1 FAILED\n");
    }

    Trace("DLLTest1 PASSED\n");
    return PASS;
}

On NetBSD this tests fails because there is thrown and not caught exception (it's C++ exception with "throw").

@janvorli @jkotas have you got pointers what may be wrong/missing? The same issue is likely on FreeBSD.

[krytarowski]

$ LD_LIBRARY_PATH=. ./paltest_pal_sxs_test1  
PAL_SXS test1 SIGSEGV handler 0x0
Starting pal_sxs test1 DllTest2
terminate called after throwing an instance of 'PAL_SEHException'
Abort (core dumped)

[krytarowski]

DllTest1 fails the same way -- it doesn't matter that there are two DllTests. Calling just one or the other results in the same termination.

[janvorli]

@krytarowski I would try to run it under a debugger with breakpoints set to __cxa_throw and __cxa_begin_catch. Then you would see exactly which throw was not being caught and where each throw is caught.

[krytarowski]

GDB/LLDB doesn't want to attach to __cxa_throw neither __cxa_begin_catch. I checked that these symbols do exist in libstdc++.

[krytarowski]

C++ exceptions may be caught:
        catch throw               - all exceptions, when thrown
        catch catch               - all exceptions, when caught

Doesn't work either. I will try to investigate it.

[janvorli]

That's strange, it works fine on Linux, I've been using it a lot for debugging in the past. Maybe the function names have different number of underscores or something?

[krytarowski]

$ nm /usr/lib/libstdc++.so|grep -E 'cxa_throw|begin_catch'
0000000000081b17 T __cxa_begin_catch
0000000000080c2a T __cxa_throw

[krytarowski]

OK, I know what was going on. I had to first load library and make it sound to GDB:

$ LD_LIBRARY_PATH=. gdb --args ./paltest_pal_sxs_test1  
GNU gdb (GDB) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./paltest_pal_sxs_test1...done.
(gdb) b __cxa_throw
Function "__cxa_throw" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) r
Starting program: /tmp/pkgsrc-tmp/wip/coreclr-git/work/coreclr/bin/obj/NetBSD.x64.Debug/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/paltest_pal_sxs_test1 
PAL_SXS test1 SIGSEGV handler 0x0
Starting pal_sxs test1 DllTest2

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 1]
0x00007f7ff74074f4 in DllTest2::$_1::operator() (this=0x7f7fffffd9d8, unused=0x0)
    at /tmp/pkgsrc-tmp/wip/coreclr-git/work/coreclr/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/dlltest2.cpp:36
36              *p = 2;                                 // Causes an access violation exception
(gdb) b __cxa_throw
Breakpoint 1 at 0x7f7ff5c80c2a: file /usr/src/external/gpl3/gcc.old/dist/libstdc++-v3/libsupc++/eh_throw.cc, line 62.
(gdb) b __cxa_begin_catch
Breakpoint 2 at 0x7f7ff5c81b17: file /usr/src/external/gpl3/gcc.old/dist/libstdc++-v3/libsupc++/eh_catch.cc, line 41.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tmp/pkgsrc-tmp/wip/coreclr-git/work/coreclr/bin/obj/NetBSD.x64.Debug/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/paltest_pal_sxs_test1 
PAL_SXS test1 SIGSEGV handler 0x0
Starting pal_sxs test1 DllTest2

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 1]
0x00007f7ff74074f4 in DllTest2::$_1::operator() (this=0x7f7fffffd9d8, unused=0x0)
    at /tmp/pkgsrc-tmp/wip/coreclr-git/work/coreclr/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/dlltest2.cpp:36
36              *p = 2;                                 // Causes an access violation exception
(gdb)

[krytarowski]

It looks like SIGSEGV isn't caught.

I know that GNU libsigsegv works on NetBSD. I'm not sure how about GCJ.

[janvorli]

The GDB always catches the sigsegv first, you should just do "c" after that.