Message196268
| Author |
pitrou |
| Recipients |
ezio.melotti, lambertv, ncoghlan, neologix, pitrou, vstinner |
| Date |
2013年08月27日.08:27:36 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1377592056.61.0.475718560961.issue18623@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> If its a problem with the test I'm guessing it might have to do with how
> os.WCOREDUMP() decides whether a process has dumped its core or not.
You are right, the status code doesn't seem affected by whether the core file was actually dumped or not:
$ ulimit -c
0
$ python -c "import os; os.abort()"; echo $?
Abandon
134
$ ulimit -c unlimited
$ python -c "import os; os.abort()"; echo $?
Abandon (core dumped)
134
And of course:
>>> os.WCOREDUMP(134)
True
I don't think there's any reliable way to test this: modern Linux kernels can intercept core file generation and run an executable instead (think Ubuntu's apport), so the only thing remaining to do is to just check that the context manager "works", i.e. doesn't raise anything.
(see http://linux.die.net/man/5/core "Piping core dumps to a program") |
|