SBCL save-lisp-and-die

[hemml]

I'm developing a code in SBCL and trying to dump lisp image to save my work. If I'm using postmodern, my image often saved in corrupted state even if I'm closing toplevel connection before image dump. Is there a special cleanup procedure for postmodern which needs to be executed before save-lisp-and-die call?

[sabracrolleton]

First I have heard of this. (Which does not mean it isn't true). Does it happen if you are using with-connection or something other than using a toplevel connection?

[hemml]

The problem was with old version of SBCL, sorry. But the more recent one also produces an error after image start:

Database error: #<SB-SYS:FD-STREAM for "file /dev/urandom" {1001CF02F3}> was closed by SB-EXT:SAVE-LISP-AND-DIE
   [Condition of type CL-POSTGRES:DATABASE-SOCKET-ERROR]
Restarts: 
  0: [RECONNECT] Try again.
  1: [RETRY] Retry SLIME REPL evaluation request.
  2: [*ABORT] Return to SLIME's top level.
  3: [ABORT] abort thread (#<THREAD "repl-thread" RUNNING {1005968433}>)
Stack Trace: 
  0: ((FLET CL-POSTGRES::ADD-RESTART :IN CL-POSTGRES::INITIATE-CONNECTION) #<SB-INT:CLOSED-SAVED-STREAM-ERROR {1008A5D1D3}>)
  1: (CL-POSTGRES::INITIATE-CONNECTION #<CL-POSTGRES:DATABASE-CONNECTION {1008A5C013}> 0)
  2: (CL-POSTGRES:OPEN-DATABASE "dbmail" "dbmail_admin" "" "mail-database" 5432 :NO "postgres" "" NIL)
  3: (POSTMODERN:CONNECT-TOPLEVEL "dbmail" "dbmail_admin" "" "mail-database" :PORT 5432 :USE-SSL NIL :APPLICATION-NAME "" :USE-BINARY NIL)
  4: (SB-INT:SIMPLE-EVAL-IN-LEXENV (POSTMODERN:CONNECT-TOPLEVEL "dbmail" "dbmail_admin" "" "mail-database") #<NULL-LEXENV>)
  5: (EVAL (POSTMODERN:CONNECT-TOPLEVEL "dbmail" "dbmail_admin" "" "mail-database"))
  6: (SWANK::EVAL-REGION "(postmodern:connect-toplevel \"dbmail\" \"dbmail_admin\" \"\" \"mail-database\")")
  7: ((LAMBDA NIL :IN SWANK-REPL::REPL-EVAL))
  8: (SWANK-REPL::TRACK-PACKAGE #<FUNCTION (LAMBDA NIL :IN SWANK-REPL::REPL-EVAL) {1008A5BDAB}>)
  9: (SWANK::CALL-WITH-RETRY-RESTART "Retry SLIME REPL evaluation request." #<FUNCTION (LAMBDA NIL :IN SWANK-REPL::REPL-EVAL) {1008A5BD4B}>)
  10: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #<FUNCTION (LAMBDA NIL :IN SWANK-REPL::REPL-EVAL) {1008A5BD2B}>)
  11: (SWANK-REPL::REPL-EVAL "(postmodern:connect-toplevel \"dbmail\" \"dbmail_admin\" \"\" \"mail-database\")")
  12: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK-REPL:LISTENER-EVAL "(postmodern:connect-toplevel \"dbmail\" \"dbmail_admin\" \"\" \"mail-database\")") #<NULL-LEXENV>)
  13: (EVAL (SWANK-REPL:LISTENER-EVAL "(postmodern:connect-toplevel \"dbmail\" \"dbmail_admin\" \"\" \"mail-database\")"))
  14: (SWANK:EVAL-FOR-EMACS (SWANK-REPL:LISTENER-EVAL "(postmodern:connect-toplevel \"dbmail\" \"dbmail_admin\" \"\" \"mail-database\")") "CL-USER" 9912)
  15: (SWANK::PROCESS-REQUESTS NIL)
  16: ((LAMBDA NIL :IN SWANK::HANDLE-REQUESTS))
  17: ((LAMBDA NIL :IN SWANK::HANDLE-REQUESTS))
  18: (SWANK/SBCL::CALL-WITH-BREAK-HOOK #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL :IN SWANK::HANDLE-REQUESTS) {100597802B}>)
  19: ((FLET SWANK/BACKEND:CALL-WITH-DEBUGGER-HOOK :IN "/home/omg/quicklisp/dists/quicklisp/software/slime-v2.27/swank/sbcl.lisp") #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL :IN SWANK::HAN..
  20: (SWANK::CALL-WITH-BINDINGS ((*STANDARD-INPUT* . #<SWANK/GRAY::SLIME-INPUT-STREAM {10060F6883}>)) #<FUNCTION (LAMBDA NIL :IN SWANK::HANDLE-REQUESTS) {100597804B}>)
  21: (SWANK::HANDLE-REQUESTS #<SWANK::MULTITHREADED-CONNECTION {1005D57D03}> NIL)
  22: ((FLET SB-UNIX::BODY :IN SB-THREAD::RUN))
  23: ((FLET "WITHOUT-INTERRUPTS-BODY-11" :IN SB-THREAD::RUN))
  24: ((FLET SB-UNIX::BODY :IN SB-THREAD::RUN))
  25: ((FLET "WITHOUT-INTERRUPTS-BODY-4" :IN SB-THREAD::RUN))
  26: (SB-THREAD::RUN)
  27: ("foreign function: call_into_lisp")
  28: ("foreign function: funcall1")

But this seems to be addressed to cl-postgress

[sabracrolleton]

So what happens when you hit 0 for reconnect?

[hemml]

Hitting the "reconnect" leads to the same error again But I found a workaround: (setf ironclad::*os-prng-stream* nil) fixes the problem. So, this is an ironclad issue, sorry.

[sabracrolleton]

Interesting. Cl-postgres uses ironclad only if the postgresql database is using scram authentication (the default as of postgresql version 13). Intuitively, I can see the need to reset ironclad's random number generator to nil before saving an instance but I have not looked at the code.

Here is another workaround, if you are just working with a local instance of postgresql and are not as concerned about the postgresql level of security on authentication. You can reset the authentication method to trust or md5 in the pg_hba.conf file. If you do not know where that is stored on your setup, (pomo:query "show config_file" :single) will tell you where the postgresql.conf file is and the pg_hba.conf file will be in the same directory.

Do you want to close the issue?

[hemml]

Unfortunately, I'm using remote (located in another container) database and I don't want to swith to md5 for some reasons. Thank you for the explanation, I will contact with ironclad developers with this issue.