From: Cyrus H. <ch...@bo...> - 2007-01-11 00:14:25
|
while trying to debug rucksack, when adding a (break) to btree-insert and attempting to get some info on the local variables in the frame, I get the following error: segmentation violation at #X10BB14A3 [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] Return to sldb level 1. 1: [CONTINUE] Return from BREAK. 2: [ABORT] Abort #<RUCKSACK:STANDARD-TRANSACTION #337746306300000 with 1 dirty object> 3: [RETRY] Retry #<RUCKSACK:STANDARD-TRANSACTION #337746306300000 with 1 dirty object> 4: [ABORT-REQUEST] Abort handling SLIME request. 5: [ABORT] Exit debugger, returning to top level. Backtrace: 0: ((FLET #:G199)) 1: (SB-UNIX::SIGSEGV-HANDLER #<unavailable argument> #<unavailable argument> #.(SB-SYS:INT-SAP #X022068E8)) 2: (SB-SYS:INVOKE-INTERRUPTION #<CLOSURE (LAMBDA #) {120601ED}>) 3: ("foreign function: call_into_lisp") 4: ("foreign function: funcall3") 5: ("foreign function: interrupt_handle_now") 6: ("foreign function: _sigtramp") 7: (TYPE-OF #<error printing object>) 8: ((FLET SB-IMPL::PRINT-DESCRIPTION)) 9: (SB-IMPL::%PRINT-UNREADABLE-OBJECT #<error printing object>) 10: ((LAMBDA ())) 11: ((LAMBDA (SWANK-BACKEND::FN)) #<CLOSURE (LAMBDA #) {1205ED75}>) 12: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA #) {1205ED75}>) 13: ((LAMBDA ())) 14: (SWANK::CALL-WITH-BINDINGS ((*PRINT-PRETTY* . T) (*PRINT-LEVEL* . 4) (*PRINT-LENGTH* . 10) (*PRINT-CIRCLE* . T) (*PRINT-READABLY*) (*PRINT-PPRINT-DISPATCH* . #<SB-PRETTY:PPRINT-DISPATCH-TABLE {11881019}>) (*PRINT-GENSYM* . T) (*PRINT-BASE* . 10) (*PRINT-RADIX*) (*PRINT-ARRAY* . T) ...) #<CLOSURE (LAMBDA #) {11D9546D}>) 15: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK:FRAME-LOCALS-FOR-EMACS 1) #<NULL-LEXENV>) 16: ((LAMBDA ())) 17: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {11D9530D}>) 18: (SWANK::SLDB-LOOP 1) 19: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #) {117155AD}>) --more-- don't know if this is a swank or an sbcl problem, but something seems wrong... Cyrus |
From: Attila L. <att...@gm...> - 2007-01-11 13:20:40
|
PiB3aGlsZSB0cnlpbmcgdG8gZGVidWcgcnVja3NhY2ssIHdoZW4gYWRkaW5nIGEgKGJyZWFrKSB0 byBidHJlZS1pbnNlcnQKPiBhbmQgYXR0ZW1wdGluZyB0byBnZXQgc29tZSBpbmZvIG9uIHRoZSBs b2NhbCB2YXJpYWJsZXMgaW4gdGhlIGZyYW1lLAo+IEkgZ2V0IHRoZSBmb2xsb3dpbmcgZXJyb3I6 Cj4KPiBzZWdtZW50YXRpb24gdmlvbGF0aW9uIGF0ICNYMTBCQjE0QTMKPiAgICAgW0NvbmRpdGlv biBvZiB0eXBlIFNJTVBMRS1FUlJPUl0KCmZ5aSwgc2JjbCBjdnMgKHVidW50dSwgeDg2LTMyKSBp cyBkeWluZyB3aGVuIHNvbWV0aGluZyBhYm91dCBkZWJ1Z2dpbmcKaXMgaW52b3ZsZWQuIHNvbWV0 aW1lcywgaSdtIGFsc28gZ2V0aW5nIGVycm9ycyBsaWtlIHRoaXMgd2hlbiB0aGUKc2xpbWUgZGVi dWdnZXIgcG9wcyB1cDoKCkZpbmFsIG9iamVjdCBwb2ludGVyIDB4MTA3YmZjYjAsIHN0YXJ0IDB4 ZGZiZjAwMCwgZW5kIDB4ZGZjMTAwMApmYXRhbCBlcnJvciBlbmNvdW50ZXJlZCBpbiBTQkNMIHBp ZCA3OTQ2KHRpZCAzMDQ2MDI2MTQ0KToKR0MgaW52YXJpYW50IGxvc3QsIGZpbGUgImdjLWNvbW1v bi5jIiwgbGluZSAxOTcKCmEgdmVyc2lvbiBjb21waWxlZCBmcm9tIGN2cyB1cCAtRCAyMDA3LTAx LTAxIGRvZXMgbm90IHByb2R1Y2UgdGhlc2UKY3Jhc2hlcyBpbiB0aGUgc2FtZSBlbnZpcm9ubWVu dC4KCmh0aCwKCi0tIAotIGF0dGlsYQoKIi0gVGhlIHRydXRoIGlzIHRoYXQgSSd2ZSBiZWVuIHRv byBjb25zaWRlcmF0ZSwgYW5kIHNvIGJlY2FtZQp1bmludGVudGlvbmFsbHkgY3J1ZWwuLi4KIC0g SSB1bmRlcnN0YW5kLgogLSBObywgeW91IGRvbid0IHVuZGVyc3RhbmQhIFdlIGRvbid0IHNwZWFr IHRoZSBzYW1lIGxhbmd1YWdlISIKKEluZ21hciBCZXJnbWFuIC0gU211bHRyb25zdMOkbGxldCkK |
From: Juho S. <js...@ik...> - 2007-01-11 19:47:06
|
"Attila Lendvai" <att...@gm...> writes: > > while trying to debug rucksack, when adding a (break) to btree-insert > > and attempting to get some info on the local variables in the frame, > > I get the following error: > > > > segmentation violation at #X10BB14A3 > > [Condition of type SIMPLE-ERROR] > > fyi, sbcl cvs (ubuntu, x86-32) is dying when something about debugging > is invovled. sometimes, i'm also geting errors like this when the > slime debugger pops up: > > Final object pointer 0x107bfcb0, start 0xdfbf000, end 0xdfc1000 > fatal error encountered in SBCL pid 7946(tid 3046026144): > GC invariant lost, file "gc-common.c", line 197 > > a version compiled from cvs up -D 2007-01-01 does not produce these > crashes in the same environment. Thanks for the reports. I believe this is fixed in 1.0.1.18. -- Juho Snellman |