Crash in Arch Linux with SBCL 1.0.55

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Crash in Arch Linux with SBCL 1.0.55

Stephen Balousek
Hi,

I am getting a strange, intermittent crash of StumpWM and I am looking for pointers on how to resolve it, or possible workarounds.

The relevant information from ~/.xsession-errors is:
Caught 'The value -28580123 is not of type UNSIGNED-BYTE.' at the top level. Please report this.
0: (SB-DEBUG::MAP-BACKTRACE
    #<CLOSURE (LAMBDA # :IN SB-DEBUG:BACKTRACE) {100555C56B}>
    :START
    0
    :COUNT
    100)
1: (SB-DEBUG:BACKTRACE 100 #<SB-IMPL::STRING-OUTPUT-STREAM {100555C463}>)
2: (BACKTRACE-STRING)
3: (PERFORM-TOP-LEVEL-ERROR-ACTION
    #<TYPE-ERROR expected-type: UNSIGNED-BYTE datum: -28580123>)
4: (SIGNAL #<TYPE-ERROR expected-type: UNSIGNED-BYTE datum: -28580123>)
5: (ERROR TYPE-ERROR :DATUM -28580123 :EXPECTED-TYPE UNSIGNED-BYTE)
6: (SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER
    #<unavailable argument>
    #.(SB-SYS:INT-SAP #X7FFFF704E9F8)
    #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X7FFFF704E3C0 :TYPE (*
                                                                (SB-ALIEN:STRUCT
                                                                 SB-VM::OS-CONTEXT-T-STRUCT))>
    (84 21))
7: (SB-KERNEL:INTERNAL-ERROR
    #.(SB-SYS:INT-SAP #X7FFFF704E3C0)
    #<unavailable argument>)
8: ("foreign function: #x4180DF")

debugger invoked on a TYPE-ERROR in thread
#<THREAD "initial thread" RUNNING {1003BA8E23}>:
  The value -28580118 is not of type UNSIGNED-BYTE.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

(no restarts: If you didn't do this on purpose, please report it as a bug.)

(SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER
 #<unavailable argument>
 #.(SB-SYS:INT-SAP #X7FFFF704EEB0)
 #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X7FFFF704E880 :TYPE (*
                                                             (STRUCT
                                                              SB-VM::OS-CONTEXT-T-STRUCT))>
 (84 21))
0]

Can anyone tell if this is a StumpWM issue or an SBCL issue?  I am thinking it is an issue with the FFI layer in SBCL, but any other interpretations would be appreciated.

Thanks,
- Steve

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Crash in Arch Linux with SBCL 1.0.55

Vladimir Sedach
It looks like the backtrace gets cut off before reaching the actually
relevant part. I'm not sure off the top of my head how to control the
length of backtraces being printed - is there anything like that in
the error handling of stumpwm?

Vladimir

On Tue, Feb 28, 2012 at 9:15 AM, Stephen Balousek <[hidden email]> wrote:

> Hi,
>
> I am getting a strange, intermittent crash of StumpWM and I am looking for
> pointers on how to resolve it, or possible workarounds.
>
> The relevant information from ~/.xsession-errors is:
>
> Caught 'The value -28580123 is not of type UNSIGNED-BYTE.' at the top level.
> Please report this.
> 0: (SB-DEBUG::MAP-BACKTRACE
>     #<CLOSURE (LAMBDA # :IN SB-DEBUG:BACKTRACE) {100555C56B}>
>     :START
>     0
>     :COUNT
>     100)
> 1: (SB-DEBUG:BACKTRACE 100 #<SB-IMPL::STRING-OUTPUT-STREAM {100555C463}>)
> 2: (BACKTRACE-STRING)
> 3: (PERFORM-TOP-LEVEL-ERROR-ACTION
>     #<TYPE-ERROR expected-type: UNSIGNED-BYTE datum: -28580123>)
> 4: (SIGNAL #<TYPE-ERROR expected-type: UNSIGNED-BYTE datum: -28580123>)
> 5: (ERROR TYPE-ERROR :DATUM -28580123 :EXPECTED-TYPE UNSIGNED-BYTE)
> 6: (SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER
>     #<unavailable argument>
>     #.(SB-SYS:INT-SAP #X7FFFF704E9F8)
>     #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X7FFFF704E3C0 :TYPE (*
>
> (SB-ALIEN:STRUCT
>
> SB-VM::OS-CONTEXT-T-STRUCT))>
>     (84 21))
> 7: (SB-KERNEL:INTERNAL-ERROR
>     #.(SB-SYS:INT-SAP #X7FFFF704E3C0)
>     #<unavailable argument>)
> 8: ("foreign function: #x4180DF")
>
> debugger invoked on a TYPE-ERROR in thread
> #<THREAD "initial thread" RUNNING {1003BA8E23}>:
>   The value -28580118 is not of type UNSIGNED-BYTE.
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> (no restarts: If you didn't do this on purpose, please report it as a bug.)
>
> (SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER
>  #<unavailable argument>
>  #.(SB-SYS:INT-SAP #X7FFFF704EEB0)
>  #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X7FFFF704E880 :TYPE (*
>                                                              (STRUCT
>
> SB-VM::OS-CONTEXT-T-STRUCT))>
>  (84 21))
> 0]
>
>
> Can anyone tell if this is a StumpWM issue or an SBCL issue?  I am thinking
> it is an issue with the FFI layer in SBCL, but any other interpretations
> would be appreciated.
>
> Thanks,
> - Steve
>
> _______________________________________________
> Stumpwm-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
>

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crash in Arch Linux with SBCL 1.0.55

Stephen Balousek
In reply to this post by Stephen Balousek
Hi,

I managed to get a repeat of this crash - this time with more information about the point of failure.

Judging from the functions involved, I am guessing this might be an issue with CLX.  Any other ideas would be appreicated.

- Steve

Caught 'The value -25040316 is not of type UNSIGNED-BYTE.' at the top level. Please report this.
0: (SB-DEBUG::MAP-BACKTRACE
    #<CLOSURE (LAMBDA #) {10043F95D9}>
    :START
    0
    :COUNT
    100)
1: (SB-DEBUG:BACKTRACE 100 #<SB-IMPL::STRING-OUTPUT-STREAM {10043F9531}>)
2: (BACKTRACE-STRING)
3: (PERFORM-TOP-LEVEL-ERROR-ACTION
    #<TYPE-ERROR expected-type: UNSIGNED-BYTE datum: -25040316>)
4: (SIGNAL #<TYPE-ERROR expected-type: UNSIGNED-BYTE datum: -25040316>)
5: (ERROR TYPE-ERROR :DATUM -25040316 :EXPECTED-TYPE UNSIGNED-BYTE)
6: (SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER
    #<unavailable argument>
    #.(SB-SYS:INT-SAP #X7FFFF6CD6E98)
    #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X7FFFF6CD6880 :TYPE (*
                                                                (SB-ALIEN:STRUCT
                                                                 SB-VM::OS-CONTEXT-T-STRUCT))>
    (84 21))
7: (SB-KERNEL:INTERNAL-ERROR
    #.(SB-SYS:INT-SAP #X7FFFF6CD6880)
    #<unavailable argument>)
8: ("foreign function: call_into_lisp")
9: ("foreign function: funcall2")
10: ("foreign function: interrupt_internal_error")
11: ("foreign function: handle_trap")
12: ("foreign function: #x4104D3")
13: (GET-INTERNAL-REAL-TIME)
14: (SB-SYS:DECODE-TIMEOUT NIL)
15: (SB-SYS:WAIT-UNTIL-FD-USABLE 4 :INPUT NIL T)
16: (XLIB::BUFFER-INPUT-WAIT-DEFAULT
     #<XLIB:DISPLAY :0 (The X.Org Foundation R11200000)>
     NIL)
17: (XLIB::BUFFER-INPUT-WAIT
     #<XLIB:DISPLAY :0 (The X.Org Foundation R11200000)>
     NIL)
18: (XLIB::READ-INPUT
     #<XLIB:DISPLAY :0 (The X.Org Foundation R11200000)>
     NIL
     NIL
     #<FUNCTION (LAMBDA #) {100259B509}>
     #S(XLIB::PENDING-COMMAND
        :SEQUENCE 6705
        :REPLY-BUFFER NIL
        :PROCESS #<SB-THREAD:THREAD "initial thread" RUNNING {1003B08E11}>
        :NEXT NIL))
19: (XLIB::READ-REPLY #<unavailable argument> #<unavailable argument>)
20: (XLIB:DISPLAY-FINISH-OUTPUT
     #<XLIB:DISPLAY :0 (The X.Org Foundation R11200000)>)
21: (HANDLE-EVENT
     :DISPLAY
     #<XLIB:DISPLAY :0 (The X.Org Foundation R11200000)>
     :EVENT-KEY
     :PROPERTY-NOTIFY
     :EVENT-CODE
     28
     :SEND-EVENT-P
     NIL
     :SEQUENCE
     6704
     :WINDOW
     #<XLIB:WINDOW :0 100000F>
     :EVENT-WINDOW
     #<XLIB:WINDOW :0 100000F>
     :ATOM
     :_NET_WM_USER_TIME
     :TIME
     283134
     :STATE
     :NEW-VALUE)
22: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK))
23: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE-LOCK]333))
24: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK
     #<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK) {7FFFF6CD7839}>
     #<SB-THREAD:MUTEX "CLX Event Lock"
         owner: #<SB-THREAD:THREAD "initial thread" RUNNING {1003B08E11}>>)
25: (XLIB:PROCESS-EVENT
     #<XLIB:DISPLAY :0 (The X.Org Foundation R11200000)>
     :HANDLER
     #<FUNCTION HANDLE-EVENT>
     :TIMEOUT
     NIL
     :PEEK-P
     NIL
     :DISCARD-P
     NIL
     :FORCE-OUTPUT-P
     T)
26: (STUMPWM-INTERNAL-LOOP)
27: (STUMPWM-INTERNAL ":0")
28: (STUMPWM ":0")
29: ((LAMBDA ()))
30: ((FLET #:WITHOUT-INTERRUPTS-BODY-[RESTART-LISP]38))
31: ((LABELS SB-IMPL::RESTART-LISP))

debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" RUNNING
                                              {1003B08E11}>:
  The value -25040307 is not of type UNSIGNED-BYTE.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

(no restarts: If you didn't do this on purpose, please report it as a bug.)

(GET-INTERNAL-REAL-TIME)
0]



On 02/28/2012 06:15 AM, Stephen Balousek wrote:
Hi,

I am getting a strange, intermittent crash of StumpWM and I am looking for pointers on how to resolve it, or possible workarounds.

The relevant information from ~/.xsession-errors is:
Caught 'The value -28580123 is not of type UNSIGNED-BYTE.' at the top level. Please report this.
0: (SB-DEBUG::MAP-BACKTRACE
    #<CLOSURE (LAMBDA # :IN SB-DEBUG:BACKTRACE) {100555C56B}>
    :START
    0
    :COUNT
    100)
1: (SB-DEBUG:BACKTRACE 100 #<SB-IMPL::STRING-OUTPUT-STREAM {100555C463}>)
2: (BACKTRACE-STRING)
3: (PERFORM-TOP-LEVEL-ERROR-ACTION
    #<TYPE-ERROR expected-type: UNSIGNED-BYTE datum: -28580123>)
4: (SIGNAL #<TYPE-ERROR expected-type: UNSIGNED-BYTE datum: -28580123>)
5: (ERROR TYPE-ERROR :DATUM -28580123 :EXPECTED-TYPE UNSIGNED-BYTE)
6: (SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER
    #<unavailable argument>
    #.(SB-SYS:INT-SAP #X7FFFF704E9F8)
    #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X7FFFF704E3C0 :TYPE (*
                                                                (SB-ALIEN:STRUCT
                                                                 SB-VM::OS-CONTEXT-T-STRUCT))>
    (84 21))
7: (SB-KERNEL:INTERNAL-ERROR
    #.(SB-SYS:INT-SAP #X7FFFF704E3C0)
    #<unavailable argument>)
8: ("foreign function: #x4180DF")

debugger invoked on a TYPE-ERROR in thread
#<THREAD "initial thread" RUNNING {1003BA8E23}>:
  The value -28580118 is not of type UNSIGNED-BYTE.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

(no restarts: If you didn't do this on purpose, please report it as a bug.)

(SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER
 #<unavailable argument>
 #.(SB-SYS:INT-SAP #X7FFFF704EEB0)
 #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X7FFFF704E880 :TYPE (*
                                                             (STRUCT
                                                              SB-VM::OS-CONTEXT-T-STRUCT))>
 (84 21))
0]

Can anyone tell if this is a StumpWM issue or an SBCL issue?  I am thinking it is an issue with the FFI layer in SBCL, but any other interpretations would be appreciated.

Thanks,
- Steve


_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Crash in Arch Linux with SBCL 1.0.55

Vitaly Mayatskikh
At Thu, 05 Apr 2012 18:10:40 -0700, Stephen Balousek wrote:

> I managed to get a repeat of this crash - this time with more
> information about the point of failure.
>
> Judging from the functions involved, I am guessing this might be an
> issue with CLX.  Any other ideas would be appreicated.

SBCL was a PITA to use with StupmWM since Medievals. Things are much
better now, it does not blow up that often, but I have personally
switched to CCL. It is almost as fast as SBCL and is definitely much
more stable.
--
wbr, Vitaly

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crash in Arch Linux with SBCL 1.0.55

David Bjergaard-2
Hi Vitaly,

While I haven't experienced any show stopping crashes, I do use Stump
with SBCL.

Is there a way to get multi-threading with CCL? I want to be able to
connect with SWANK via emacs.

        Dave

Vitaly Mayatskikh <[hidden email]> writes:

> At Thu, 05 Apr 2012 18:10:40 -0700, Stephen Balousek wrote:
>
>> I managed to get a repeat of this crash - this time with more
>> information about the point of failure.
>>
>> Judging from the functions involved, I am guessing this might be an
>> issue with CLX.  Any other ideas would be appreicated.
>
> SBCL was a PITA to use with StupmWM since Medievals. Things are much
> better now, it does not blow up that often, but I have personally
> switched to CCL. It is almost as fast as SBCL and is definitely much
> more stable.

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crash in Arch Linux with SBCL 1.0.55

Vitaly Mayatskikh
At Mon, 16 Apr 2012 20:56:42 -0400, David Bjergaard wrote:

> While I haven't experienced any show stopping crashes, I do use Stump
> with SBCL.

Yeah, we've spent enormous amount of efforts on that 2 or 3 years
ago. Though SBCL works for me too, I've noticed that StumpWM likes CCL
a bit more.

> Is there a way to get multi-threading with CCL? I want to be able to
> connect with SWANK via emacs.

I have no problem with CCL, swank and slime:

CL-USER> stumpwm:*version*
"0.9.7-85-g6ac03c4 Compiled On Wed Feb 15 12:06:53"
CL-USER> (lisp-implementation-version)
"Version 1.7-r14925M  (LinuxX8664)"
CL-USER>.

--
wbr, Vitaly

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Crash in Arch Linux with SBCL 1.0.55

Stephen Balousek
In reply to this post by Vitaly Mayatskikh
On 04/16/2012 02:28 PM, Vitaly Mayatskikh wrote:
At Thu, 05 Apr 2012 18:10:40 -0700, Stephen Balousek wrote:

I managed to get a repeat of this crash - this time with more 
information about the point of failure.

Judging from the functions involved, I am guessing this might be an 
issue with CLX.  Any other ideas would be appreicated.
SBCL was a PITA to use with StupmWM since Medievals. Things are much
better now, it does not blow up that often, but I have personally
switched to CCL. It is almost as fast as SBCL and is definitely much
more stable.
Thanks for that, Vitaly.  StumpWM no longer crashes when compiled with CCL.

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

smime.p7s (5K) Download Attachment