intermittent malloc error when checking for ENOTSUP

[commandodev]

Hi,

When I'm running the test suite for the eventlet/zeromq stuff I occasionally get this is my test output:

$ EVENTLET_HUB=zeromq nosetests -v tests/zmq_test.py
test_different_context_in_different_thread (tests.zmq_test.TestThreadedContextAccess) ... ok
test_threadlocal_context (tests.zmq_test.TestThreadedContextAccess) ... ok
test_change_subscription (tests.zmq_test.TestUpstreamDownStream) ... ok
test_close_socket_raises_enotsup (tests.zmq_test.TestUpstreamDownStream) ... python(76333,0x102806000) malloc: *** error for object 0x10155aad0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap

This probably happens about once in 15 test runs or so.

This is the test case:

def test_close_socket_raises_enotsup(self):
    req, rep, port = self.create_bound_pair(zmq.PAIR, zmq.PAIR)
    rep.close()
    req.close()
    self.assertRaisesErrno(zmq.ENOTSUP, rep.recv)
    self.assertRaisesErrno(zmq.ENOTSUP, req.send, 'test')

You can see the full code here:
https://bitbucket.org/boothead/eventlet/src/tip/tests/zmq_test.py

I'm not exactly what you'd call a c or cython expert but if you could give me some pointers on how to provide more info I will certainly try.

Thanks,
Ben

[minrk]

Can you give a bit more information about the context (pyzmq/zeromq/python/OS versions)?

[commandodev]

Ah yes, novice error! Sorry about that :-)

I last worked on this a couple of weeks ago and I wasn't having the error then. This is on snow leopard and pyzmq is installed in a virtualenv of python 2.6.3. Last commit I've got from pyzmq is 199b0fe (23rd sept) and zeromq2 version is be159b (13th sept). Let me fetch all the latest updates and try it on a different OS and give you a better bug report.

Cheers,
Ben

[minrk]

Thanks,

I have reproduced the error in current master with OSX 10.6 system Python 2.6.1 with zeromq release 2.0.9, but only once in a few thousand runs. This is going to be a bit tricky to chase down.

[ellisonbg]

Eeeew, that is going to be horrible. Did you see the error when using eventlet or just regular pyzmq? If you did see it with pyzmq alone, do you have a simple test case that fails. Ideally, it would be nice to run this using gdb, but it might be tough to catch.

[minrk]

I managed to make it happen in pure pyzmq, but only ~ 1 in a few thousand trials. I'll try to see if I can't catch it in a gdb session. I haven't so far.

[commandodev]

I gave a wrong steer on the version I was using - I thought I was working off the checkout I gave you but I had actually installed zeromq via homebrew earlier and I think that was the one that pyzmq was being built against. It was version 2.0.6.

I've now updated to trunk and changed my tests to have some sleep statements in them before messing with the sockets (see https://bitbucket.org/boothead/eventlet/changeset/baa4ea7d5c60) and I'm not seeing any errors.

I haven't run it for thousands of times yet but it's a lot better that the 1 in 10 or so I was getting.

[ellisonbg]

Yes, 2.0.6 is much more buggy than 2.0.9 is for sure.

[minrk]

With current master, I just ran my stress test, and it's past 1.4M now without seeing the issue, so I'm convinced it's resolved.

issue 33 stress test

There is a new issue mentioned in the comments on the gist, but I'm not convinced it's not peculiar to my computer.