Issue 18683: Core dumps on CentOS (original) (raw)

This issue has been migrated to GitHub: https://github.com/python/cpython/issues/62883

classification

Title: Core dumps on CentOS
Type: crash Stage:
Components: Versions: Python 2.7, Python 2.6

process

Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: r.david.murray, schlamar, vstinner
Priority: normal Keywords:

Created on 2013-08-08 11:41 by schlamar, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
crash.log schlamar,2013-08-08 11:41
Messages (8)
msg194660 - (view) Author: Marc Schlaich (schlamar) * Date: 2013-08-08 11:41
I'm running unittests on a CentOS 6.4 Virtual Box slave via Jenkins on a Windows host. Randomly I get core dumps for no obvious reason. I don't use any C extension in my code and don't use ctypes. The (proprietary) software is plain Python with a multi-threaded architecture. There might be a threading race condition in the code but according to http://stackoverflow.com/a/13654489/851737 this shouldn't result in a segfault. So it might be a bug in Python. I appended one log (I have various others if you wish to see them) with faulthandler enabled by https://pypi.python.org/pypi/nose-faulthandler.
msg194662 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-08-08 12:01
Can you reproduce this using 2.7? 2.6 only gets security fixes.
msg194761 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-08-09 20:11
It might be related to #14432. Could you try patch Python with a patch of the issue #14432?
msg197517 - (view) Author: Marc Schlaich (schlamar) * Date: 2013-09-12 10:32
Yes, I could reproduce segfaults on Python 2.7 (looks like it is even worse than on 2.6 where it appeared only randomly). I was not quite accurate in my initial comment. I don't use any custom C extensions but I'm using pygtk/gobject so it might be a bug there. However, my library contains a coroutine scheduler similar to tulip so it is very likely that this is related to #14432. I'll try that patch and keep you posted.
msg197519 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-09-12 11:33
> I'll try that patch and keep you posted. Cool, thanks.
msg197521 - (view) Author: Marc Schlaich (schlamar) * Date: 2013-09-12 12:09
The generator.patch from #14432 didn't help. The other couldn't be applied to 2.7. I have a core dump, should I upload it?
msg197522 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2013-09-12 12:19
> I have a core dump, should I upload it? The coredump is not useful if we cannot analyze it. Please open it in gdb, type "thread all apply where" and copy/paste in a file and attach the file. You may use "set pagination off" for easier copy/paste.
msg201729 - (view) Author: Marc Schlaich (schlamar) * Date: 2013-10-30 11:24
Ok, these issues were probably due to the shipped version of PyGTK (which is used as event scheduler). Since I built my own Python and own PyGTK everything looks fine.
History
Date User Action Args
2022-04-11 14:57:49 admin set github: 62883
2013-10-30 11:24:10 schlamar set status: open -> closedresolution: not a bugmessages: +
2013-09-12 12:19:44 vstinner set messages: +
2013-09-12 12:09:03 schlamar set messages: +
2013-09-12 11:33:52 vstinner set messages: +
2013-09-12 10:32:38 schlamar set messages: + versions: + Python 2.7
2013-08-09 20:11:47 vstinner set nosy: + vstinnermessages: +
2013-08-08 12:01:07 r.david.murray set nosy: + r.david.murraymessages: +
2013-08-08 11:41:21 schlamar create