-
Notifications
You must be signed in to change notification settings - Fork 8
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
'double free or corruption' #11
Comments
The restriction to particular fields is evidently not relevant; i.e. I removed the two |
On double checking the versions, I just noticed that I compiled the mongo driver without SSL, and thus commented out the ssl functions in mondo as well. |
Are you using the same collection anywhere else? |
The collection is being written to by another process, yes. We're using vibe.d there, but wanted to avoid doing so again for this new (read only) client. |
The cleaning of objects isn't thread safe. I guess there are some kind of concurrency problem. Maybe synchronizing methods of RefCountTree could solve this but I have no example to test with. |
Ok, I'll check tomorrow, but I'm almost certain the collection access in the process which uses mondo occurs only from a single thread. Possible synchronisation issues with another process writing to the same collection are hopefully covered by mongo itself :) I'll see if I have time tomorrow to reproduce the behaviour with a static database I can dump. Getting a simple code example won't be the problem. No guarantees though, there's a lot of work at the moment :( |
This or something very similar happens even in a single thread in Mongo's destructor. |
Probably has to do with https://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors |
dmd 2.074.1
mondo 1.1.6
mongo-c-driver 1.3.4
Connecting to a mongo DB, selecting a single attribute from the result, using a query which will return either zero or one rows. Query like so:
Both with findOne and find, a "double free or corruption" occurs within a minute or two, after about 10 queries.
My impression is that there are some circular link chains involving RefCountTree; enabling the debug logs and adding "-->" before the parent.removeChild and "<--" immediately after parent.removeChild in RefCountTree.tryDestroy results in the last few lines being:
Note the same pointer being destroyed twice, just as the error says.
The mongo database is being written by another process entirely, so getting a minimum complete example will be tricky; is there anything unusual that can be seen from what I've described? It seems to me to be a very simple usage of the library.
Commenting out the body of
RefCountTree.tryDestroy
(and just returning false always) seems to allow the program to run for "long" (no crashes observed, but no really long tests yet either)... but presumably it's now leaking like a sieve ,-)The text was updated successfully, but these errors were encountered: