test_faulthandler fails on an android emulator running an x86 system image at API level 21.

See the attached test_output.txt file.

The 8 failures are all because exitcode is 0 when it should not be.

    self.assertNotEqual(exitcode, 0)
AssertionError: 0 == 0

Reproducing the code that is executed on the first failure (test_disable) gives:

On linux:
$ python
Python 3.6.0a0 (default:47fa003aa9f1, Feb 24 2016, 13:09:02) 
[GCC 5.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import faulthandler
>>> faulthandler.enable()
>>> faulthandler.disable()
True
>>> faulthandler._sigsegv()
Segmentation fault (core dumped)


On the android emulator:
root@generic_x86:/data/local/tmp # python
Python 3.6.0a0 (default:811ccdee6f87+, May  7 2016, 09:02:21) 
[GCC 4.9 20140827 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import faulthandler
>>> faulthandler.enable()
>>> faulthandler.disable()
True
>>> faulthandler._sigsegv()
>>>

The gdb backtrace of running interactively 'faulthandler._sigsegv()'. After the SIGSEGV and the last gdb 'continue', python is still alive with a '>>>' prompt and ready for the next user input:

(gdb) b faulthandler_sigsegv
Breakpoint 1 at 0xb752159f: file /home/xavier/src/packages/android/cpython/Modules/faulthandler.c, line 964.
(gdb) c
Continuing.

Breakpoint 1, faulthandler_sigsegv (self=self@entry=<module at remote 0xb6d85cf4>,
args=args@entry=()) at /home/xavier/src/packages/android/cpython/Modules/faulthandler.c:964
964 {
(gdb) next
965 int release_gil = 0;
(gdb)
966 if (!PyArg_ParseTuple(args, "|i:_sigsegv", &release_gil))
(gdb)
969 if (release_gil) {
(gdb)
974 faulthandler_raise_sigsegv();
(gdb) step
faulthandler_raise_sigsegv ()
at /home/xavier/src/packages/android/cpython/Modules/faulthandler.c:941
941 {
(gdb) next
942 faulthandler_suppress_crash_report();
(gdb)
958 raise(SIGSEGV);
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0xb76ec126 in ?? ()
(gdb) c
Continuing.

This is due to something mysterious in Android's bionic & kernel. For the following C program:

#include <stdlib.h>
#include <signal.h>
#include <stdio.h>

int main()
{
    sigaction(SIGSEGV, NULL, NULL);
    raise(SIGSEGV);
    printf("Good evening!\n");
    return 0;
}

Compiled with: /opt/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc test_sigsegv.c --sysroot /opt/android-ndk/platforms/android-21/arch-arm -fPIE -Wl,-pie
(Replace /opt/android-ndk to the path of NDK)

On ASUS ZE500KL:
shell@ASUS_Z00E_2:/data/local/tmp $ ./a.out
Good evening!

On Linux: (Compiled with gcc test_sigsegv.c)
$ ./a.out
[2] 23434 segmentation fault (core dumped) ./a.out

Seems the sigaction() call in Python occurs in Modules/signalmodule.c.

This is due to something mysterious in Android's bionic & kernel. For the following C program:
(...)

Please try without "sigaction(SIGSEGV, NULL, NULL);". Does the program still quit?

Does faulthandler._read_null() crash Python? If yes, I should patch test_faulthandler to replace all _sigsegv() with faulthandler._read_null().

I was too lazy to do that because currently the unit tests checks the exact error message, whereas _read_null() gives different error messages depending on the platform.

Please try without "sigaction(SIGSEGV, NULL, NULL);". Does the program still quit?

Nope.

int main()
{
    raise(SIGSEGV);
}

Still exits normally with 0.

Does faulthandler._read_null() crash Python?

Yes.

int main()
{
    int *x = 0;
    int y = *x;
    return 0;
}

Is killed and exits with 139 as expected.

The problem: raise() does not cause the program to exit in a Python interactive session and a spawned Python process exits with 0. Android fixed this problem at API level 24 (Android 6.0 aka Marshmallow).
The attached patch fixes this (tested at API levels 21 et 24).

Can you try to write a decorator to not suplicate the same long skipIf()?

Thanks for the suggestion Victor. The decorator may be used in other tests as well, and referring to the concern raised by Chi Hsuan in msg280147 and my answer, it makes it more clear that the build time _android_api_level should not be used in the standard library itself.
New patch.

New patch following Victor code review.

buggy_raise_3.patch LGTM but I don't think that it's worth it to add @requires_raise to support directly. I suggest to only add it to test_faulthandler.py.

New patch.

buggy_raise_4.patch LGTM. Thanks for your patience :-)

Maybe later you can also modify existing tests to use the new
@requires_android_level?

Thanks for your patience :-)

No problem, your suggestions and code reviews are always very much welcome :)
I will push this patch with the other Android patches after 3.6 is released. The patch at bpo-26936 will also use @requires_android_level.

New patch using a plain 'requires_raise' decorator without argument.

LGTM.

Oh, you didn't push your patch yet? Go ahead.

buggy_raise_5.patch LGTM and is better than perfect :-)

New changeset 66aac9676a28 by Xavier de Gaye in branch 'default':
Issue bpo-26934: Fix test_faulthandler on Android where raise() exits with 0,
https://hg.python.org/cpython/rev/66aac9676a28

New changeset f37ac1a003f3 in branch 3.6.
New changeset 892f13827219 in branch default.

Buildbots fail since _ANDROID_API_LEVEL could end up being None

New changeset 2639afcedaad by Xavier de Gaye in branch '3.6':
Issue bpo-26934: Handle _ANDROID_API_LEVEL is None on Windows
https://hg.python.org/cpython/rev/2639afcedaad

New changeset 4012e28539c4 by Xavier de Gaye in branch 'default':
Issue bpo-26934: Merge 3.6
https://hg.python.org/cpython/rev/4012e28539c4