SIGSEGV in _BTree_get() about btrees HOT 7 CLOSED

We use BTrees+gevent+ClientStorage in some configurations, and I haven't seen any crashes like this.

from btrees.

Any ideas how to deeper dig into this? It's fairly reproducible. As soon as there is some more activity going on with the db (like every program startup cycle), I see the usual startup, then the activity peak, I see a bunch of new threads spawned, and then the segfault:

(random last log line)
[New Thread 0x7fffdadfd700 (LWP 23777)]
[New Thread 0x7fffda5fc700 (LWP 23778)]
[New Thread 0x7fffd9dfb700 (LWP 23779)]
[New Thread 0x7fffd95fa700 (LWP 23780)]
[New Thread 0x7fffd8df9700 (LWP 23781)]
[New Thread 0x7fffbbfff700 (LWP 23782)]
[New Thread 0x7fffbb7fe700 (LWP 23783)]

Program received signal SIGSEGV, Segmentation fault.
_BTree_get (self=0x7fffe002aef0, keyarg=(('GRYDER', ('AARON', 'T')), 'M'), has_key=0) at BTrees/BTreeTemplate.c:268
268 BTrees/BTreeTemplate.c: Datei oder Verzeichnis nicht gefunden.

These new threads also get spawned, when I run the database in-process, so not sure, what they're doing, but I guess they don't seem to cause the issue.

What I also noted, especially on startup I get KeyErrors from BTrees on keys, that are supposed to be present, and also show up as being present just on retrying. Ever noticed something like that?

from btrees.

@ml31415 if you can build Python with debug enabled, and run your app under pdb, you might be able to get some more clues (e.g., see the contents of self->data).

Another question: are you trying to share your database connection across threads? The ZODB doesn't expect that: in the stock model each thread would check out a connection as needed from the pool managed by the database (e.g., at the start of a web request), and then return it when finished (at the end of a request, for instance).

from btrees.

I use gevent in only one thread, no multithreading intended. The first line of the program does the monkeypatching, so all the spawned threads should happen somewhere on C-level. Not sure exactly, what they're doing. From gevent, I have about 50-100 microthreads, that access the database without further synchronisation. With plain filestorage, this worked flawlessly.

About self->data, I'm not sure about which object you're talking, but I'll give it a try with the debug symbols.

from btrees.

all the spawned threads should happen somewhere on C-level. Not sure exactly, what they're doing.

By default, gevent uses a threadpool to handle hostname (DNS) lookups, and optionally certain types of I/O with FileObjectThread. Chances are the threads you see are pool threads that did DNS lookups, such as when you connect to the database.

from btrees.

Yeah, the program does indeed a bunch of DNS lookups at that time, though the DB itself is accessed via a socket. So I guess these threads are unrelated to the problem then.

from btrees.

Just for info the results of my further experiments with this:

• Threading is definitely unrelated, setting the gevent resolver to ares disabled any threading, but the problem persisted
• Problem not demonstrateable with a freshly initialized (nearly empty) database
• Problem not demonstrateable with direct in-process FileStorage access
• Problem still present after packing the database
• Problem also happens with elder versions, tested with 3.10.5 and recent versions
• Parallel to the segfault, there are errors with keys not found in the BTree, which are supposed to be there. This may or may not be related (again not present on direct FileStorage access)
• ZEO server process never reports any error
• It seems easier reproducible, the more greenlets are accessing and modifying the database in parallel, ranging from not reproducible with maybe less than 50 greenlets to nearly instant with 150+. Though, none of them are creating heavy load, just infrequently modifying a handful of objects each
• All my tries to write a slim and simple reproducer failed so far

I'm afraid this isn't too helpful yet, so I'll have some more tries in getting something reproducible together. My thoughts so far, please correct me if I'm drawing wrong conclusions:

• Data corruption seems unlikely, as the problem persists after the packing, and as the in-process FileStorage access works fine
• There must be some rare? edge case, when BTree gets different data through ClientStorage/ZEOServer than directly from FileStorage, which causes the segfault in _BTree_get

from btrees.