Thank you Pedro. But this would still crash the nosetests process and thus prevent the summary from being created, right?
On Thu, Jun 21, 2018 at 11:14 PM Pedro Larroy <[email protected]> wrote: > 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 > > >
