From thompdump at gmail.com Fri May 15 14:19:05 2009 From: thompdump at gmail.com (david thompson) Date: Fri, 15 May 2009 07:19:05 -0700 Subject: [postmodern-devel] cl-postgres/sbcl crashes with bogus stack frame Message-ID: Any ideas what might trigger cl-postgres (postmodern 1.14) coming to its knees with the backtrace shown below? No error or condition description is given - sbcl (1.0.28) just retires from active duty and drops into the debugger with the ("bogus stack frame") indication. The postgresql server (8.3) log doesn't have any indication of trouble at the time cl-postgres seems to run into trouble. This seems to only happen intermittently (every few thousand queries), irreproducibly (doesn't seem to be associated with a specific query or anything along those lines), and only when the postgresql server is being utilized by several lisp instances concurrently. Thanks in advance for any input/ideas/troubleshooting suggestions... - Alan ... 32: ("bogus stack frame") 33: (SB-IMPL::SUB-SUB-SERVE-EVENT NIL NIL) 34: (SB-IMPL::SUB-SERVE-EVENT NIL NIL NIL) 35: (SB-SYS:WAIT-UNTIL-FD-USABLE 5 :INPUT NIL) 36: (SB-IMPL::REFILL-INPUT-BUFFER #) 37: (SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE # T NIL) 38: (CL-POSTGRES::SKIP-BYTES # #) 39: (CL-POSTGRES::TRY-TO-SYNC # T) 40: ((FLET #:CLEANUP-FUN-[FORM-FUN-[SEND-QUERY]389]390))[:CLEANUP] 41: (CL-POSTGRES::SEND-QUERY # # #) 42: ((LABELS #:G161)) 43: (SQLG::QUERY-CORE "select program from programs where programskey = '192828' ;" 20 #) From marijnh at gmail.com Fri May 15 15:50:26 2009 From: marijnh at gmail.com (Marijn Haverbeke) Date: Fri, 15 May 2009 17:50:26 +0200 Subject: [postmodern-devel] cl-postgres/sbcl crashes with bogus stack frame In-Reply-To: References: Message-ID: There has been some noise on #lisp the past days about current usocket using an internal SBCL feature that's breaking with current SBCL. Try downgrading your SBCL to see if that solves the problem, and if it does, wait for an usocket update. I recently patched cl-postgres to use the non-portable socket interface when on ACL, I think I had to change only three lines. You could try a similar thing for SBCL. Attila also talked about having cl-postgres use iolib (though that has the disadvantage of a huge set of dependencies). Best, Marijn From attila.lendvai at gmail.com Mon May 18 11:14:05 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 18 May 2009 13:14:05 +0200 Subject: [postmodern-devel] cl-postgres/sbcl crashes with bogus stack frame In-Reply-To: References: Message-ID: > There has been some noise on #lisp the past days about current usocket > using an internal SBCL feature that's breaking with current SBCL. Try > downgrading your SBCL to see if that solves the problem, and if it > does, wait for an usocket update. that's not it and it only happens with a few days old, freshly compiled sbcl. on the other hand sbcl's network stuff is the last source of major stability issues we have with our codebase, that's why i have it on my TODO to add an option to use iolib for the network communication in cl-postgres. i've seen sub-serve-event too many times in weird backtraces... a few days ago i had a 30 min timeframe to move cl-postgres to iolib/babel, but gave up on something. iirc, the read-a-string-until-a-zero-byte-comes was unnecessarily hard to implement with the current iolib streams (which are being worked on currently by Stelian). -- attila From lucas.r.hope at gmail.com Tue May 26 04:55:19 2009 From: lucas.r.hope at gmail.com (Lucas Hope) Date: Tue, 26 May 2009 14:55:19 +1000 Subject: [postmodern-devel] with-connection is strange... Message-ID: <69fb852b0905252155w244a4c5ci811cd3e9615f128d@mail.gmail.com> Hi there, The macro with-connection doesn't seem to work as I would expect. It seems two macros were merged... I am curious as to why the following definition is used: (defmacro with-connection (spec &body body) "Like with-connection, but evaluate the specification list." `(let ((*database* (apply #'connect ,spec))) (unwind-protect (progn , at body) (disconnect *database*)))) Note the documentation above. I think a more standard "with-" macro doesn't evaluate the spec (like below). (defmacro with-connection (spec &body body) "Like with-connection, but evaluate the specification list." `(let ((*database* (connect , at spec))) (unwind-protect (progn , at body) (disconnect *database*)))) What's the reasoning here? -Luke From marijnh at gmail.com Tue May 26 05:49:26 2009 From: marijnh at gmail.com (Marijn Haverbeke) Date: Tue, 26 May 2009 07:49:26 +0200 Subject: [postmodern-devel] with-connection is strange... In-Reply-To: <69fb852b0905252155w244a4c5ci811cd3e9615f128d@mail.gmail.com> References: <69fb852b0905252155w244a4c5ci811cd3e9615f128d@mail.gmail.com> Message-ID: It indeed used to not evaluate it's spec (which explains the silly comment, there was also a with-connection* which did), but now it does, since this makes using it much easier -- you'll usually want to pass such a spec around as a list, and it's clumsy to have to unpack it every time you use the macro: (with-connection ((car spec) (cadr spec) (caddr spec)) ...) So in version 1.1 (I think) I dropped the old non-evaluating version, and made only this one available. I'll change the docstring. Best, Marijn From daniel at whitehouse.id.au Thu May 28 12:44:20 2009 From: daniel at whitehouse.id.au (Daniel White) Date: Thu, 28 May 2009 22:44:20 +1000 Subject: [postmodern-devel] IF-EXISTS operator for DROP-* ops Message-ID: <20090528224420.0d0b45ea@whitehouse.id.au> I'm wanting to use the IF EXISTS modifier for the various DROP operations, and it seems like the semantics of CASCADE works best for this case. The following is a proof of concept implementation. If there aren't any issues or complaints I'll write a patch that covers the rest of the DROP operations. (defvar *expand-if-exists* nil) (defun expand-if-exists () (when *expand-if-exists* `("IF EXISTS "))) (def-sql-op :if-exists (op) (let ((*expand-if-exists* t)) (sql-expand op))) (def-sql-op :drop-sequence (name) `("DROP SEQUENCE " ,@(expand-if-exists) ,@(sql-expand name))) (sql (:if-exists (:drop-sequence 'sequence))) Cheers, -- Daniel White From marijnh at gmail.com Thu May 28 17:12:53 2009 From: marijnh at gmail.com (Marijn Haverbeke) Date: Thu, 28 May 2009 19:12:53 +0200 Subject: [postmodern-devel] IF-EXISTS operator for DROP-* ops In-Reply-To: <20090528224420.0d0b45ea@whitehouse.id.au> References: <20090528224420.0d0b45ea@whitehouse.id.au> Message-ID: Good suggestion, but I think the special variable thing is a bit more cognitive overload than it's worth. I just added an extra argument to all the :drop-... operators, and am now generating them through a macro. Pull from repository to see the change. Best, Marijn From thompdump at gmail.com Thu May 28 21:26:16 2009 From: thompdump at gmail.com (david thompson) Date: Thu, 28 May 2009 14:26:16 -0700 Subject: [postmodern-devel] cl-postgres/sbcl crashes with bogus stack frame In-Reply-To: References: Message-ID: On Mon, May 18, 2009 at 4:14 AM, Attila Lendvai wrote: >> Try >> downgrading your SBCL to see if that solves the problem, and if it >> does, wait for an usocket update. > > > that's not it and it only happens with a few days old, freshly compiled sbcl. > > on the other hand sbcl's network stuff is the last source of major > stability issues we have with our codebase, that's why i have it on my > TODO to add an option to use iolib for the network communication in > cl-postgres. i've seen sub-serve-event too many times in weird > backtraces... > It's definitely not a postmodern/cl-postgres issue... Out of curiosity, I tried using CLSQL (4.0.3) with its :postgresql-socket interface under similar circumstances. Ended up with similar SBCL unhappiness: nothing showing up in the postgresql server log but "broken pipe" errors triggering SBCL (1.0.28) sporadically dropping into ldb with Signal 13 masked fatal error encountered in SBCL pid [somepid](tid [sometid]): some deferrable signals blocked, some unblocked The ldb backtraces all look pretty similar (example backtrace below). - Alan Backtrace: 0: Foreign fp = 0xb70abec8, ra = 0x8059314 1: Foreign fp = 0xb70abee8, ra = 0x8055afe 2: Foreign fp = 0xb70abf98, ra = 0x8056616 3: Foreign fp = 0xb70abfd8, ra = 0x8056f0b 4: Foreign fp = 0xb70abff8, ra = 0x8057089 5: Foreign fp = 0xb70ac028, ra = 0x8058c4a 6: Foreign fp = 0xb70ac444, ra = 0xb7fe5440 7: Foreign fp = 0xb70ac564, ra = 0xb75c6b79 8: Foreign fp = 0xb70ac724, ra = 0xb75c6ced 9: Foreign fp = 0xb70ac854, ra = 0xb75be9be 10: Foreign fp = 0xb70ac874, ra = 0xb75bc36b 11: Foreign fp = 0xb70ac894, ra = 0xb75be00c 12: (SB-PCL::FAST-METHOD CLSQL-SYS::DATABASE-QUERY (COMMON-LISP::T CLSQL-POSTGRESQL::POSTGRESQL-DATABASE COMMON-LISP::T COMMON-LISP::T)) 13: (COMMON-LISP::LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1. SB-PCL::.ARG2. SB-PCL::.ARG3.)) 14: (SB-C::TL-XEP (SB-PCL::FAST-METHOD CLSQL-SYS::QUERY (COMMON-LISP::STRING))) 15: (SB-C::TL-XEP SQLG::COLUMNS-FROM-TABLE-WHERE) 16: SQLG::ATOM-FROM-TABLE-WHERE 17: RP-GENEVAL::GET-PROGRAM-FROM-DB 18: (SB-C::TL-XEP RP-GENEVAL::GET-TEMPLATE-MATCH01) 19: RP-GENEVAL::KSST-CORE 20: SB-INT::SIMPLE-EVAL-IN-LEXENV 21: (SB-C::HAIRY-ARG-PROCESSOR RP-GENEVAL::KRW) 22: RP-GENEVAL::KRWU 23: SB-INT::SIMPLE-EVAL-IN-LEXENV 24: (SB-C::HAIRY-ARG-PROCESSOR RP-GENEVAL::KRW) 25: RP-GENEVAL::KRWU 26: SB-INT::SIMPLE-EVAL-IN-LEXENV 27: (SB-C::HAIRY-ARG-PROCESSOR RP-GENEVAL::RPG-EVAL) 28: (SB-C::HAIRY-ARG-PROCESSOR RP-GENEVAL::EVAL-METHOD) 29: (SB-C::HAIRY-ARG-PROCESSOR RP-GENEVAL::CRITERION-FUNCTION) 30: (SB-C::HAIRY-ARG-PROCESSOR RP-GENEVAL::EVALUATE-PROGRAM-INTERNAL) 31: (SB-C::TL-XEP RP-GENEVAL::EVALUATE-*PROGRAM-POPULATION*-FITNESS)