summaryrefslogtreecommitdiffstats
path: root/src/H5Shyper.c
diff options
context:
space:
mode:
authorAlbert Cheng <acheng@hdfgroup.org>2010-04-28 19:56:29 (GMT)
committerAlbert Cheng <acheng@hdfgroup.org>2010-04-28 19:56:29 (GMT)
commit2bf52ee03ef0a1f8663d40b1ac0f8fe2d4934720 (patch)
tree9491fccce38c18b3f102485914e6516ab2fa5528 /src/H5Shyper.c
parentfadbd8866f5741da77a369fd015c82db5b191294 (diff)
downloadhdf5-2bf52ee03ef0a1f8663d40b1ac0f8fe2d4934720.zip
hdf5-2bf52ee03ef0a1f8663d40b1ac0f8fe2d4934720.tar.gz
hdf5-2bf52ee03ef0a1f8663d40b1ac0f8fe2d4934720.tar.bz2
[svn-r18659] Bug: 1764
Description: longjmp do not necessary restore signal that is blocked during the signal handling. This caused the Alignment test to fail quietly, resulting in wrong alignment information which will cause failures later. Solution: One can use sigsetjmp/siglongjmp to restore signal handling but not all systems such as Cray XT or VMS supports sigsetjmp. Backup solution is to use sigprocmask to reset the signal. Again, some systems may not support it either. Added code to try the first and then the second solution. Also added tests to verify if the signal_handler routines are working properly. Finally, added code to print results of the verification (in form of comments) to H5Tinit.c for inspection in case of failure. (Note that many platforms do not have alignment limits at all and ALIGNMNET code never raise the SIGBUS or SIGSEGV errors. In those cases, it does not matter whether the signal handlers work or not. Again, this can be deduced from the results comments near the end of the H5Tinit.c. If the sum of signal handlers called equals the total of verify, it means ALIGNMENT does not raise any signals.) For configure.in and configure: Added the test for setjmp, sigsetjmp, sigprocmask which are used by the H5detec.c. Tested: htcommittested, jam(serial).
Diffstat (limited to 'src/H5Shyper.c')
0 files changed, 0 insertions, 0 deletions