View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000526 | ascend | general | public | 2012-01-20 16:11 | 2013-02-26 13:39 |
Reporter | john | ||||
Assigned To | john | ||||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | resolved | Resolution | won't fix | ||
Product Version | 0.9.8 | ||||
Target Version | 0.9.9 | Fixed in Version | 0.9.8 | ||
Summary | 0000526: test case utilities_ascSignal failing | ||||
Description | There are several errors raised by the utilities_ascSignal test collection, when run on Ubuntu 11.10 32-bit. There is no memory leak, though. | ||||
Additional Information | Suite: utilities_ascSignal Test: ascSignal ...PROGRAM ERROR: ascend/utilities/ascSignal.c:341:Asc_SignalHandlerPop: Asc_Signal (8) stack pop mismatch. PROGRAM ERROR: ascend/utilities/ascSignal.c:334:Asc_SignalHandlerPop: Popping invalid signal type (signum = 4) PROGRAM ERROR: ascend/utilities/ascSignal.c:334:Asc_SignalHandlerPop: Popping invalid signal type (signum = 6) PROGRAM WARNING: ascend/utilities/ascSignal.c:354:Asc_SignalTrap: Floating point error caught ascend/utilities/ascSignal.c:355 (Asc_SignalTrap): SIGFPE caught ascend/utilities/ascSignal.c:362 (Asc_SignalTrap): SIGINT (Ctrl-C) caught ascend/utilities/ascSignal.c:366 (Asc_SignalTrap): SIGSEGV caught FAILED 1. ascend/utilities/test/test_ascSignal.c:208 - my_handler1 == old_handler 2. ascend/utilities/test/test_ascSignal.c:219 - my_handler1 == old_handler 3. ascend/utilities/test/test_ascSignal.c:273 - my_handler1 == old_handler 4. ascend/utilities/test/test_ascSignal.c:308 - TRUE == signal3_caught 5. ascend/utilities/test/test_ascSignal.c:327 - TRUE == signal2_caught 6. ascend/utilities/test/test_ascSignal.c:346 - TRUE == signal1_caught 7. ascend/utilities/test/test_ascSignal.c:376 - TRUE == signal3_caught 8. ascend/utilities/test/test_ascSignal.c:395 - TRUE == signal2_caught 9. ascend/utilities/test/test_ascSignal.c:414 - TRUE == signal1_caught 10. ascend/utilities/test/test_ascSignal.c:444 - TRUE == signal3_caught 11. ascend/utilities/test/test_ascSignal.c:463 - TRUE == signal2_caught 12. ascend/utilities/test/test_ascSignal.c:482 - TRUE == signal1_caught 13. ascend/utilities/test/test_ascSignal.c:490 - my_handler1 == old_handler 14. ascend/utilities/test/test_ascSignal.c:500 - my_handler1 == old_handler Run Summary: Type Total Ran Passed Failed Inactive suites 35 1 n/a 0 0 tests 84 1 0 1 0 asserts 101 101 87 14 n/a | ||||
Tags | No tags attached. | ||||
|
As of changeset 3983, the first three bugs above are resolved. Not sure of the reason for the remaining failures. Hmm. 1. ascend/utilities/test/test_ascSignal.c:336 - CU_FAIL("should'nt be here!") 2. ascend/utilities/test/test_ascSignal.c:353 - TRUE == signal3_caught 3. ascend/utilities/test/test_ascSignal.c:373 - TRUE == signal2_caught 4. ascend/utilities/test/test_ascSignal.c:393 - TRUE == signal1_caught 5. ascend/utilities/test/test_ascSignal.c:414 - CU_FAIL("shouldn't be here!") 6. ascend/utilities/test/test_ascSignal.c:424 - TRUE == signal3_caught 7. ascend/utilities/test/test_ascSignal.c:442 - TRUE == signal2_caught 8. ascend/utilities/test/test_ascSignal.c:460 - TRUE == signal1_caught 9. ascend/utilities/test/test_ascSignal.c:480 - CU_FAIL("shouldn't be here!") 10. ascend/utilities/test/test_ascSignal.c:490 - TRUE == signal3_caught 11. ascend/utilities/test/test_ascSignal.c:508 - TRUE == signal2_caught 12. ascend/utilities/test/test_ascSignal.c:526 - TRUE == signal1_caughtSuite results = 35 |
|
We've concluded that there is either some illegal usage or a GCC bug causing this, and we will simply remove the offending test cases. We want to make sure we don't use nested signal handlers for the same signal in ASCEND, as a result, because this bug will show up. FWIW I found some alternative implementations of this stuff, should we ever want to come back to it: 'trycatch' at http://llg.cubic.org/trycatch/ 'kazlib' at http://www.kylheku.com/~kaz/kazlib.html 'XXL' at zork.org/xll, currently offline |
|
nested signal handlers with longjmp don't appear to be 'supported' behaviour for GCC/Linux in their current form. A new implementation is needed using 'sigaction' on this platform, but for the moment, this nested usage is deprecated and we have suppressed the failing test case. |
Date Modified | Username | Field | Change |
---|---|---|---|
2012-01-20 16:11 | john | New Issue | |
2012-01-26 14:56 | john | Note Added: 0000801 | |
2012-01-26 15:00 | john | Note Edited: 0000801 | View Revisions |
2012-01-28 06:55 | john | Note Added: 0000805 | |
2012-01-31 05:38 | svn | ||
2012-02-06 05:31 | john | Note Added: 0000813 | |
2012-02-06 05:31 | john | Status | new => resolved |
2012-02-06 05:31 | john | Fixed in Version | => 0.9.8 |
2012-02-06 05:31 | john | Resolution | open => won't fix |
2012-02-06 05:31 | john | Assigned To | => john |
2013-02-26 13:39 | john | Target Version | 1.0 => 0.9.9 |