TestCases

From Linux PARISC Wiki
Revision as of 11:57, 5 February 2014 by Deller (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

Kernel Testcases

Futex wait failure

No testcase.

Threads and fork on VIPT-WB machines

 * Affects [[1]].
 * Discussed on [thread] and [thread]

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

  1. include <stdio.h>
  2. include <stdlib.h>
  3. include <errno.h>
  4. include <sys/types.h>
  5. include <unistd.h>
  1. 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

 * Affects [[21]]
 * Discussed by Carlos O'Donell in [thread]:

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:

 a. vfork
 a. Launch "ls -l" in the vfork'd child.
 a. Print some information in the parent.

{{{#!cplusplus /* vfork.c */

  1. include <stdio.h>
  2. include <stdlib.h>
  3. 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]

 * Other testcase [[23]] by Carlos O'Donell
 * Updated (?) testcase [[24]] by Carlos O'Donell

Patches

 * [[25]] from JDA (not-upstream)
 * [[26]] from Carlos O'Donell - Comments/cleanup (on-buildds)


floating point SIGFPE not trapped

 * Affects [[27]]
 * Testcase [[28]]

Patches

 * [[29]] from Helge Deller (in-debian, on-buildds)

GCC TestCases

MMAP

 * Affects [[30]].
 * Discussed by Carlos O'Donell on [thread].
 * Testcase [[31]] from Carlos O'Donell


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` {{{#!cplusplus // This test only applies to glibc (NPTL) targets. // { dg-do run { target *-*-linux* } } // { dg-options "-pthread" }

  1. include <pthread.h>
  2. 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;
   }

} }}}

Personal tools