TestCases
m |
(→Kernel Testcases) |
||
Line 1: | Line 1: | ||
= Kernel Testcases = | = Kernel Testcases = | ||
+ | |||
+ | == Math test case == | ||
+ | |||
+ | should return 0.0: (hppa floating point error) | ||
+ | |||
+ | #include <stdio.h> | ||
+ | #include <math.h> | ||
+ | int | ||
+ | main (void) { | ||
+ | double result = exp (-4.3682654441477153e+19); | ||
+ | printf ("%g\n", result); | ||
+ | if (result != 0.0) | ||
+ | return 1; | ||
+ | return 0; | ||
+ | } | ||
+ | |||
+ | |||
== Futex wait failure == | == Futex wait failure == |
Revision as of 12:26, 25 March 2014
Contents |
Kernel Testcases
Math test case
should return 0.0: (hppa floating point error)
#include <stdio.h> #include <math.h> int main (void) { double result = exp (-4.3682654441477153e+19); printf ("%g\n", result); if (result != 0.0) return 1; return 0; }
Futex wait failure
No testcase.
Threads and fork on VIPT-WB machines
Summary from [[2]]:
The minifail bug is a "Threads and fork" problem arising from cache corruption. Mainly, copy_user_page is broken when copying memory shared by more than one process. There are also issues in PTE/TLB management on SMP systems. Probably, the vfork/execve bug is caused by the same problem.
Initial patch [[3]] from [[4]]
First testcase [[5]]
Build with:
- g++ -I/usr/include/qt4 -lQtCore minifail.cpp -o minifail -O0 -g
Fails occasionally with:
$ i=0; while true; do i=$(($i+1)); echo Run $i; ./minifail; done; $ i=0; while true; do i=$(($i+1)); echo Run $i; ./minifail qt; done;
Typical observed failure:
Run 21 Segmentation fault Run 22 Child OK. Thread OK. Run 23 Thread OK. Segmentation fault
- Reduced [[6]], from [post]:
- Tentative [[7]], see this [[8]]
- Other version [[9]] from [Deller]
- Other version [[10]] from [[11]]
- Other version [[12]] from [[13]]
- Final (?) version [[14]] from [Deller]
Other testcase from [[15]]:
Compile with `-static` to link with libc.a. Testcase prints incorrect parent pid.:
#!cplusplus #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <sys/types.h> #include <unistd.h> #define CALL_EXIT 0 int main (void) { pid_t child; pid_t parent; char *cmd[] = { "bash", "-c", "echo In child $$;", (char *)0 }; char *env[] = { "HOME=/tmp", (char *)0 }; int ret; child = vfork(); if (child == 0) { ret = execve("/bin/bash", cmd, env); // printf ("ret = %d\n", ret); _exit(1); } else { // printf("child != 0\n"); } parent = getpid(); printf("parent is %d\n", (unsigned int)parent); printf("child is %d\n", (unsigned int)child); return 0; }
Patches
- [[16]] from Helge Deller - Not Applicable (not-upstream)
- [[17]] from JDA (not-upstream)
- [[18]] from JDA - Superseded by patch2 (not-upstream)
- [[19]] from JDA - Included in patch3 (not-upstream)
- [patch3] from JDA - Partially split into
- [pagefault_disable/pagefault_enable in kmap_atomic/kunmap_atomic] (on-buildds)
- [unnecessary macros from entry.S] (on-buildds)
- [unnecessary nop's in entry.S] (on-buildds)
- [interruption in critical region in entry.S] (on-buildds)
- [fixes for syscall.S] (on-buildds)
- Note: some bits from patch3 have not be separately submitted (futex.h, etc) - Needs review
- [patch update], initially found in patch3 from JDA (not-upstream)
- [patch4] aka `pte.2.d` from JDA, updating parts of patch3 (not-upstream)
- [[20]] from James Bottomley for kmap issues fixing minifail6.cpp (not-upstream)
- [patch5] from JDA with a slightly modified version of James' patch (not-upstream)
- [patch6] from JDA, with apparently good results both on pa8800 and previous CPUs (not-upstream)
- [patch7] from JDA, with reworked pacache.s and cache.c (not-upstream)
vfork/execve
I have constructed a vfork test case which shows some of the problems I have using vfork reliably. This fails every time on my PA8700 system running 2.6.32-rc6. It appears as though r28 (ret0) in the parent is being corrupted.
The intent of the testcase is to do the following:
- vfork
- Launch "ls -l" in the vfork'd child.
- Print some information in the parent.
/* vfork.c */ #include <stdio.h> #include <stdlib.h> #include <errno.h> int main (void) { pid_t child; char *cmd[] = { "ls", "-l", (char *)0 }; char *env[] = { "HOME=/tmp", (char *)0 }; child = vfork(); if (child == 0) { execve("/bin/ls", cmd, env); } else { printf("child != 0\n"); } printf("child is 0x%x\n", (unsigned int)child); return 0; }
Compile this test case twice:
- gcc -O1 -g -o vfork-O1 vfork.c
- gcc -O0 -g -o vfork-O0 vfork.c
The return from vfork is corrupted in the parent.
This gets worse at -O0.
To remove the C library from the loop I attach a complete vfork implementation as used by glibc. [[22]]
You can compile the test case using: `cc -O1 -g -o vfork-O1 vfork.c pt-vfork.s`
In summary:
- Test case works on x86.
- Test case fails on hppa.
- Test case works on hppa under strace.
More discussion by Carlos O'Donell in [thread]
Patches
floating point SIGFPE not trapped
Patches
- [[29]] from Helge Deller (in-debian, on-buildds)
GCC TestCases
MMAP
GLIBC TestCases
Segmentation fault in __libc_start_main with -static
Discussed in [thread]
Testcase from [[32]]: Compile with `g++ -o xx -static -pthread xx.C`
// This test only applies to glibc (NPTL) targets. // { dg-do run { target *-*-linux* } } // { dg-options "-pthread" } #include <pthread.h> #include <cxxabi.h> extern "C" int printf (const char *, ...); int main() { try { pthread_exit (0); } catch (abi::__forced_unwind &) { printf ("caught forced unwind\n"); throw; } catch (...) { printf ("caught ...\n"); return 1; } }