-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Segfault: current_page_acq_t::current_page_for_read #2222
Comments
Pinging @srh (and possibly @danielmewes) |
The script is appending to an array for all documents matching the filter (in this case, a field containing a URL). I'm using the python API:
The script calling this code ran every 5 minutes for ~3 days, so the array should be about 800+ items when the crashing started occurring. ~200 documents in the table. I also get this warning when starting the rethinkdb server, don't know if it is related:
|
Thank you! Would it be possible for you to zip up the files and send them to us? (You can send them to slava@rethinkdb.com if they fit into an e-mail; if not we'll set up a share for you).
Are the RethinkDB data files on an encrypted/compressed file system? In this case Rethink can't use direct IO, so it switches to use the page cache. (I opened an issue in the doc repository to write a troubleshooting entry for it -- rethinkdb/docs#259) |
Will follow up on email, thank you! |
For core devs looking at this issue, the data files, core dump, and the script that produces the segfault are in |
The assembler code of the crash point in
For comparison the source code of that function with asserts removed (those don't get compiled in release mode):
One can see the call to @AtnNn do we have a full symbol file for the builds somewhere? |
Oh actually the comparison that crashes is probably the line |
Now the question is how both |
I think we can get into this situation if a deleted page gets snapshotted. Then the Now generally nobody should attempt to read a deleted page. I will try a bit more to reproduce this problem locally. So far I didn't have any luck. |
Hah, got a crash. It was necessary to have a concurrent read transaction, for example My backtrace is different, but I believe it's the same underlying problem.
Looks like a problem with snapshotting. |
We are assigning it to me, because it'll require dealing with some awful blob code. |
Working on this in sam_2222 (off v1.12.x of course). |
This might be (should be) fixed in branch sam_2222, I'm doing some testing. |
We can confirm that this doesn't crash in the way v1.12.x crashes on the data for this issue with the scripts that @danielmewes created. |
This is fixed and merged to v1.12.x as of cea6c39. |
@rlshepherd We have just released RethinkDB 1.12.2, which includes a fix for this issue. |
Thank you very much! On Thu, Apr 10, 2014 at 5:06 AM, Etienne Laurin notifications@github.comwrote:
|
Stack trace from the user:
Running on:
@rlshepherd -- I have a few more questions:
rethinkdb --version
)The text was updated successfully, but these errors were encountered: