Skip to content

Add unit test for signal handling#2

Closed
zzxuanyuan wants to merge 0 commit into
root-project:masterfrom
zzxuanyuan:master
Closed

Add unit test for signal handling#2
zzxuanyuan wants to merge 0 commit into
root-project:masterfrom
zzxuanyuan:master

Conversation

@zzxuanyuan
Copy link
Copy Markdown
Contributor

This pull request implements unit tests for new signal handling.

  1. It includes four signals (SIGBUS, SIGSEGV, SIGILL, SIGFPE). Each of tests creates three threads and keep allocating and freeing memory. Then the test calls kill function to raise signal to the running process.
  2. I tried to raise SIGALRM and SIGCHLD. But it seems they did not have any effects on running process. I tests both main stream and my implementation, the results were the same. CheckChild() handle SIGCHLD, which is an empty function. DispatchTimer() handles SIGALRM and reset the timer (? if I understand correctly). So I did not make tests for these two signals.
  3. Please note: I am currently type-casting TSystem to TUnixSystem to handle SIGALRM and SIGCHLD, and I tried to implement DispatchTimer() function in TSystem, but it cause an segmentation fault Refactor signal handling and replace signal handlers with thread-safe functions root#134. I am not sure it could be a potential issue here. But It is working properly now.

Thanks,

Zhe

@zzxuanyuan zzxuanyuan closed this Apr 5, 2016
Axel-Naumann added a commit to Axel-Naumann/roottest that referenced this pull request May 3, 2022
…jit ABI issue:

This causes failures with
```
 #0  0xb6e5c7e3 in std::_Head_base<0u, std::thread::id const&, false>::_M_head (__b=...) at /usr/include/c++/8/tuple:160
 #1  0xb6e5c7cb in std::_Tuple_impl<0u, std::thread::id const&>::_M_head (__t=...) at /usr/include/c++/8/tuple:351
 root-project#2  0xb6e5d488 in std::__get_helper<0u, std::thread::id const&> (__t=...) at /usr/include/c++/8/tuple:1304
 root-project#3  0xb6e5d462 in std::get<0u, std::thread::id const&> (__t=std::tuple containing = {...}) at /usr/include/c++/8/tuple:1315
 root-project#4  0xb6e5d4ad in std::pair<std::thread::id const, unsigned int>::pair<std::thread::id const&, 0u>(std::tuple<std::thread::id const&>&, std::tuple<>&, std::_Index_tuple<0u>, std::_Index_tuple<>) (this=0xa48005e0, __tuple1=std::tuple containing = {...}, __tuple2=empty std::tuple) at /usr/include/c++/8/tuple:1667
 root-project#5  0xb6e5c863 in std::pair<std::thread::id const, unsigned int>::pair<std::thread::id const&>(std::piecewise_construct_t, std::tuple<std::thread::id const&>, std::tuple<>) (this=0xa48005e0, __first=<error reading variable: Cannot access memory at address 0x7c>, __second=empty std::tuple) at /usr/include/c++/8/tuple:1657
 root-project#6  0xaf853abc in ?? ()
 root-project#7  0xb7722fd2 in start_thread (arg=<optimized out>) at pthread_create.c:486
 root-project#8  0xb76386d6 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108
```

Note esp the JIT frame, and the broken parameter address 0x7c, signaling an ABI issue.
When running this test compiled (root.exe ....C+) the test passes.
Axel-Naumann added a commit to Axel-Naumann/roottest that referenced this pull request May 4, 2022
… issue:

This causes failures with
```
 #0  0xb6e5c7e3 in std::_Head_base<0u, std::thread::id const&, false>::_M_head (__b=...) at /usr/include/c++/8/tuple:160
 #1  0xb6e5c7cb in std::_Tuple_impl<0u, std::thread::id const&>::_M_head (__t=...) at /usr/include/c++/8/tuple:351
 root-project#2  0xb6e5d488 in std::__get_helper<0u, std::thread::id const&> (__t=...) at /usr/include/c++/8/tuple:1304
 root-project#3  0xb6e5d462 in std::get<0u, std::thread::id const&> (__t=std::tuple containing = {...}) at /usr/include/c++/8/tuple:1315
 root-project#4  0xb6e5d4ad in std::pair<std::thread::id const, unsigned int>::pair<std::thread::id const&, 0u>(std::tuple<std::thread::id const&>&, std::tuple<>&, std::_Index_tuple<0u>, std::_Index_tuple<>) (this=0xa48005e0, __tuple1=std::tuple containing = {...}, __tuple2=empty std::tuple) at /usr/include/c++/8/tuple:1667
 root-project#5  0xb6e5c863 in std::pair<std::thread::id const, unsigned int>::pair<std::thread::id const&>(std::piecewise_construct_t, std::tuple<std::thread::id const&>, std::tuple<>) (this=0xa48005e0, __first=<error reading variable: Cannot access memory at address 0x7c>, __second=empty std::tuple) at /usr/include/c++/8/tuple:1657
 root-project#6  0xaf853abc in ?? ()
 root-project#7  0xb7722fd2 in start_thread (arg=<optimized out>) at pthread_create.c:486
 root-project#8  0xb76386d6 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108
```

Note esp the JIT frame, and the broken parameter address 0x7c, signaling an ABI issue.
When running this test compiled (root.exe ....C+) the test passes.
Axel-Naumann added a commit that referenced this pull request May 5, 2022
… issue:

This causes failures with
```
 #0  0xb6e5c7e3 in std::_Head_base<0u, std::thread::id const&, false>::_M_head (__b=...) at /usr/include/c++/8/tuple:160
 #1  0xb6e5c7cb in std::_Tuple_impl<0u, std::thread::id const&>::_M_head (__t=...) at /usr/include/c++/8/tuple:351
 #2  0xb6e5d488 in std::__get_helper<0u, std::thread::id const&> (__t=...) at /usr/include/c++/8/tuple:1304
 #3  0xb6e5d462 in std::get<0u, std::thread::id const&> (__t=std::tuple containing = {...}) at /usr/include/c++/8/tuple:1315
 #4  0xb6e5d4ad in std::pair<std::thread::id const, unsigned int>::pair<std::thread::id const&, 0u>(std::tuple<std::thread::id const&>&, std::tuple<>&, std::_Index_tuple<0u>, std::_Index_tuple<>) (this=0xa48005e0, __tuple1=std::tuple containing = {...}, __tuple2=empty std::tuple) at /usr/include/c++/8/tuple:1667
 #5  0xb6e5c863 in std::pair<std::thread::id const, unsigned int>::pair<std::thread::id const&>(std::piecewise_construct_t, std::tuple<std::thread::id const&>, std::tuple<>) (this=0xa48005e0, __first=<error reading variable: Cannot access memory at address 0x7c>, __second=empty std::tuple) at /usr/include/c++/8/tuple:1657
 #6  0xaf853abc in ?? ()
 #7  0xb7722fd2 in start_thread (arg=<optimized out>) at pthread_create.c:486
 #8  0xb76386d6 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108
```

Note esp the JIT frame, and the broken parameter address 0x7c, signaling an ABI issue.
When running this test compiled (root.exe ....C+) the test passes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant