This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Arfrever, Trundle, dmalcolm, lemburg, pitrou, scott.dial, vstinner
Date 2011-03-30.07:28:18
SpamBayes Score 6.2894134e-14
Marked as misclassified No
Message-id <1301470087.30032.28.camel@marge>
In-reply-to <1301440645.4.0.9160500586.issue11393@psf.upfronthosting.co.za>
Content
> >  - speed up the test: because dump_backtraces_later() has now a
> > subsecond resolution, we can use sleep of 50 ms instead of 1 sec
> 
> This is too short, there may be random failures on some slow buildbots.
> IMO, 0.5s is the minimum you can use.

Ok, changed.

> The docstring is outdated.

fixed

>  It also seems the "cancel" option isn't
> useful anymore, you could remove it and simplify the test.

cancel is used by test_dump_tracebacks_later_repeat_cancel() to check
that faulthandler.cancel_dump_tracebacks_later() did cancel the last
dump_backtraces_later() request.

> +        process = script_helper.spawn_python('-c', code)
> +        stdout, stderr = process.communicate()
> 
> Shouldn't you check the return code as well?

Yes, except for fatal errors, because the C library exits with a
non-zero exit code (e.g. 139 for a SIGSEGV on Linux). I added a check on
the exit code.

> +        code = "\n".join(code)
> 
> Again, I think it would make the code simpler and more maintainable if
> you used triple-quoted strings instead of lists/tuples.

Ok ok, done

> When you launch a waiting thread in a subprocess, I think it's better to
> set it in daemon mode so as to avoid blocking if the main thread raises
> an exception.

I doesn't know that. fixed

> You have a "#ifdef MS_WINDOWS" in check_signum() but that function is
> not compiled under Windows (it is inside "#ifdef FAULTHANDLER_USER").

Ah yes, the code became useless: removed

--

Other changes:

 - faulthandler_fatal_error() calls the previous signal handler using
raise(signum). Before, the signal was raised again because the same
instruction was executed again, and it raised the same fault. But if the
user sends manually a fatal signal to the process, the signal was
ignored because of the fault handler (but the traceback was displayed).
 - use SA_NODEFER and SA_RESTART flags in enable() and register()
 - faulthandler_get_fileno() accepts fileno()==0
 - cleanup the doc
History
Date User Action Args
2011-03-30 07:28:19vstinnersetrecipients: + vstinner, lemburg, scott.dial, pitrou, Arfrever, Trundle, dmalcolm
2011-03-30 07:28:18vstinnerlinkissue11393 messages
2011-03-30 07:28:18vstinnercreate