Assertion failure "erased == 1 (mtrie.cpp:292)" with multiple subscribers and pushers

Description

The attached test case causes an assertion to fail in the 'server' process when the second 'client' process start executing.

This problem was initially observed with the 'server' process implemented in java and the 'client' process implemented in php. The problem was easily reproduced using a pure python implementation.

Environment

Fedora 19
zeromq3-3.2.3-1.fc19.x86_64
python-zmq-13.0.0-1.fc19.x86_64

Activity

Show:
PieterP
September 12, 2013, 12:52 PM

I've rewritten the test case in C, see https://github.com/zeromq/issues/blob/master/562/issue.c

It does not fail on libzmq master.

I don't have Python to test on, but could you try some changes to see if those change its failure?

  • subscribe just once, rather than repeatedly subscribing and unsubscribing

Richard Barlow
September 18, 2013, 4:45 PM

Hi,

Apologies for the delay in responding. I've now moved onto another project, so it's taken a while to get back to this.

I have recreated the problem using the native C API and without the extra complication of threads. Running a single instance of the 'break_server.c' program and two instances of the 'break_client.c' program causes the server program to hit the same assertion as the python. I tested this against libzmq master (de91c7362cd6ca64a1a964b126658768c45e2814).

I tried modifying the client to only subscribe once and, as you would expect, it works perfectly. I appreciate what I'm doing is slightly unusual, but this is just a simple test case that highlights the problem. I observed this happening with a much more complex system where the repeated subscribe/unsubscribes were necessary at the time. I have now begun to re-architect the system so that this isn't as much of an issue, however I wouldn't ever expect a library to hit an assertion.

Many Thanks,
Rich

Assignee

Unassigned

Reporter

Richard Barlow

Labels

None

Components

Affects versions

Priority

Critical