[odb-users] Coredump in multithreading environment and one transaction

[Boris Kolpackov]

Javier Gutierrez <javier.gutierrez at web.de> writes:

> I have a bunch of threads that share the same transaction. All of them run
> different queries concurrently.
> For running the query they call a function passing the transaction and the
> odb::query by value.
> The transaction is passed as an object that contains the odb::transaction
> and a std::mutex.
> So this function locks the mutex, sets the transaction as odb::current, runs
> the query and returns the result to the calling thread.
> Then the thread reads the result in a for-loop.
> 
> The segmentation fault occurs (if it occurs) when returning the result.
> 
> Of course when the function returns, the locking of the mutex goes out of
> scope. Now if I make a test and run the for-loop of the result inside the
> scope of the mutex then I get no coredump (at least this is the conclusion I
> got to).
> 
> But my understanding is that reading the result of the locked area should
> not be a problem since the result is cached (i.e. the odb::query run with
> the cache flag = true).

My guess (without looking at the stack trace) is that this has to do with
the object image (essentially, buffers) that are used to load objects from
their database representation and are per-connection. In your case they
would be shared without any protection. One way to fix this would be to
iterate over the result under the lock, load all the objects, and return
them as a vector or some such.

Note also that query result caching is to be able to have several query
results at the same time in a single transaction. Also, for some databases,
caching is a noop/unsupported. See the Limitations section for your
database in the manual for details.