[postmodern-devel] [patch] Erratic behavior when NIL password is given
Hi, I usually use host-based authentication with ident to connect to PostgreSQL from trusted machines, so I've been specifying a password of NIL for a long time. However, when passwordless authentication fails and NIL is given as a password, POSTMODERN:CONNECT will behave erratically. In my case, the symptoms are: * SBCL (Debian 1:1.0.18.0-2) RAM usage balloons to hundreds of megabytes. * I get this condition printed, along with a tag-along (obscure and what I assume to be) object, for the heck of it: ---8<---8<--- * (postmodern:connect "piranha" "piranha" nil "localhost") debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {1002669C31}>: The value NIL is not of type (MOD 1152921504606846975). Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-KERNEL:UB32-BASH-COPY "piranha" 0 "" NIL 7)[:EXTERNAL] --->8--->8--- That's invoking SBCL on the command-line. When I use SLIME: * SBCL, like a gas, expands to fill all available space (e.g. ~1.8GiB before I ran out of RAM+swap and rebooted the virtual machine). * During this time, nothing ever comes back to emacs. * If I do a SLIME interrupt before the system completely dies, emacs takes a while to do anything, then enters the emacs (not SLIME!) debugger, and informs me that the "variable binding depth exceeds max-specpdl-size" at every available opportunity until I restart emacs. It turns out bad things happen when you optimize for safety 0. Making this change: diff -x'*~' -urN postmodern-1.16/cl-postgres/package.lisp postmodern-1.16-no_opt/cl-postgres/package.lisp --- postmodern-1.16/cl-postgres/package.lisp 2010-04-02 04:23:24.000000000 -0700 +++ postmodern-1.16-no_opt/cl-postgres/package.lisp 2010-04-06 06:00:47.000000000 -0700 @@ -83,5 +83,5 @@ (eval-when (:compile-toplevel :load-toplevel :execute) ;; Optimization settings (only used by functions that need it). (defparameter *optimize* - '(optimize (speed 3) (safety 0) (space 1) (debug 1) + '(optimize (speed 3) (space 1) (debug 1) (compilation-speed 0)))) yields a much more sensible, instantaneous, and non-ballooning: The value NIL is not of type STRING. [Condition of type TYPE-ERROR] Of course, bad things also happen when you pass objects of the wrong type to a function. (It just never sat well with me to pass a string password when no password was needed; NIL seemed to make much more sense, and it worked...) I've attached a patch to: * Check the types of arguments given to CL-POSTGRES:OPEN-DATABASE. * Update the HTML documentation to describe the expected types of arguments to CL-POSTGRES:OPEN-DATABASE and POSTMODERN:CONNECT. * Update the documentation strings for the above two functions to contain the same content as their descriptions in the HTML documentation. I also humbly suggest not optimizing for safety 0. One of the big reasons I use CL, and not something like C, is because I value safety: when one thing breaks, that breakage is self-contained and can be tracked down due to conditions. I don't want my Lisp process to go down like the Hindenburg when one little thing goes wrong. Thanks for your time, -- J.P. Larocque <jpl@thoughtcrime.us>
Hello J.P.,
I usually use host-based authentication with ident to connect to PostgreSQL from trusted machines, so I've been specifying a password of NIL for a long time. However, when passwordless authentication fails and NIL is given as a password, POSTMODERN:CONNECT will behave erratically.
Hm, yes, I really shouldn't be passing un-type-checked parameters to functions compiled at (safety 0). I've applied a patch that adds your check-type forms, and made a change to allow NIL as password (the authentication code will raise an error when the server demands a password and none was given). I did not apply the full doc changes you submitted. I can see the value of thoroughness, but I think telling people that a usename should be a string etc. seems a superfluous (especially when it has to be done four times -- two docstrings and two html documents)
I also humbly suggest not optimizing for safety 0.
I see your point, yet when I profiled postmodern (back in 2007, on SBCL, not sure if this still holds) the speed difference between (safety 1) and (safety 0) was very significant (25% range, if I remember correctly). Memory safety in a chaotically-typed language like CL means a *lot* of checks. Feel free to run some benchmarks again, and see what you get (my benchmark consisted of inserting a lot of data, and making queries that returned huge result sets). Best, Marijn
On Tue, Apr 06, 2010 at 07:39:38PM +0200, Marijn Haverbeke wrote:
I usually use host-based authentication with ident to connect to PostgreSQL from trusted machines, so I've been specifying a password of NIL for a long time. However, when passwordless authentication fails and NIL is given as a password, POSTMODERN:CONNECT will behave erratically.
Hm, yes, I really shouldn't be passing un-type-checked parameters to functions compiled at (safety 0).
I've applied a patch that adds your check-type forms, and made a change to allow NIL as password (the authentication code will raise an error when the server demands a password and none was given).
Thanks! The pedantic doc changes I attached don't really fit in with the level of detail in the Postmodern HTML documentation (and especially the docstrings), so I understand why you'd want to leave those out.
I also humbly suggest not optimizing for safety 0.
I see your point, yet when I profiled postmodern (back in 2007, on SBCL, not sure if this still holds) the speed difference between (safety 1) and (safety 0) was very significant (25% range, if I remember correctly). Memory safety in a chaotically-typed language like CL means a *lot* of checks. Feel free to run some benchmarks again, and see what you get (my benchmark consisted of inserting a lot of data, and making queries that returned huge result sets).
Fair enough. Thanks, -- J.P. Larocque <jpl@thoughtcrime.us>
participants (2)
-
J.P. Larocque -
Marijn Haverbeke