From: Christophe R. <cs...@ca...> - 2003-04-26 17:52:11
|
Hi, all. I've got a way of triggering a runtime assertion that seems reproduceable: building with :sb-show and :sb-thread. I get, while building contrib in make-target-contrib.sh: /THROWing EOF-INPUT-CATCHER NIL CL-USER(1): ; loading system definition from #P"/var/tmp/sbcl/contrib/systems/sb-rt.asd" ; into #<PACKAGE "ASDF2445"> ; registering #<SYSTEM SB-RT {93AE5B9}> as SB-RT /THROWing EOF-INPUT-CATCHER /entering PROCLAIM, RAW-FORM=.. 0x090768cb /returning from PROCLAIM /entering PROCLAIM, RAW-FORM=.. 0x09076f9b /returning from PROCLAIM /entering PROCLAIM, RAW-FORM=.. 0x09077413 /returning from PROCLAIM /entering PROCLAIM, RAW-FORM=.. 0x09077aa3 /returning from PROCLAIM /entering PROCLAIM, RAW-FORM=.. 0x090780e3 /returning from PROCLAIM /entering PROCLAIM, RAW-FORM=.. 0x0907872b /returning from PROCLAIM /entering PROCLAIM, RAW-FORM=.. 0x09078db3 /returning from PROCLAIM /entering PROCLAIM, RAW-FORM=.. 0x09079443 /returning from PROCLAIM /entering PROCLAIM, RAW-FORM=.. 0x09079ac3 /returning from PROCLAIM /entering PROCLAIM, RAW-FORM=.. 0x09079f9b /returning from PROCLAIM /entering PROCLAIM, RAW-FORM=.. 0x0907ab4b /returning from PROCLAIM /entering PROCLAIM, RAW-FORM=.. 0x0907b833 /returning from PROCLAIM /entering PROCLAIM, RAW-FORM=.. 0x0907c3eb /returning from PROCLAIM /entering PROCLAIM, RAW-FORM=.. 0x0907d1e3 /returning from PROCLAIM /THROWing FASL-GROUP-END /THROWing EOF-INPUT-CATCHER /entering PROCLAIM, RAW-FORM=.. 0x09090f2b /returning from PROCLAIM /entering PROCLAIM, RAW-FORM=.. 0x0909576b /returning from PROCLAIM fatal error in thread 0x40550000, pid=11791 fs is 7, th->tls_cookie=0 (should be identical) fatal error encountered in SBCL pid 11791: If you see this message before 2003.05.01, mail details to sbcl-devel LDB monitor ldb> Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Christophe R. <cs...@ca...> - 2003-04-27 10:58:13
|
Christophe Rhodes <cs...@ca...> writes: > I've got a way of triggering a runtime assertion that seems > reproduceable: building with :sb-show and :sb-thread. I get, while > building contrib in make-target-contrib.sh: And I've just deduced why this must be. I haven't checked, but I'm approximately 99% certain that this is "user error". Further, it's user error that would have been caught if I'd waited for Bill to check in his "check for incompatible *FEATURES*" patch. To go into a little more detail: what's happened is that I didn't run ./clean.sh before building. This wouldn't ordinarily matter, except that this was the tree in which I separated out SB-RT into a contrib of its own. When I did that, I named the lisp file sb-rt.lisp (it's since been renamed), and consequently I have an sb-rt.fasl hanging around. This _still_ wouldn't have mattered, except that SB-ACLREPL's way of getting sb-rt in is by REQUIRE, not by :DEPENDS-ON, and REQUIRE first checks to see if it can load a single fasl of the same name. Thus, rather than loading the newly-compiled sb-rt/rt.fasl as asdf would have told it to, it loaded the old, not-compiled-with-threads sb-rt/sb-rt.fasl, leading to the assertion failure. When I get back home, I'll test this hypothesis, by deleting the old fasl file. But, as I say, I'm 99% sure that this is the problem (which is no problem at all any more :-) Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Daniel B. <da...@te...> - 2003-04-27 14:02:26
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christophe Rhodes <cs...@ca...> writes: > When I get back home, I'll test this hypothesis, by deleting the old > fasl file. But, as I say, I'm 99% sure that this is the problem > (which is no problem at all any more :-) That sounds entirely plausible. For the benefit of the permanent record (and anyone else not on #lisp), the debugging message Christophe got indicates that a thread attempted to allocate without being in a pseudo-atomic section. When we cornered the offending code in gdb and disassembled, we found that it was using the unithread conventions for pseudo-atomic, not the threaded convention. So if there's a stale fasl anywhere about, that would account for it nicely. =2D -dan =2D --=20 http://www.cliki.net/ - Link farm for free CL-on-Unix resources=20 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE+q+KvHDK5ZnWQiRMRAv49AJ9+LloBTrI953H7GhZ1ya/YxywulgCfUoZf A+VyXhI0iNUJcVTvyPtrnV0=3D =3DYhju =2D----END PGP SIGNATURE----- |