A crash in the library is not an error in the test, is a different situation.
I suggest adding these flags to get stack traces and addressing the crash as a separate bug. https://github.com/larroy/mxnet/commit/46389e5851a60d06c37755e5772e6cbcd71b0080 Check the return code when executing the test ($? variable in bash for example) and it will have the value explained here ( https://stackoverflow.com/questions/14599670/what-error-code-does-a-process-that-segfaults-return) set. Then you can mark the full suite as crashed. Pedro. On Thu, Jun 21, 2018 at 1:35 PM Marco de Abreu <[email protected]> wrote: > Hello, > > is anybody aware of a way to catch segmentation faults as part of the > nosetests execution and log them as ERROR? Right now, the nosetests process > gets terminated without a stack trace or further test execution. This has > additional significance because our result-recording that has been > introduced in [1] does not get executed if nosetests does not run until the > end. This means, we're not able to record and track any segmentation > faults. > > If there is anybody in this community who has experience with catching > segmentation faults without terminating the nosetests parent process, I'd > really appreciate some guidance. > > Best regards, > Marco > > [1]: https://github.com/apache/incubator-mxnet/pull/11199 >
