'double free or corruption'

[MWumpusZ]

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:

...
        mongo = new Mongo("mongodb://<url:port here>");
...
        Collection c = mongo["journaling"]["records"];

        Query q = new Query();
        q.conditions["attributes.id"] = announcementId;
        q.conditions["action"] = "new";
        q.fields["_id"] = false;
        q.fields["attributes.datagram"] = true;

        auto queryResult = c.find(q);
...

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:

...
TryDestroy db with address 7FB7FC00C5B0 fail. toDestroy: true children.lenght:1
Destroying collection with address **7FB7FC00CA10**
-->
Destroying db with address 7FB7FC00C5B0
-->
Destroying collection with address **7FB7FC00CA10**
...
*** Error in `./build/debug/AnnouncementListener': double free or corruption (out): 0x00007fb7fc00ca10 ***

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 ,-)

[MWumpusZ]

The restriction to particular fields is evidently not relevant; i.e. I removed the two q.fields lines and the error persists.

[MWumpusZ]

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.
I can't really imagine that being relevant for the error at hand, but just in case... ,-)

[trikko]

Are you using the same collection anywhere else?

[MWumpusZ]

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.

[trikko]

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.

[MWumpusZ]

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 :)
Having said that: Is it possible that an automatic garbage collector run could end up conflicting with "manual" cleanup triggered by something going out of scope or similar?

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 :(

[NotSpooky]

This or something very similar happens even in a single thread in Mongo's destructor.
foreach (i; 0..10000) { auto a = new Mongo ("mongodb://localhost"); }

[NotSpooky]

Probably has to do with https://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
because a method from garbageIdx is called from the destructor.