Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rare java crash - invalid access in Poller_run_1poll #24

Closed
robinp opened this issue Jan 7, 2011 · 3 comments

Comments

@robinp
Copy link
Contributor

commented Jan 7, 2011

On Linux x86, jdk1.6u20/22 using latest zmq and jzmq, the bug happens occassionally (sometimes 4 times in a row, sometimes once a day). Happened with older (j)zmq too.

Compiled jzmq without optimalizations, made disassembly and identified the line and place of code of the invalid access. See details attached to https://gist.github.com/769657 (interesting places in files marked).

It seems that in Poller.cpp line 101, pitem[pc] points to the bad address (beginning of a guard page). The .revents matches the offset of [eax + 10] seen in the disasm.

By the way, the the cycle at Poller.cpp:100 seems suspicious, since above in the file it is notet that the sockets array can be sparse, and at :72 this sparseness is checked, so while the cycle at :70 runs from 0...ls_0mq, pc may be incremented less times.

However, at the :100 cycle pc seems to be incremented as many times as ls_0mq, and with ls_0mq > ls that may read unallocated memory.

Also, what happens if the check at :90 fails? Should it be an assertion?

Thanks,
Robin

@robinp

This comment has been minimized.

Copy link
Contributor Author

commented Jan 7, 2011

See experimental patch at https://github.com/robinp/jzmq/commit/04c29009adfe6c66e856b27b6100eac6a9e3b242

(Haven't run long yet to be decisive, but at least it didn't break anything yet:)

@robinp

This comment has been minimized.

Copy link
Contributor Author

commented Jan 7, 2011

This java file reproduces that the Poller_run_1poll last cycle not checking for sparsity produces unexpected behavior.

https://gist.github.com/769876

It can be seen when run unpatched, that socket2 is already unregistered from the poller, but incorrectly it receives the revents of socket3. revents of socket3 is random (since it is copied from unallocated memory).

@robinp

This comment has been minimized.

Copy link
Contributor Author

commented Jan 11, 2011

Patch seems to behave fine, closing this. Issued pull request (https://github.com/zeromq/jzmq/issues#issue/25)

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.