From: Alain P. <Dr....@gm...> - 2009-09-27 00:45:24
|
G'day! I'm starting a new personal project, having used Lispworks for many years, and SBCL seems to be "the open source lisp of choice", right now. Great work guys! Now to the bad news... :-) I have a (multi-threaded) application, which I start like this: % sbcl --core myapp.core --eval "(mypackage:start)" Once in a blue moon, I experienced something rather odd; the threads meant to be launched by START haven't even been run yet, and the console is left, frozen, in a debugger, with a stack like this one: (READ-CHAR #<SB-SYS:FD-STREAM for "the terminal" {D283941}> NIL #:EOF-OBJECT #<unused argument>) 5[6] u (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "the terminal" {D283941}> NIL #:EOF-OBJECT) 4[6] u (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "the terminal" {D283941}>) 3[6] u (SB-SYS:WAIT-UNTIL-FD-USABLE 15 :INPUT NIL) 2[6] u (SB-SYS:DECODE-TIMEOUT NIL) 1[6] u (GET-INTERNAL-REAL-TIME) 0[6] u Top of stack. 0[6] Seems rather odd. The whole thing is started from `screen' when the machine boots. This was on sbcl 1.0.29. Haven't seen it since, but then again, I don't boot this machine terribly often ;-) Any clues will be welcome. Thanks! --Alain Picard -- Please read about why Top Posting is evil at: http://en.wikipedia.org/wiki/Top-posting and http://www.dickalba.demon.co.uk/usenet/guide/faq_topp.html Please read about why HTML in email is evil at: http://www.birdhouse.org/etc/evilmail.html |
From: Attila L. <att...@gm...> - 2009-09-27 09:07:19
|
> Any clues will be welcome. Thanks! maybe your're trying with a non-threaded sbcl? ...which was compiled without a customize-target-features that enables threading (which is not enabled by default)? -- attila |
From: Samium G. <_de...@fe...> - 2009-09-27 13:05:34
|
From: Attila Lendvai <att...@gm...> >> Any clues will be welcome. Thanks! > > maybe your're trying with a non-threaded sbcl? > > ...which was compiled without a customize-target-features that enables > threading (which is not enabled by default)? Wouldn't it then have been happening reproducibly, rather than "once in a blue moon"? regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org |
From: Robert G. <rpg...@si...> - 2009-09-27 16:44:16
|
Alain Picard wrote: > G'day! > > I'm starting a new personal project, having used Lispworks for many > years, and SBCL seems to be "the open source lisp of choice", right now. > Great work guys! > > > Now to the bad news... :-) > > I have a (multi-threaded) application, which I start like this: > > % sbcl --core myapp.core --eval "(mypackage:start)" > > Once in a blue moon, I experienced something rather odd; the > threads meant to be launched by START haven't even been run yet, > and the console is left, frozen, in a debugger, with a stack like > this one: > > (READ-CHAR #<SB-SYS:FD-STREAM for "the terminal" {D283941}> NIL #:EOF-OBJECT #<unused argument>) > 5[6] u > (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "the terminal" {D283941}> NIL #:EOF-OBJECT) > 4[6] u > (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "the terminal" {D283941}>) > 3[6] u > (SB-SYS:WAIT-UNTIL-FD-USABLE 15 :INPUT NIL) > 2[6] u > (SB-SYS:DECODE-TIMEOUT NIL) > 1[6] u > (GET-INTERNAL-REAL-TIME) > 0[6] u > > Top of stack. > 0[6] > > Seems rather odd. > > The whole thing is started from `screen' when the machine boots. > This was on sbcl 1.0.29. Haven't seen it since, but then again, > I don't boot this machine terribly often ;-) > > Any clues will be welcome. Thanks! > > --Alain Picard > I've had something like this happen to me before, but I'm afraid my memory is a bit hazy about it. IIRC, it happened to me on a program that was being run by a daemon, and there was some oddity about restoring *error-output* and/or *standard-output* with some piping we were doing. Is it possible that something is trying to read from the terminal without being properly hooked up to the terminal? Sorry I can't be more precise; I didn't take notes when we encountered and then fixed this bug. I mention this on the off-chance it will suggest something. best, r |
From: Alain P. <Dr....@gm...> - 2009-09-28 03:54:03
|
Robert Goldman <rpg...@si...> writes: > I've had something like this happen to me before, but I'm afraid my > memory is a bit hazy about it. IIRC, it happened to me on a program > that was being run by a daemon, and there was some oddity about > restoring *error-output* and/or *standard-output* with some piping we > were doing. Is it possible that something is trying to read from the > terminal without being properly hooked up to the terminal? > > Sorry I can't be more precise; I didn't take notes when we encountered > and then fixed this bug. I mention this on the off-chance it will > suggest something. Well, as I say, this only seems to happen when the system boots and launches `screen' from /etc/rc.local --- I haven't seen it lock up when I run the thing interactively, so it kinda sounds right, although it doesn't suggest anything to me. I'm not really expecting to be able to track this down; it sounds like a SBCL bug to me. I reported it on the off chance that it would spark some AHA reaction in a maintainer. Especially the bit about GET-INTERNAL-REAL-TIME seems very suspicious. But thanks for your input! --ap |
From: Nikodemus S. <nik...@ra...> - 2009-10-05 15:39:51
|
2009/9/28 Alain Picard <Dr....@gm...>: > I reported it on the off chance that it would spark some AHA reaction > in a maintainer. (READ-CHAR #<SB-SYS:FD-STREAM for "the terminal" {D283941}> NIL #:EOF-OBJECT #<unused argument>) 5[6] u the 5 [6] indicates that you're in a nested debugger session there. >From the debugger, the command error reprints the current error message and restarts, which should give a clue -- particularly when followed by aborting from the nested error and doing the same for the original error. My guess would be that 1. An error is signalled, and debugger entered. 2. The debugger tries to write to a stream that is closed, has a bad FD, or something. 3. A nested error is signalled from the debugger. > Especially the bit about GET-INTERNAL-REAL-TIME seems very suspicious. One possibility is that an asynch interrupt has occurred, which would explain the irregularity of the issue. Are you using WITH-TIMEOUT, by any chance? Cheers, -- Nikodemus |
From: Alain P. <dr....@gm...> - 2009-10-06 02:42:03
|
Nikodemus Siivola <nik...@ra...> writes: > My guess would be that > > 1. An error is signalled, and debugger entered. > 2. The debugger tries to write to a stream that is closed, has a bad > FD, or something. > 3. A nested error is signalled from the debugger. Maybe. But I wasn't using this interactively; it was started by an init script. >> Especially the bit about GET-INTERNAL-REAL-TIME seems very suspicious. > > One possibility is that an asynch interrupt has occurred, which would > explain the irregularity of the issue. Are you using WITH-TIMEOUT, by > any chance? No - at least not explicitly; and the main thread I was trying to launch (hunchentoot) probably does, but it hadn't got a chance to get going yet. Mysterious. --Alain |
From: Nikodemus S. <nik...@ra...> - 2009-10-06 09:17:45
|
2009/10/6 Alain Picard <dr....@gm...>: > Maybe. But I wasn't using this interactively; it was > started by an init script. For things like that you probably want to use the --disable-debugger toplevel option at minimum. Better yet, you can use the --script runtime option which implies pretty much all the things I would assume a thing like that would want. Cheers, -- Nikodemus |
From: Alain P. <dr....@gm...> - 2009-10-06 22:37:36
|
Nikodemus Siivola <nik...@ra...> writes: > 2009/10/6 Alain Picard <dr....@gm...>: > >> Maybe. But I wasn't using this interactively; it was >> started by an init script. > > For things like that you probably want to use the --disable-debugger > toplevel option at minimum. Better yet, you can use the --script > runtime option which implies pretty much all the things I would assume > a thing like that would want. Oh wow. That's great info. Thanks!! |