classification
Title: Segafault in _PyObject_Alloc
Type: crash Stage: resolved
Components: Versions: Python 3.5
process
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: Nosy List: ned.deily, ronaldoussoren, serhiy.storchaka, vstinner, yselivanov
Priority: normal Keywords:

Created on 2016-04-18 18:35 by yselivanov, last changed 2016-09-16 00:03 by vstinner. This issue is now closed.

Messages (5)
msg263678 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2016-04-18 18:35
I'm working on an implementation of asyncio event loop on top of libuv [1].  One of my tests crashes on Mac OS X with a segfault [2].  The problem is that it's not consistent -- looks like it depends on size of uvloop so binary, or/and amount of objects allocated in program.

I can't reproduce the problem on a debug build, or write a test for it, it is really a weird edge-case.  But I'm certain that we have a bug in our memory allocator.

Here's a screenshot of crash log [3], and here's an lldb disassembly of crash location [4].

Now, what's going on in [2] is:
1. uvloop sets a sigint signal handler the moment it starts the loop
2. uvloop start to execute a coroutine, which blocks on a long "time.sleep(..)" call
3. sigint handler receives a SIGINT and calls PyErr_SetInterrupt
4. CPython interrupts the code, KeyboardInterrupt is instantiated and raised
5. CPython starts to render the traceback to print it to stderr, and this is where it tries to allocate some object, and this is where we hit a bad-access in _PyObject_Alloc.

I'd really appreciate any ideas on what's going on here and how we can fix this.


[1] https://github.com/magicstack/uvloop
[2] https://github.com/MagicStack/uvloop/blob/v0.4.6/tests/test_signals.py#L14
[3] http://imgur.com/6GcE92X
[4] https://gist.github.com/1st1/b46f3702aeb1b57fe4ad32b19ed63c3f
msg263691 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-04-18 21:16
Usually a "bug in the memory allocator" means a buffer overflow in your
code. Did you check your code using a debug build, PYTHONDEBUG=debug (if
CPython is compiled in release mode), or PYTHONMALLOC=malloc + valgrind?
(The env var requires CPython 3.6)
msg263692 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2016-04-18 21:26
> Did you check your code using a debug build, PYTHONDEBUG=debug (if
CPython is compiled in release mode), or PYTHONMALLOC=malloc + valgrind?
(The env var requires CPython 3.6)

Can't reproduce it in the debug build :(

Since I'm not writing C by hand (I use Cython), and libuv is quite stable, I quite doubt that I have a buffer overflow anywhere in my code, but I'll double check.
msg276643 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2016-09-15 23:59
Closing this one. Haven't seen this in a while, probably it was a bug in libuv.
msg276644 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-09-16 00:03
> Closing this one. Haven't seen this in a while, probably it was a bug in libuv.

I told you so! :-D
History
Date User Action Args
2016-09-16 00:03:55vstinnersetmessages: + msg276644
2016-09-15 23:59:10yselivanovsetstatus: open -> closed
resolution: works for me
messages: + msg276643

stage: test needed -> resolved
2016-04-18 21:26:38yselivanovsetmessages: + msg263692
2016-04-18 21:16:35vstinnersetmessages: + msg263691
2016-04-18 18:48:40ned.deilysetnosy: + ronaldoussoren
2016-04-18 18:35:54yselivanovcreate