david thompson | 15 May 16:19 2009
Picon

cl-postgres/sbcl crashes with bogus stack frame

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 #<SB-SYS:FD-STREAM for "a socket" {C265BA9}>)
37: (SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE
     #<SB-SYS:FD-STREAM for "a socket" {C265BA9}>
     T
     NIL)
38: (CL-POSTGRES::SKIP-BYTES #<unavailable argument> #<unavailable argument>)
39: (CL-POSTGRES::TRY-TO-SYNC #<SB-SYS:FD-STREAM for "a socket" {C265BA9}> T)
40: ((FLET #:CLEANUP-FUN-[FORM-FUN-[SEND-QUERY]389]390))[:CLEANUP]
41: (CL-POSTGRES::SEND-QUERY
     #<unavailable argument>
(Continue reading)

Marijn Haverbeke | 15 May 17:50 2009
Picon

Re: cl-postgres/sbcl crashes with bogus stack frame

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
Attila Lendvai | 18 May 13:14 2009
Picon

Re: cl-postgres/sbcl crashes with bogus stack frame

> 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
david thompson | 28 May 23:26 2009
Picon

Re: cl-postgres/sbcl crashes with bogus stack frame

On Mon, May 18, 2009 at 4:14 AM, Attila Lendvai
<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
(Continue reading)


Gmane