cl-dbi
cl-dbi copied to clipboard
Functions connect-cached and get-connection-pool are not thread-safe
Because of that, Ultralisp sometimes fails with this error:
failed AVER:
(= (HASH-TABLE-COUNT SB-IMPL::TABLE) SB-IMPL::HWM)
This is probably a bug in SBCL itself. (Alternatively, SBCL
might have been corrupted by bad user code, e.g. by an undefined
Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers
from alien code or from unsafe Lisp code; or there might be a
bug in the OS or hardware that SBCL is running on.) If it seems
to be a bug in SBCL itself, the maintainers would like to know
about it. Bug reports are welcome on the SBCL mailing lists,
which you can find at <http://sbcl.sourceforge.net/>.
[Condition of type SB-INT:BUG]
Restarts:
0: [ABORT] abort thread (#<THREAD "searching-for-repositories" RUNNING {102F529873}>)
Backtrace:
0: (SB-IMPL::GROW-HASH-TABLE #<HASH-TABLE :TEST EQ :COUNT 35 {10020957B3}>)
1: ((FLET SB-IMPL::INSERT-AT :IN SB-IMPL::GET-PUTHASH-DEFINITIONS) #<unavailable argument> #<HASH-TABLE :TEST EQ :COUNT 35 {10020957B3}> #<SB-THREAD:THREAD "searching-for-repositories" RUNNING {102F52987..
2: (SB-IMPL::PUTHASH/EQ #<SB-THREAD:THREAD "searching-for-repositories" RUNNING {102F529873}> #<unavailable argument> #<unavailable argument>)
3: (SB-KERNEL:%PUTHASH #<SB-THREAD:THREAD "searching-for-repositories" RUNNING {102F529873}> #<HASH-TABLE :TEST EQ :COUNT 35 {10020957B3}> #<HASH-TABLE :TEST EQUAL :COUNT 0 {102F5305A3}>)
4: (DBI:CONNECT-CACHED :POSTGRES :HOST "172.17.0.1" :DATABASE-NAME "ultralisp" :USERNAME "ultralisp" :PASSWORD "****")
5: (ULTRALISP/DB::CONNECT :HOST NIL :DATABASE-NAME NIL :USERNAME NIL :PASSWORD NIL :CACHED T)
6: ((LAMBDA NIL :IN ULTRALISP/GITHUB/WIDGETS/REPOSITORIES::SET-OAUTH-TOKEN))
7: ((LABELS BORDEAUX-THREADS::%BINDING-DEFAULT-SPECIALS-WRAPPER :IN BORDEAUX-THREADS::BINDING-DEFAULT-SPECIALS))
This code short be protected with lock.
As a workaround, you may recreate the hash from time to time:
(setf cl-dbi::*threads-connection-pool* (cl-dbi::make-threads-connection-pool))
Thank you for reporting.
Adding :synchronized t to make-hash-table might work?
As I understand, :synchronized t is SBCL's extensions and will not work on other implementations.
Probably we need a separate system to work this around? Something like trivial-sychronized.?
As I see some sort of synchronization was already added: https://github.com/fukamachi/cl-dbi/blob/738a74dd69adb2a7c21fa67e140d89c7df25b227/src/cache/thread.lisp#L37
And today I've fixed it a little in this pull-request:
https://github.com/fukamachi/cl-dbi/pull/75