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

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)

> 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.

Closing this one. Haven't seen this in a while, probably it was a bug in libuv.

> Closing this one. Haven't seen this in a while, probably it was a bug in libuv.

I told you so! :-D