From: <nye...@li...> - 2006-01-14 20:44:11
Attachments:
win32-backtrace.patch
|
Hello all, jamesjb and I have been looking at the problems with backtrace on Win32. He figured out what was going on, and I started figuring out how to fix it. Anyway, the attached patch fixes the lisp-side notion of where the control stack is, which makes backtraces work properly (the case which was breaking earlier was trying to backtrace through an internal-error). Unfortunately, this patch has a side effect. There are now constant notifications from VirtualProtect that it has failed with code 0x1e7. This turns out to be ERROR_INVALID_ADDRESS, and is because SBCL is attempting to install a stack guard page on uncommitted memory. The stack guard page stuff doesn't work on win32 -anyway-, so the easiest thing would be to disable it. --Alastair Bridgewater |
From: David L. <da...@li...> - 2006-04-06 19:35:06
|
Hi, Quoting nye...@li... (nye...@li...): > jamesjb and I have been looking at the problems with backtrace on Win32. He > figured out what was going on, and I started figuring out how to fix it. > > Anyway, the attached patch fixes the lisp-side notion of where the control > stack is, which makes backtraces work properly (the case which was breaking > earlier was trying to backtrace through an internal-error). FWIW, this patch seems to work well for me. Can it be checked into CVS? > Unfortunately, this patch has a side effect. There are now constant > notifications from VirtualProtect that it has failed with code 0x1e7. This > turns out to be ERROR_INVALID_ADDRESS, and is because SBCL is attempting to > install a stack guard page on uncommitted memory. The stack guard page > stuff doesn't work on win32 -anyway-, so the easiest thing would be to > disable it. Hmm, I don't see more VirtualProtect messages than without the patch. Thanks, David |
From: Rudi S. <ru...@co...> - 2006-04-07 08:50:06
Attachments:
PGP.sig
|
On 6. Apr 2006, at 21:35, David Lichteblau wrote: > Quoting nye...@li... (nye...@li...): >> Anyway, the attached patch fixes the lisp-side notion of where the >> control >> stack is, which makes backtraces work properly (the case which was >> breaking >> earlier was trying to backtrace through an internal-error). > > FWIW, this patch seems to work well for me. > > Can it be checked into CVS? Checked in as sbcl 0.9.11.17. Cheers, Rudi |
From: <mar...@gm...> - 2006-04-07 09:49:52
|
SSB0cmllZCB0byBidWlsZCAwLjkuMTEuMTYgb24gd2luMzIgbWluZ3cgKGFmdGVyIGZpbmFsbHkg c2V0dGluZyBhcmNoKQphbmQgZ290IHRoZSBmb2xsb3dpbmcgZXJyb3I6CgovL2VudGVyaW5nIG1h a2UtdGFyZ2V0LTIuc2gKLy9kb2luZyB3YXJtIGluaXQKVmlydHVhbEFsbG9jOiBObyBlcnJvcgpl bnN1cmVfc3BhY2U6IGZhaWxlZCB0byB2YWxpZGF0ZSA1MzY4NzA5MTIgYnl0ZXMgYXQgMHgwOTAw MDAwMAooaGludDogVHJ5ICJ1bGltaXQgLWEiOyBtYXliZSB5b3Ugc2hvdWxkIGluY3JlYXNlIG1l bW9yeSBsaW1pdHMuKQoKSSB3YXMgYm9vdHN0cmFwcGluZyBmcm9tIDAuOS4xMS44CgpJIHRyaWVk IGJvdGggbWFrZSB3aXRoIC9kZXYvbnVsbCBhbmQgTlVMIHBhcmFtZXRlcnMgdG8gc2JjbCwgYnV0 CnRoYXQncyBub3QgdGhlIHByb2JsZW0uIEknbGwgdHJ5IGFnYWluIHNvb24gYXMgYXJjaCBzeW5j aHJvbml6ZXMgdG8KMC45LjExLjE3CgpSZWdhcmRzLApNYXJrbwo= |
From: David L. <da...@li...> - 2006-04-07 10:35:39
|
Quoting Marko Koci?? (mar...@gm...): > I tried to build 0.9.11.16 on win32 mingw (after finally setting arch) > and got the following error: > > //entering make-target-2.sh > //doing warm init > VirtualAlloc: No error > ensure_space: failed to validate 536870912 bytes at 0x09000000 > (hint: Try "ulimit -a"; maybe you should increase memory limits.) Does the relocation patch at http://www.lichteblau.com/blubba/ help? Put relocate.c into src/runtime/ and run patch -p0 <relocate-4.diff (Which version of Windows is this?) d. |
From: <mar...@gm...> - 2006-04-07 11:14:44
|
PiA+IC8vZW50ZXJpbmcgbWFrZS10YXJnZXQtMi5zaAo+ID4gLy9kb2luZyB3YXJtIGluaXQKPiA+ IFZpcnR1YWxBbGxvYzogTm8gZXJyb3IKPiA+IGVuc3VyZV9zcGFjZTogZmFpbGVkIHRvIHZhbGlk YXRlIDUzNjg3MDkxMiBieXRlcyBhdCAweDA5MDAwMDAwCj4gPiAoaGludDogVHJ5ICJ1bGltaXQg LWEiOyBtYXliZSB5b3Ugc2hvdWxkIGluY3JlYXNlIG1lbW9yeSBsaW1pdHMuKQo+Cj4gRG9lcyB0 aGUgcmVsb2NhdGlvbiBwYXRjaCBhdCBodHRwOi8vd3d3LmxpY2h0ZWJsYXUuY29tL2JsdWJiYS8g aGVscD8KPiBQdXQgcmVsb2NhdGUuYyBpbnRvIHNyYy9ydW50aW1lLyBhbmQgcnVuIHBhdGNoIC1w MCA8cmVsb2NhdGUtNC5kaWZmCgpJcyB0aGF0IHBhdGNoIGNvbW1pdGVkIHRvIDAuOS4xMS4xNz8K SSBjYW4ndCB0cnkgaXQgcmlnaHQgbm93IGNhdXNlIEkgc2VlbSB0byBkZXN0cm95ZWQgbXkgYXJj aCBzb3VyY2UsIHNvCkknbSBmZXRjaGluZyBpdCBhZ2FpbiA7KApJJ2xsIHRyeSBhcyBzb29uIGFz IEkgY2FuLgoKPiAoV2hpY2ggdmVyc2lvbiBvZiBXaW5kb3dzIGlzIHRoaXM/KQpXaW4gWFAgU1Ay LCBtaW5ndywgZ2NjLTQuMQooSSBidWlsdCAwLjkuMTEuOCB3aXRoIHRoZSBzYW1lIHNldHVwKQoK PiBkLgo+Cg== |
From: Rudi S. <ru...@co...> - 2006-04-07 11:39:39
Attachments:
PGP.sig
|
On 7. Apr 2006, at 13:14, Marko Koci=C4=87 wrote: >>> //entering make-target-2.sh >>> //doing warm init >>> VirtualAlloc: No error >>> ensure_space: failed to validate 536870912 bytes at 0x09000000 >>> (hint: Try "ulimit -a"; maybe you should increase memory limits.) >> >> Does the relocation patch at http://www.lichteblau.com/blubba/ help? >> Put relocate.c into src/runtime/ and run patch -p0 <relocate-4.diff > > Is that patch commited to 0.9.11.17? No, it's not. I think that with the commit of tritchey's megapatch we have an =20 additional dependency on Shell32.dll (as can be seen by opening =20 sbcl.exe in Dependency Walker), which on your system seens to live in =20= a part of the memory space that sbcl needs for its core. An earlier =20 version of (parts of) the megapatch was rejected because it failed on =20= windows xp, although it ran on win2k. I'll test David's relocation patch as well. Cheers, Rudi |
From: Yaroslav K. <kav...@je...> - 2006-04-07 12:01:08
|
Rudi Schlatte wrote: > On 7. Apr 2006, at 13:14, Marko Kocić wrote: > >>>> //entering make-target-2.sh >>>> //doing warm init >>>> VirtualAlloc: No error >>>> ensure_space: failed to validate 536870912 bytes at 0x09000000 >>>> (hint: Try "ulimit -a"; maybe you should increase memory limits.) >>> Does the relocation patch at http://www.lichteblau.com/blubba/ help? >>> Put relocate.c into src/runtime/ and run patch -p0 <relocate-4.diff >> Is that patch commited to 0.9.11.17? > > No, it's not. > > I think that with the commit of tritchey's megapatch we have an > additional dependency on Shell32.dll (as can be seen by opening > sbcl.exe in Dependency Walker), which on your system seens to live in > a part of the memory space that sbcl needs for its core. An earlier > version of (parts of) the megapatch was rejected because it failed on > windows xp, although it ran on win2k. > But sbcl is builded and works with changes parms.lisp in 0.9.11.13 Thanks! -- WBR, Yaroslav Kavenchuk. |
From: David L. <da...@li...> - 2006-04-07 12:13:56
|
Quoting Yaroslav Kavenchuk (kav...@je...): > But sbcl is builded and works with changes parms.lisp in 0.9.11.13 So do you have settings for dynamic-space-start and -end that work with current SBCL sources on both Windows 2000 and Windows XP without requiring further workarounds? d. |
From: Yaroslav K. <kav...@je...> - 2006-04-07 12:21:37
|
David Lichteblau wrote: > Quoting Yaroslav Kavenchuk (kav...@je...): >> But sbcl is builded and works with changes parms.lisp in 0.9.11.13 > > So do you have settings for dynamic-space-start and -end that work with > current SBCL sources on both Windows 2000 and Windows XP without > requiring further workarounds? > I shall precisely say "Yes!" after sf.net will start work Thanks! -- WBR, Yaroslav Kavenchuk. |
From: Yaroslav K. <kav...@tu...> - 2006-04-11 21:24:53
|
David Lichteblau wrote: >> But sbcl is builded and works with changes parms.lisp in 0.9.11.13 >> > > So do you have settings for dynamic-space-start and -end that work with > current SBCL sources on both Windows 2000 and Windows XP without > requiring further workarounds? > > SBCL 0.9.11.8 - build on both Windows 2000 and Windows XP SBCL 0.9.11.29 - build on both Windows 2000 and Windows XP Thanks! -- WBR, Yaroslav Kavenchuk. |
From: Yaroslav K. <kav...@je...> - 2006-04-12 14:07:41
|
>> So do you have settings for dynamic-space-start and -end that work > with >> current SBCL sources on both Windows 2000 and Windows XP without >> requiring further workarounds? >> >> > SBCL 0.9.11.8 - build on both Windows 2000 and Windows XP > SBCL 0.9.11.29 - build on both Windows 2000 and Windows XP > Argh!!! Excuse me - I have not noticed. SBCL 0.9.11.29 after start gives out the message "VirtualProtect failed, code 0x1e7." :( (It was not in SBCL 0.9.11.8) Thanks! -- WBR, Yaroslav Kavenchuk. |
From: Yaroslav K. <kav...@je...> - 2006-04-13 07:33:23
|
Yaroslav Kavenchuk wrote: > Argh!!! Excuse me - I have not noticed. > SBCL 0.9.11.29 after start gives out the message "VirtualProtect failed, > > code 0x1e7." :( > (It was not in SBCL 0.9.11.8) Oops, message does not appear without patch 0.9.11.17 Patch note: 0.9.11.17 Merge patch "Backtrace on Win32" (sbcl-devel 2006-01-14) (Alastair Bridgewater) :) Somebody has other information? Thanks! -- WBR, Yaroslav Kavenchuk. |
From: Alastair B. <nye...@li...> - 2006-04-14 00:44:20
|
Yaroslav Kavenchuk writes: > Yaroslav Kavenchuk wrote: >> Argh!!! Excuse me - I have not noticed. >> SBCL 0.9.11.29 after start gives out the message "VirtualProtect failed, >> >> code 0x1e7." :( >> (It was not in SBCL 0.9.11.8) > > Oops, message does not appear without patch 0.9.11.17 > > Patch note: > > 0.9.11.17 > Merge patch "Backtrace on Win32" (sbcl-devel 2006-01-14) (Alastair > Bridgewater) > > > :) > > Somebody has other information? Sure. That's from the stack guard page stuff. It used to work because it was running against an sbcl-allocated stack. It fails now because it's running against the real stack (which theoretically already has a guard page anyway). If memory serves, this was mentioned when the patch was posted or shortly thereafter. > Thanks! > > -- > WBR, Yaroslav Kavenchuk. --Alastair Bridgewater |
From: David L. <da...@li...> - 2006-04-07 13:04:31
|
Quoting Marko Koci?? (mar...@gm...): > I can't try it right now cause I seem to destroyed my arch source, so > I'm fetching it again ;( > I'll try as soon as I can. That is fine: relocate-4.diff did not compile on Windows out of the box anyway. Here is a new patch that compiles for me: http://www.lichteblau.com/blubba/relocate-5.diff > Win XP SP2, mingw, gcc-4.1 Hmm, I have just copied a binary (compiled on Windows 2000) to XP Home SP 2 and that binary started just fine, without attempting to do relocation. d. |
From: <mar...@gm...> - 2006-04-07 15:47:40
|
SSBqdXN0IHRyaWVkIHRvIGNvbXBpbGUgIjAuOS4xMS4xOSIgcGF0Y2hlZCB3aXRoIHlvdXIgcGF0 Y2ggNSBhbmQKcmVsb2NhdGlvbi5jLCBhbmQgaXQgZmFpbGVkIGFnYWluIGluIG1ha2UtdGFyZ2V0 LTIKCi8vZW50ZXJpbmcgbWFrZS10YXJnZXQtMi5zaAovL2RvaW5nIHdhcm0gaW5pdApWaXJ0dWFs QWxsb2M6IE5vIGVycm9yCmZhdGFsIGVycm9yIGVuY291bnRlcmVkIGluIFNCQ0wgcGlkIDI0MjA6 CmZhaWxlZCB0byB2YWxpZGF0ZSBkeW5hbWljIHNwYWNlCgpyZWFsICAgIDBtMC42NDFzCnVzZXIg ICAgMG0wLjA0MHMKc3lzICAgICAwbTAuMDUwcwoKUmVnYXJkcywKTWFya28K |
From: David L. <da...@li...> - 2006-04-07 16:57:53
|
Quoting Marko Koci?? (mar...@gm...): > I just tried to compile "0.9.11.19" patched with your patch 5 and > relocation.c, and it failed again in make-target-2 > > //entering make-target-2.sh > //doing warm init > VirtualAlloc: No error > fatal error encountered in SBCL pid 2420: > failed to validate dynamic space Sorry. :-( Apply this in addition to relocate-5.diff: --- orig/src/runtime/win32-os.c +++ mod/src/runtime/win32-os.c @@ -168,7 +168,10 @@ if (!VirtualAlloc(addr, len, (mem_info.State == MEM_RESERVE)? MEM_COMMIT: MEM_RESERVE, PAGE_EXECUTE_READWRITE)) { perror("VirtualAlloc"); - return 0; + if (fixedp) + return 0; + else + return os_validate(0, len, 0); } return addr; |
From: <mar...@gm...> - 2006-04-10 12:14:05
|
T2ssIEkgdHJpZWQgdG8gYnVpbGQgIjAuOS4xMS4yNiIgZmlyc3Qgd2l0aG91dCBhbmQgbGF0ZXIg d2l0aCB5b3VyCnBhdGNoZXMsIGFuZCBhbSBzdGlsbCB1bmFibGUgdG8gYnVpbGQgaXQuIEhlcmUn cyB3aGF0IEkgZ2V0OgoKLy9lbnRlcmluZyBtYWtlLXRhcmdldC0yLnNoCi8vZG9pbmcgd2FybSBp bml0ClZpcnR1YWxBbGxvYzogTm8gZXJyb3IKVmlydHVhbEFsbG9jOiBObyBlcnJvcgpmYXRhbCBl cnJvciBlbmNvdW50ZXJlZCBpbiBTQkNMIHBpZCAyMjgwOgpmYWlsZWQgdG8gdmFsaWRhdGUgZHlu YW1pYyBzcGFjZQo= |
From: David L. <da...@li...> - 2006-04-10 12:42:17
|
Quoting Marko Koci?? (mar...@gm...): > Ok, I tried to build "0.9.11.26" first without and later with your > patches, and am still unable to build it. Here's what I get: Hmm. Errors in warm init can mean anything, but the specific errors you see must be relatively simple VirtualAlloc issues, I think. With my latest patch, relocation basically works for me, tested on Windows 2000 by mapping something into dynamic space before starting up. SBCL recognizes that and maps to somewhere else. On your installation, however, that does not seem to help: > //entering make-target-2.sh > //doing warm init > VirtualAlloc: No error os_validate tries to map to DEFAULT_DYNAMIC_SPACE_START, which fails. > VirtualAlloc: No error It then calls itself without a default address (as implemented in my last patch anyway), which should simply map to an area of DYNAMIC_SPACE_SIZE, no matter where it is. So apparently your Windows refuses to find DYNAMIC_SPACE_SIZE many bytes? > fatal error encountered in SBCL pid 2280: > failed to validate dynamic space ... which we cannot recover from, so we give up. I'll try to build directly on an XP installation with msys to reproduce this. d. PS Can someone please point me to the right msys installers by mail or IRC? I have been using cygwin so far and find the mingw download pages highly confusing. :-( Thanks. |
From: <mar...@gm...> - 2006-04-12 13:06:05
|
SSBzd2l0Y2hlZCBiYWNrIHRvIG1pbmd3IHdpdGggMy40LjQgZ2NjIGFuZCB0cmllZCB0byBjb21w aWxlIGFyY2ggaGVhZAp3aXRoIGFsbCB5b3VyIHBhdGNoZXMsIGJ1dCB3aXRoIG5vIHN1Y2Nlc3Mu CkkgYWRkZWQgc29tZSBkZWJ1ZyBvdXRwdXQgdG8gb3NfdmFsaWRhdGUgZnVuY3Rpb24gdG8gdHJh Y2sgaXRzCmV4ZWN1dGlvbi4gSXQgbm93IGxvb2tzIGxpa2U6Cgpvc192bV9hZGRyZXNzX3QKb3Nf dmFsaWRhdGUob3Nfdm1fYWRkcmVzc190IGFkZHIsIG9zX3ZtX3NpemVfdCBsZW4sIGludCBmaXhl ZHApCnsKCWZwcmludGYoc3RkZXJyLCIqKioqKipcbiIpOwoJZnByaW50ZihzdGRlcnIsImFkZHIg PSAlZFxuIiwgYWRkcik7CglmcHJpbnRmKHN0ZGVyciwibGVuID0gJWRcbiIsIGxlbik7CglmcHJp bnRmKHN0ZGVyciwiZml4ZWRwID0gJWRcbiIsIGZpeGVkcCk7CgkKICAgIE1FTU9SWV9CQVNJQ19J TkZPUk1BVElPTiBtZW1faW5mbzsKCiAgICBpZiAoIWFkZHIpIHsKICAgICAgIAlmcHJpbnRmKHN0 ZGVyciwibWtiZy0+MVxuIik7CiAgICAgICAgLyogdGhlIHNpbXBsZSBjYXNlIGZpcnN0ICovCiAg ICAgICAgb3Nfdm1fYWRkcmVzc190IHJlYWxfYWRkcjsKICAgICAgICBpZiAoIShyZWFsX2FkZHIg PSBWaXJ0dWFsQWxsb2MoYWRkciwgbGVuLCBNRU1fQ09NTUlULApQQUdFX0VYRUNVVEVfUkVBRFdS SVRFKSkpIHsKCSAgICAgICAJZnByaW50ZihzdGRlcnIsIm1rYmctPjJcbiIpOwoJICAgICAgIAlm cHJpbnRmKHN0ZGVyciwibWtiZy0+R2V0TGFzdEVycm9yKCk9JWRcbiIsIEdldExhc3RFcnJvcigp KTsKICAgICAgICAgICAgcGVycm9yKCJWaXJ0dWFsQWxsb2MiKTsKICAgICAgICAgICAgcmV0dXJu IDA7CiAgICAgICAgfQogICAgICAgCWZwcmludGYoc3RkZXJyLCJta2JnLT4zXG4iKTsKICAgICAg ICByZXR1cm4gcmVhbF9hZGRyOwogICAgfQogICAgZnByaW50ZihzdGRlcnIsInByaW50Zi0+NFxu Iik7CgogICAgaWYgKCFWaXJ0dWFsUXVlcnkoYWRkciwgJm1lbV9pbmZvLCBzaXplb2YgbWVtX2lu Zm8pKSB7CiAgICAJZnByaW50ZihzdGRlcnIsIm1rYmctPjVcbiIpOwogICAgICAgIHBlcnJvcigi VmlydHVhbFF1ZXJ5Iik7CiAgICAgICAgcmV0dXJuIDA7CiAgICB9CiAgICBmcHJpbnRmKHN0ZGVy ciwibWtiZy0+NlxuIik7CgogICAgaWYgKChtZW1faW5mby5TdGF0ZSA9PSBNRU1fUkVTRVJWRSkg JiYgKG1lbV9pbmZvLlJlZ2lvblNpemUKPj1sZW4pKSByZXR1cm4gYWRkcjsKICAgIGZwcmludGYo c3RkZXJyLCJta2JnLT43XG4iKTsKCiAgICBpZiAobWVtX2luZm8uU3RhdGUgPT0gTUVNX1JFU0VS VkUpIHsKICAgIAlmcHJpbnRmKHN0ZGVyciwibWtiZy0+OFxuIik7CiAgICAgICAgZnByaW50Zihz dGRlcnIsICJ2YWxpZGF0aW9uIG9mIHJlc2VydmVkIHNwYWNlIHRvbyBzaG9ydC5cbiIpOwogICAg ICAgIGZmbHVzaChzdGRlcnIpOwogICAgfQogICAgZnByaW50ZihzdGRlcnIsIm1rYmctPjlcbiIp OwoKICAgIGlmICghVmlydHVhbEFsbG9jKGFkZHIsIGxlbiwgKG1lbV9pbmZvLlN0YXRlID09IE1F TV9SRVNFUlZFKT8KTUVNX0NPTU1JVDogTUVNX1JFU0VSVkUsIFBBR0VfRVhFQ1VURV9SRUFEV1JJ VEUpKSB7CiAgICAJZnByaW50ZihzdGRlcnIsIm1rYmctPjEwXG4iKTsKICAgICAgICBwZXJyb3Io IlZpcnR1YWxBbGxvYyIpOwogICAgICAgIGlmIChmaXhlZHApIHsKICAgICAgICAJZnByaW50Zihz dGRlcnIsIm1rYmctPjExXG4iKTsKICAgICAgICAgICAgcmV0dXJuIDA7CiAgICAgICAgfSBlbHNl IHsKICAgICAgICAJZnByaW50ZihzdGRlcnIsIm1rYmctPjEyXG4iKTsKICAgICAgICAgICAgcmV0 dXJuIG9zX3ZhbGlkYXRlKDAsIGxlbiwgMCk7CiAgICAgICAgfQogICAgfQogICAgZnByaW50Zihz dGRlcnIsIm1rYmctPjEzXG4iKTsKCiAgICByZXR1cm4gYWRkcjsKfQoKT3V0cHV0IGZyb20gbWFr ZSB0YXJyZ2V0IDIgaXMgYXMgZm9sbG93czoKLy9lbnRlcmluZyBtYWtlLXRhcmdldC0yLnNoCi8v ZG9pbmcgd2FybSBpbml0ClZpcnR1YWxBbGxvYzogTm8gZXJyb3IKVmlydHVhbEFsbG9jOiBObyBl cnJvcgoqKioqKioKYWRkciA9IDMzNTU0NDMyCmxlbiA9IDQxOTM4OTQ0CmZpeGVkcCA9IDEKcHJp bnRmLT40Cm1rYmctPjYKbWtiZy0+Nwpta2JnLT45Cm1rYmctPjEzCioqKioqKgphZGRyID0gODM4 ODYwODAKbGVuID0gNTAzMjc1NTIKZml4ZWRwID0gMQpwcmludGYtPjQKbWtiZy0+Ngpta2JnLT43 Cm1rYmctPjkKbWtiZy0+MTMKKioqKioqCmFkZHIgPSA4MDUzMDYzNjgKbGVuID0gMjY4NDM1NDU2 CmZpeGVkcCA9IDEKcHJpbnRmLT40Cm1rYmctPjYKbWtiZy0+Nwpta2JnLT45Cm1rYmctPjEzCioq KioqKgphZGRyID0gMTUwOTk0OTQ0CmxlbiA9IDUzNjg3MDkxMgpmaXhlZHAgPSAwCnByaW50Zi0+ NApta2JnLT42Cm1rYmctPjcKbWtiZy0+OQpta2JnLT4xMApta2JnLT4xMgoqKioqKioKYWRkciA9 IDAKbGVuID0gNTM2ODcwOTEyCmZpeGVkcCA9IDAKbWtiZy0+MQpta2JnLT4yCm1rYmctPkdldExh c3RFcnJvcigpPTgKZmF0YWwgZXJyb3IgZW5jb3VudGVyZWQgaW4gU0JDTCBwaWQgMzUwNDoKZmFp bGVkIHRvIHZhbGlkYXRlIGR5bmFtaWMgc3BhY2UKCmVycm9yIDggcmV0dXJuZWQgaW4gbGFzdCBj YXNlIGlkICJub3QgZW5vdWdoIG1lbW9yeSIuCg== |
From: Friedrich D. <fr...@q-...> - 2006-04-07 09:24:19
|
I don't know if something has changes since ages I compile a new sbcl with ./make.sh 'sbcl --userinit /dev/null --sysinit /dev/null' But this days I got a message: arily disabled: proceed with caution unhandled SB-KERNEL::CONTROL-STACK-EXHAUSTED in thread #<SB-THREAD:THREAD "initial thread" {1002287C91}>: Control stack exhausted (no more space for function call frames). This is probably due to heavily nested or infinitely recursive function calls, or a tail call that SBCL cannot or has not optimized away. What can cause this? System AMD64, Debian 2.6.11, compiling with version "0.9.11.8" Regards Friedrich |
From: Nikodemus S. <nik...@ra...> - 2006-04-08 10:17:21
|
Friedrich Dominicus <fr...@q-...> writes: > But this days I got a message: > arily disabled: proceed with caution > unhandled SB-KERNEL::CONTROL-STACK-EXHAUSTED in thread #<SB-THREAD:THREAD "initial thread" {1002287C91}>: > Control stack exhausted (no more space for function call frames). This is probably due to heavily nested or infinitely recursive function calls, or a tail call that SBCL cannot or has not optimized away. Surely this is not the entirety of the message? Where's the rest? What does your customize-target-features.lisp-expr look like? Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |