paltest_pal_sxs_test1 failed on SmartOS x64

@janvorli

The following condition is failing on SmartOS x64:

runtime/src/coreclr/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/dlltest2.cpp

Lines 65 to 67 in 0fbd88e

    
           if (ex.GetExceptionRecord()->ExceptionInformation[1] != 0x22) 
        
           { 
        
               Fail("ERROR: PAL_EXCEPT ExceptionInformation[1] != 0x22\n");

Based on the discussion in #5158, I have captured the backtraces and printed the value of ex.GetExceptionRecord()->ExceptionInformation[1], which is different in every run, but never the expected 0x22: https://gist.github.com/am11/0bef90cabb1185d41a93c456e9083b4d.

cc @janvorli, if i try to comment this FAIL line it throws SIGABRT after few lines.

With line 67 commented out, the backtraces look like this: https://gist.github.com/am11/2464eff2db3a3ceadd3d56b976ee4a15.

The ExceptionInformation[1] comes from the sigsegv_handler, it passes siginfo->si_addr to common_signal_handler which then stores it into the ExceptionInformation[1].

I put the breakpoints in few places in sigsegv_handler and common_signal_handler, they get called as expected. At position src/coreclr/src/pal/src/exception/signal.cpp:516, the failure address (captured from siginfo->si_addr) was 96070, which is the same (wrong) one assigned to ExceptionInformation[1] and get compared with 0x22.

(gdb) c
Continuing.

Thread 2 hit Breakpoint 6, sigsegv_handler (code=11, siginfo=0xfffffc7fef0c3ef0, context=0xfffffc7fef0c3b90) at /home/am11/runtime/src/coreclr/src/pal/src/exception/signal.cpp:516
516	        if ((failureAddress - (sp - GetVirtualPageSize())) < 2 * GetVirtualPageSize())
(gdb) print failureAddress
$8 = 96070
(gdb) bt
#0  sigsegv_handler (code=11, siginfo=0xfffffc7fef0c3ef0, context=0xfffffc7fef0c3b90) at /home/am11/runtime/src/coreclr/src/pal/src/exception/signal.cpp:516
#1  0xfffffc7fef245df6 in __sighndlr () from /lib/64/libc.so.1
#2  0xfffffc7fef238c3b in call_user_handler () from /lib/64/libc.so.1
#3  0xfffffc7fef238f6e in sigacthandler () from /lib/64/libc.so.1
#4  0xffffffffffffffff in ?? ()
#5  0x000000000000000b in ?? ()
#6  0xfffffc7fef0c3ef0 in ?? ()
#7  0x000000000000000f in ?? ()
#8  0x0000000000000000 in ?? ()

Could it be the indication of data getting corrupted somewhere in libc?

The strange thing is also that the dlltest2 passes and then dlltest1 fails. They are exactly the same except of the address of failure. So maybe there is something that the first sigsegv screws in the kernel?
The sigsegv_handler is called directly by the kernel, so there should be nothing that libc could corrupt.
Can you try to swap the calls to DllTest1 and 2 to prove that it is not a problem of the DllTest1, but rather the fact that it gets called as the 2nd one?

I switched the call:

--- a/src/coreclr/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/exceptionsxs.cpp
+++ b/src/coreclr/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/exceptionsxs.cpp
@@ -84,12 +84,12 @@ int main(int argc, char *argv[])
 
     printf("PAL_SXS test1 SIGSEGV handler %p\n", oldAction.sa_sigaction);
 
-    if (0 != InitializeDllTest1())
+    if (0 != InitializeDllTest2())
     {
         return FAIL;
     }
 
-    if (0 != InitializeDllTest2())
+    if (0 != InitializeDllTest1())
     {
         return FAIL;
     }

rebuilt and ran the test under debugger without any breakpoints, it failed at same place:

(gdb) r
Starting program: /home/am11/runtime/artifacts/obj/coreclr/SunOS.x64.Debug/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/paltest_pal_sxs_test1 
[Thread debugging using libthread_db enabled]
PAL_SXS test1 SIGSEGV handler 0
Starting pal_sxs test1 DllTest2
[New Thread 1 (LWP 1)]

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xfffffc7fe7238653 in FailingFunction (p=0x22) at /home/am11/runtime/src/coreclr/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/dlltest2.cpp:34
34	    *p = 1;          // Causes an access violation exception
(gdb) c
Continuing.
ERROR: PAL_EXCEPT ExceptionInformation[1] != 0x22

[Inferior 1 (process 270    ) exited with code 01]
(gdb) bt
No stack.

I didn't mean to switch the initialization, I meant switching the calls to DllTest1 and DllTest2 functions.

Ah, right. the current order is DllTest2, DllTest1, DllTest2. I changed it to DllTest1, DllTest2, DllTest2 and got these results:

(gdb) r
Starting program: /home/am11/runtime/artifacts/obj/coreclr/SunOS.x64.Debug/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/paltest_pal_sxs_test1 
[Thread debugging using libthread_db enabled]
PAL_SXS test1 SIGSEGV handler 0
Starting pal_sxs test1 DllTest1
[New Thread 1 (LWP 1)]

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xfffffc7fe7d78653 in FailingFunction (p=0x11) at /home/am11/runtime/src/coreclr/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/dlltest1.cpp:34
34	    *p = 1;          // Causes an access violation exception
(gdb) c
Continuing.
ERROR: PAL_EXCEPT ExceptionInformation[1] != 0x11

[Inferior 1 (process 4173    ) exited with code 01]

DllTest2 is the first one (in master), that is why it was failing.

runtime/src/coreclr/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/exceptionsxs.cpp

Lines 97 to 100 in af36c6d

    
           // Test catching exceptions in other PAL instances 
        
           DllTest2(); 
        
           DllTest1(); 
        
           DllTest2();

Now I have put DllTest1 before 2, so DllTest1 is failing. Reordering has no effect.

Oh, I have somehow misread your debugging log, I have thought that the 1st one was succeeding and the 2nd one was failing.
So it seems that the OS is not filling in the siginfo->si_addr. Could it be an OS bug / feature?

I tried to isolate the issue, but could not reproduce it with this program: http://sprunge.us/6rXQXO

curl -s http://sprunge.us/6rXQXO | g++ -xc++ -std=c++11 - ; ./a.out

correctly prints: Address is: 0x22 (followed by Segmentation Fault (core dumped)).

Another strange thing is that line 65 condition only fails under the debugger, so it is not related to the actual test failure.

I commented out two out of three tests:

     // Test catching exceptions in other PAL instances
     DllTest2();
-    DllTest1();
-    DllTest2();
+//    DllTest1();
+//    DllTest2();

and got a crash on second sigsegv (in chaining):

PAL_SXS test1 SIGSEGV handler 0
Starting pal_sxs test1 DllTest2
DLLTest2 PASSED
Starting PAL_SXS test1 signal chaining
Segmentation Fault (core dumped)

(exit code 139)

the truss output looks like this: https://gist.github.com/am11/682e8f2a6b22a551e78004506774047f.

For comparison, here is the output of truss on FreeBSD x64: https://gist.github.com/am11/419ca311e2219c7f033155e2d2a44c6d

Added few print messages:

--- a/src/coreclr/src/pal/src/exception/signal.cpp
+++ b/src/coreclr/src/pal/src/exception/signal.cpp
@@ -251,6 +251,7 @@ void SEHCleanupSignals()
         restore_signal(SIGTRAP, &g_previous_sigtrap);
         restore_signal(SIGFPE, &g_previous_sigfpe);
         restore_signal(SIGBUS, &g_previous_sigbus);
+system("echo detaching pal internal sigsegv_handler");
         restore_signal(SIGSEGV, &g_previous_sigsegv);
         restore_signal(SIGINT, &g_previous_sigint);
         restore_signal(SIGQUIT, &g_previous_sigquit);
@@ -505,6 +506,7 @@ Parameters :
 --*/
 static void sigsegv_handler(int code, siginfo_t *siginfo, void *context)
 {
+system("echo pal internal sigsegv_handler");
     if (PALIsInitialized())
     {
         // First check if we have a stack overflow

--- a/src/coreclr/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/exceptionsxs.cpp
+++ b/src/coreclr/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/exceptionsxs.cpp
@@ -96,8 +96,8 @@ int main(int argc, char *argv[])
 
     // Test catching exceptions in other PAL instances
     DllTest2();
-    DllTest1();
-    DllTest2();
+//    DllTest1();
+  //  DllTest2();
 
     if (bHandler)
     {

on FreeBSD, we get:

PAL_SXS test1 SIGSEGV handler 0x0
Starting pal_sxs test1 DllTest2
pal internal sigsegv_handler
DLLTest2 PASSED
Starting PAL_SXS test1 signal chaining
pal internal sigsegv_handler
pal internal sigsegv_handler
pal_sxs test1: signal handler called
Signal chaining PASSED

on SmartOS, we get:

PAL_SXS test1 SIGSEGV handler 0
Starting pal_sxs test1 DllTest2
pal internal sigsegv_handler
DLLTest2 PASSED
Starting PAL_SXS test1 signal chaining
pal internal sigsegv_handler
pal internal sigsegv_handler
pal internal sigsegv_handler
pal internal sigsegv_handler
pal internal sigsegv_handler
pal internal sigsegv_handler
pal internal sigsegv_handler
pal internal sigsegv_handler
pal internal sigsegv_handler

and it continues, until process is terminated. Looks like the second sigsegv is initiating a never ending loop.

Does the runtime make use of in-process profiling through setitimer(ITIMER_PROF) and SIGPROF at all? If so, you may need to know about illumos bug 11494.

Also I would be very careful using system(3C) in a signal handler, even just for debugging. It is listed with an MT-Level attribute of Unsafe, which as per my reading of attributes(5) means it is not safe for use when multiple threads or signals are at play. If it were safe in a signal handler, I would expect it to be marked Async-Signal-Safe.

Afaict, setitimer is not used in coreclr code; the only use of setitimer is in one of the libunwind's test code, which is passing in upstream repo on SmartOS 2020. Also, SIGPROF is not used in coreclr (mono's POSIX library uses it in one of its APIs, but that is separate).

using system(3C) in a signal handler

Thanks, i have removed it. It was just for a quick sneak peek in the absence of printf/std::cout in that context (as PAL have some of the printer functions redefined, and tests are selectively linked with components).

The overview of this test failure is as follow:

libcoreclrpal.so: PAL library that has generic signal handlers for various signals, including SIGSEGV (and try/catch macros).
libpaltest_pal_sxs_test1_dll2.so: test lib that causes SIGSEGV for testing the handler. links with libcorepal.
paltest_pal_sxs_test1: the main / glue executable program, which links with libpaltest_pal_sxs_test1_dll2. It also defines its own signal handler for SIGSEGV, and expects the signal calls to chain when SIGSEGV is raised from the program's own code, but get stuck in an infinite loop of calling the first handler from PAL repeatedly and never calls the second one; as we can see in truss outputs, SmartOS vs. FreeBSD: paltest_pal_sxs_test1 failed on SmartOS x64 #35362 (comment).

ps - aside from pthread_setschedparam's inability to raise priority after lowering it from same value in case of non-privileged execution, which will likely be fixed upstream (and not too critical for now, as it only causes an assertion to fail in runtime code), this is the last failing (out of 716) PAL test.

To investigate this further, I see that your error message tells you that the expected value was not detected -- but it'd be good to print the value that was detected. In addition, our ucontext_t contains a uc_link member that may be NULL or may be a pointer to a parent signal handling context. It might help to walk up that chain, at least now during debugging, to see if the context you're looking for is further up.

It might help to ask the runtime linker which shared object a particular PC value comes from, too, to see which frame was interrupted; e.g.,

ucontext_t *uc = /* value from handler arguments */;

while (uc != NULL) {
        Dl_info_t dli;
        void *pc = (void *)(uintptr_t)uc->uc_mcontext.gregs[REG_PC];

        /* report pc */
        if (dladdr(pc, &dli) != 0) {
                /* report dli.dli_fname */
        }

        uc = uc->uc_link;
}

To investigate this further, I see that your error message tells you that the expected value was not detected -- but it'd be good to print the value that was detected.

I agree, we should emit the faulting address at src/coreclr/src/pal/tests/palsuite/exception_handling/pal_sxs/test1/dlltest2.cpp#67, in the failure message. However, that (error) condition only meets, when we run it under the debugger. The main problem in normal runs (when debugger is not attached) is with the signal handler chaining; if two signal handlers are associated with SIGSEGV, in different objects, then the first one keeps getting fired.

It might help to walk up that chain, at least now during debugging, to see if the context you're looking for is further up.

Thank you. I will try to walk up the chain to find more details. Looks like Linux/BSD also define uc_link in ucontext_t . Is there any well-known difference in Illumos around that area? We have an alias typedef ucontext_t native_context_t; and use that alias in PAL's common_signal_handler.

It might help to ask the runtime linker which shared object a particular PC value comes from, too, to see which frame was interrupted

Could you give some pointers on how -- which linker flag to set in order to obtain this shared object to PC/IP mappings? We are using Solaris native ld (as opposed to gld, which is in PATH of some distros but not necessarily present everywhere).

@jclulow

@jclulow, if you want to give it a try, you can use my branch with libunwind upgrade commit: feature/solaris/pal-test-fixes. On SmartOS 20200408T231825Z x64 userland, my steps are:

sudo pkgin -y install git mozilla-rootcerts cmake icu py37-expat gcc7 gmake gdb-7

git clone https://github.com/am11/runtime --branch feature/solaris/pal-test-fixes --single-branch --depth 1

# skip everything and only build coreclr with PAL tests
runtime/src/coreclr/build-runtime.sh -skipgenerateversion -nopgooptimize    \
    -cmakeargs -DCLR_CMAKE_BUILD_TESTS=1 -gcc

with seven physical cores, the build took 11m33.128s with clean tree; subsequent runs (without git-clean) are faster.

The test executable paltest_pal_sxs_test1 is in artifacts/obj/coreclr/SunOS.x64.Debug/src/pal/tests/palsuite/exception_handling/pal_sxs/test1 directory.

Failed again:

Failed tests:

coreclr linux arm Checked no_tiered_compilation @ (Alpine.314.Arm32.Open)Ubuntu.1804.ArmArch.Open@mcr.microsoft.com/dotnet-buildtools/prereqs:alpine-3.14-helix-arm32v7
coreclr linux arm Checked @ (Alpine.314.Arm32.Open)Ubuntu.1804.ArmArch.Open@mcr.microsoft.com/dotnet-buildtools/prereqs:alpine-3.14-helix-arm32v7
  - exception_handling.pal_sxs.test1

Error message:

***** Testing PAL *****

Running PAL tests from /root/helix/work/workitem/e
The list of PAL tests to run will be read from /root/helix/work/workitem/e/paltestlist.txt
PAL tests will store their temporary files and output in /root/helix/work/workitem/e/testoutputtmp.
Output files will be copied to /root/helix/work/workitem/e/testoutput at the end.

Running tests...

.................................................................Testing for Non 64 Bit Platforms 
.......................................hello world.foo 52foo 177777foo 177777foo 52foo 52foo  52foo 52 foo 52foo 052foo 052foo 052foo 52foo 52foo 37777777726foo 37777777726.foo 42foo 65535foo 65535foo 42foo 42foo  42foo 42 foo 42foo 042foo 042foo 42foo 42foo 42foo 4294967254foo 4294967254.foo 1234abfoo 1234abfoo 34abfoo 1234abfoo 1234567887654321foo  1234abfoo 1234ab foo 1234abfoo 01234abfoo 01234abfoo 0x1234abfoo 1234abfoo 1234abfoo ffffffd6foo ffffffd6.foo 1234ABfoo 1234ABfoo 34ABfoo 1234ABfoo 1234567887654321foo  1234ABfoo 1234AB foo 1234ABfoo 01234ABfoo 01234ABfoo 0X1234ABfoo 1234ABfoo 1234ABfoo FFFFFFD6foo FFFFFFD6.foo 2.560000e+02foo 2.560000e+02foo 2.560000e+02foo 2.560000e+02foo 2.560000e+02foo   2.560000e+02foo 2.560000e+02  foo 2.6e+02foo 2.56000000e+02foo 002.560000e+02foo 2.560000e+02foo +2.560000e+02foo  2.560000e+02foo -2.560000e+02foo -2.560000e+02.foo 2.560000E+02foo 2.560000E+02foo 2.560000E+02foo 2.560000E+02foo 2.560000E+02foo   2.560000E+02foo 2.560000E+02  foo 2.6E+02foo 2.56000000E+02foo 002.560000E+02foo 2.560000E+02foo +2.560000E+02foo  2.560000E+02foo -2.560000E+02foo -2.560000E+02.foo 2560.001000foo 2560.001000foo 2560.001000foo 2560.001000foo 2560.001000foo  2560.001000foo 2560.001000 foo 2560.0foo 2560.00100000foo 02560.001000foo 2560.001000foo +2560.001000foo  2560.001000foo -2560.001000foo -2560.001000.foo 2560foo 2560foo 2560foo 2560foo 2560foo  2560foo 2560 foo 3e+03foo 2.6e+03foo 2560.001foo 002560foo 2560.00foo +2560foo  2560foo -2560foo -2560.foo 2560foo 2560foo 2560foo 2560foo 2560foo  2560foo 2560 foo 3E+03foo 2.6E+03foo 2560.001foo 002560foo 2560.00foo +2560foo  2560foo -2560foo -2560.babaaaaa4204242042520524204242042420422.0e+002.010e+002.0E+002.010E+002.02.0103e+02256256256.013E+02256256256.01.foo barfoo barfoo barfoo barfoo barfoo barfoo   barfoo bafoo    bafoo bar  foo 00barfoo (null)foo (null)foo (null)foo (null)foo (null)foo (null).foo barfoo barfoo barfoo barfoo barfoo barfoo   barfoo bafoo    bafoo bar  foo 00barfoo (null)foo (null)foo (null)foo (null)foo (null)foo (null).Testing for Non 64 Bit Platforms 
0000000000123456 00123456 0012345600123456 001234560X001234560012345600003456001234561234567887654321.foo  barreally-long-string-that-just-keeps-going-on-and-on-and-on....................useless-filler....................................................useless-filler....................................................useless-filler.................................. barfo barfoo  barfoo  barfoo  barfoo  barfoo  barfoo  barfoo  barfoo  barfoo  barfoo  bar.foo bfoo bfoo cfoo bfoo bfoo     bfoo bfoo b    foo 0000bfoo bfoo b.foo bfoo bfoo cfoo bfoo bfoo     bfoo bfoo b    foo 0000bfoo bfoo b.foo 42foo 65535foo -1foo 42foo 42foo  42foo 42 foo 42foo 042foo 042foo 42foo +42foo  42foo -42foo -42.foo 42foo 65535foo -1foo 42foo 42foo  42foo 42 foo 42foo 042foo 042foo 42foo +42foo  42foo -42foo -42........................Testing for Non 64 Bit Platforms 
.............................................................Testing for Non 64 Bit Platforms 
......foo 52foo 177777foo 177777foo 52foo 52foo  52foo 52 foo 52foo 052foo 052foo 052foo 52foo 52foo 37777777726foo 37777777726.foo 42foo 65535foo 65535foo 42foo 42foo  42foo 42 foo 42foo 042foo 042foo 42foo 42foo 42foo 4294967254foo 4294967254.foo 1234abfoo 1234abfoo 34abfoo 1234abfoo 1234567887654321foo  1234abfoo 1234ab foo 1234abfoo 01234abfoo 01234abfoo 0x1234abfoo 1234abfoo 1234abfoo ffffffd6foo ffffffd6.foo 1234ABfoo 1234ABfoo 34ABfoo 1234ABfoo 1234567887654321foo  1234ABfoo 1234AB foo 1234ABfoo 01234ABfoo 01234ABfoo 0X1234ABfoo 1234ABfoo 1234ABfoo FFFFFFD6foo FFFFFFD6.foo 2.560000e+02foo 2.560000e+02foo 2.560000e+02foo 2.560000e+02foo 2.560000e+02foo   2.560000e+02foo 2.560000e+02  foo 2.6e+02foo 2.56000000e+02foo 002.560000e+02foo 2.560000e+02foo +2.560000e+02foo  2.560000e+02foo -2.560000e+02foo -2.560000e+02.foo 2.560000E+02foo 2.560000E+02foo 2.560000E+02foo 2.560000E+02foo 2.560000E+02foo   2.560000E+02foo 2.560000E+02  foo 2.6E+02foo 2.56000000E+02foo 002.560000E+02foo 2.560000E+02foo +2.560000E+02foo  2.560000E+02foo -2.560000E+02foo -2.560000E+02.foo 2560.001000foo 2560.001000foo 2560.001000foo 2560.001000foo 2560.001000foo  2560.001000foo 2560.001000 foo 2560.0foo 2560.00100000foo 02560.001000foo 2560.001000foo +2560.001000foo  2560.001000foo -2560.001000foo -2560.001000.foo 2560foo 2560foo 2560foo 2560foo 2560foo  2560foo 2560 foo 3e+03foo 2.6e+03foo 2560.001foo 002560foo 2560.00foo +2560foo  2560foo -2560foo -2560.foo 2560foo 2560foo 2560foo 2560foo 2560foo  2560foo 2560 foo 3E+03foo 2.6E+03foo 2560.001foo 002560foo 2560.00foo +2560foo  2560foo -2560foo -2560.babaaaaa4204242042520524204242042420422.0e+002.010e+002.0E+002.010E+002.02.0103e+02256256256.013E+02256256256.01.foo barfoo barfoo barfoo barfoo barfoo barfoo   barfoo bafoo    bafoo bar  foo 00barfoo (null)foo (null)foo (null)foo (null)foo (null)foo (null).foo barfoo barfoo barfoo barfoo barfoo barfoo   barfoo bafoo    bafoo bar  foo 00barfoo (null)foo (null)foo (null)foo (null)foo (null)foo (null).Testing for Non 64 Bit Platforms 
0000000000123456 00123456 0012345600123456 001234560X001234560012345600003456001234561234567887654321.foo  barreally-long-string-that-just-keeps-going-on-and-on-and-on....................useless-filler....................................................useless-filler....................................................useless-filler.................................. barfo barfoo  barfoo  barfoo  barfoo  barfoo  barfoo  barfoo  barfoo  barfoo  barfoo  bar.foo bfoo bfoo cfoo bfoo bfoo     bfoo bfoo b    foo 0000bfoo bfoo b.foo bfoo bfoo cfoo bfoo bfoo     bfoo bfoo b    foo 0000bfoo bfoo b.foo 42foo 65535foo -1foo 42foo 42foo  42foo 42 foo 42foo 042foo 042foo 42foo +42foo  42foo -42foo -42.foo 42foo 65535foo -1foo 42foo 42foo  42foo 42 foo 42foo 042foo 042foo 42foo +42foo  42foo -42foo -42..............Testing for Non 64 Bit Platforms 
................................................Testing for Non 64 Bit Platforms 
....................Testing for Non 64 Bit Platforms 
.....................PAL_SXS test1 SIGSEGV handler 0

FAILED: exception_handling/pal_sxs/test1/paltest_pal_sxs_test1. Exit code: 1

.............................................................................................................................................GlobalMemoryStatusEx:
    ullTotalPhys: 8323821568
    ullAvailPhys: 7693672448
    ullTotalVirtual: 140737488355328
    ullAvailVirtual: 7693672448
    ullTotalPageFile: 0
    ullAvailPageFile: 0
    ullAvailExtendedVirtual: 0
    dwMemoryLoad: 7
...Global Counter Value at the end of the test 0

@janvorli

@janvorli, it is blocking outerloop in many runs. PTAL.
cc @mangod9.

@JulieLeeMSFT

@JulieLeeMSFT, this is a different OS (illumos), while outerloop failure is in linux-musl-arm. Opened #81113.

@gwr

@gwr, @AustinWise, the PAL tests instructions are here: https://github.com/dotnet/runtime/blob/aed5c225ded0fecf98988ac3736d0f6399a82df3/docs/workflow/testing/coreclr/testing.md#pal-tests-macos-and-linux-only (it is meant to be Unix only instead of linux/mac; something we can reword along the way)

Navigation Menu

Repository navigation

paltest_pal_sxs_test1 failed on SmartOS x64 #35362

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	if (ex.GetExceptionRecord()->ExceptionInformation[1] != 0x22)
	{
	Fail("ERROR: PAL_EXCEPT ExceptionInformation[1] != 0x22\n");

	// Test catching exceptions in other PAL instances
	DllTest2();
	DllTest1();
	DllTest2();

paltest_pal_sxs_test1 failed on SmartOS x64 #35362

Description

Activity

am11 commented on Apr 24, 2020

janvorli commented on Apr 24, 2020

am11 commented on Apr 24, 2020

janvorli commented on Apr 24, 2020

am11 commented on Apr 24, 2020

janvorli commented on Apr 24, 2020

am11 commented on Apr 24, 2020

am11 commented on Apr 24, 2020

janvorli commented on Apr 24, 2020

am11 commented on Apr 24, 2020

am11 commented on Apr 26, 2020

am11 commented on Apr 26, 2020

jclulow commented on Apr 26, 2020

jclulow commented on Apr 26, 2020

am11 commented on Apr 26, 2020

jclulow commented on Apr 28, 2020

am11 commented on Apr 28, 2020

am11 commented on Apr 29, 2020

JulieLeeMSFT commented on Jan 24, 2023

JulieLeeMSFT commented on Jan 24, 2023

am11 commented on Jan 24, 2023

am11 commented on Jul 10, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions