From: Cyrus H. <ch...@bo...> - 2011-01-20 06:15:57
|
On the one hand, it's a welcome change to see some new commits to the tree. On the other hand, I think there might be some problems with the recent changes. First I built on x86-64 darwin and dropped into LDB: * //testing for consistency of first and second GENESIS passes //header files match between first and second GENESIS -- good real 5m47.965s user 3m59.269s sys 0m51.389s //entering make-target-2.sh //doing warm init - compilation phase This is SBCL 1.0.45.7, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. in core: 0x4000000 - in runtime: 0x20000000 fatal error encountered in SBCL pid 73170(tid 140735089040544): core/runtime address mismatch: READ_ONLY_SPACE_START Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Second, on linux x86-64, I get: ; SYS:SRC;CODE;RUN-PROGRAM.FASL.NEWEST written ; compilation finished in 0:00:00.463 debugger invoked on a UNDEFINED-ALIEN-ERROR in thread #<THREAD "initial thread" RUNNING {1002B60071}>: Undefined alien: "waitpid" Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (FOREIGN-SYMBOL-ADDRESS "waitpid" #<unused argument>) 0] I'll try and track down the offending commits, assuming these aren't transient problems on my end, but I figured I would raise the alarm bells first. Cyrus |
From: James Y K. <fo...@fu...> - 2011-01-20 11:01:42
|
On Jan 20, 2011, at 12:45 AM, Cyrus Harmon wrote: > in core: 0x4000000 - in runtime: 0x20000000 > fatal error encountered in SBCL pid 73170(tid 140735089040544): > core/runtime address mismatch: READ_ONLY_SPACE_START Being a multiple of 8, that sounds like the space's start address on darwin somehow depended on *backend-page-bytes* in the runtime (which just got multiplied by 8), while it didn't on linux. James |
From: Attila L. <att...@gm...> - 2011-01-20 13:01:11
|
> * //testing for consistency of first and second GENESIS passes > //header files match between first and second GENESIS -- good fyi, i've heard a report like that when someone tried to build the dwim.hu branch of sbcl, which does not have the past few commits yet. so, i suspect that it's an architecture related issue, because that branch builds fine on my ubuntu and debian x86_64. another piece of memory that might be related: some time ago i used to see git diffs showing up in some files after building, which i had to git reset regularly. haven't seen it happening recently. hth, -- attila Notice your eroding (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06 |
From: Martin C. <cra...@co...> - 2011-01-20 13:26:12
|
James Y Knight wrote on Thu, Jan 20, 2011 at 05:21:07AM -0500: > On Jan 20, 2011, at 12:45 AM, Cyrus Harmon wrote: > > in core: 0x4000000 - in runtime: 0x20000000 > > fatal error encountered in SBCL pid 73170(tid 140735089040544): > > core/runtime address mismatch: READ_ONLY_SPACE_START > > Being a multiple of 8, that sounds like the space's start address on darwin somehow depended on *backend-page-bytes* in the runtime (which just got multiplied by 8), while it didn't on linux. Looks more like a build dependency problem to me. The code doesn't seem to do any arithmetic on the start. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ |
From: Cyrus H. <ch...@bo...> - 2011-01-20 16:13:32
|
On Jan 19, 2011, at 9:45 PM, Cyrus Harmon wrote: > Second, on linux x86-64, I get: > > ; SYS:SRC;CODE;RUN-PROGRAM.FASL.NEWEST written > ; compilation finished in 0:00:00.463 > > debugger invoked on a UNDEFINED-ALIEN-ERROR in thread #<THREAD > "initial thread" RUNNING > {1002B60071}>: > Undefined alien: "waitpid" > > Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > restarts (invokable by number or by possibly-abbreviated name): > 0: [ABORT] Exit debugger, returning to top level. > > (FOREIGN-SYMBOL-ADDRESS "waitpid" #<unused argument>) > 0] > There seem to be a couple of problems, brought about by the fact that I upgraded this box to Ubuntu's Natty Narwhal release (linux kernel 2.6.37-12). The problems are: 1. waitpid -- My understanding of how unix system calls are provided to C library code is rather sketchy, but something seems to have changed here. If I add waitpid to src/runtime/undefineds.h and tools-for-build/ldso-stubs.lisp then I get past this problem -- and on to the next: 2. -ldl -- the os-provides-dlopen-test.c fails as for this to work it apparently needs to be built with -ldl. What's the best way to get grovel-features.sh to play nice with natty narwhal and not break compatibility with older linuxes for this? thanks, Cyrus |
From: Josh E. <jo...@el...> - 2011-01-20 16:18:13
|
On Wed, Jan 19, 2011 at 09:45:04PM -0800, Cyrus Harmon wrote: > On the one hand, it's a welcome change to see some new commits to the tree. On the other hand, I think there might be some problems with the recent changes. First I built on x86-64 darwin and dropped into LDB: > > > * //testing for consistency of first and second GENESIS passes > //header files match between first and second GENESIS -- good > > real 5m47.965s > user 3m59.269s > sys 0m51.389s > //entering make-target-2.sh > //doing warm init - compilation phase > This is SBCL 1.0.45.7, an implementation of ANSI Common Lisp. > More information about SBCL is available at <http://www.sbcl.org/>. > > SBCL is free software, provided as is, with absolutely no warranty. > It is mostly in the public domain; some portions are provided under > BSD-style licenses. See the CREDITS and COPYING files in the > distribution for more information. > in core: 0x4000000 - in runtime: 0x20000000 > fatal error encountered in SBCL pid 73170(tid 140735089040544): > core/runtime address mismatch: READ_ONLY_SPACE_START > > > Welcome to LDB, a low-level debugger for the Lisp runtime environment. > ldb> > I see this on OpenBSD/amd64 as well: [building initial core file in "output/cold-sbcl.core": writing 32768 bytes [1 page] from #<SB!FASL::GSPACE :READ-ONLY> writing 32768 bytes [1 page] from #<SB!FASL::GSPACE :STATIC> writing 44826624 bytes [1368 pages] from #<SB!FASL::GSPACE :DYNAMIC> /(DESCRIPTOR-BITS INITIAL-FUN)=#X100293CFF9 done] * //testing for consistency of first and second GENESIS passes //header files match between first and second GENESIS -- good 5m52.14s real 5m35.15s user 0m15.90s system //entering make-target-2.sh //doing warm init - compilation phase This is SBCL 1.0.45.7, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. in core: 0x4000000 - in runtime: 0x20000000 fatal error encountered in SBCL pid 30797: core/runtime address mismatch: READ_ONLY_SPACE_START |
From: Cyrus H. <ch...@bo...> - 2011-01-20 16:22:45
|
Hmm... not sure I'd call it a build dependency, as backing out the *backend-page-bytes* change fixes things, but I'll keep digging. I assume others are seeing the same problem on x86-64 darwin? On Jan 20, 2011, at 5:25 AM, Martin Cracauer wrote: > James Y Knight wrote on Thu, Jan 20, 2011 at 05:21:07AM -0500: >> On Jan 20, 2011, at 12:45 AM, Cyrus Harmon wrote: >>> in core: 0x4000000 - in runtime: 0x20000000 >>> fatal error encountered in SBCL pid 73170(tid 140735089040544): >>> core/runtime address mismatch: READ_ONLY_SPACE_START >> >> Being a multiple of 8, that sounds like the space's start address on darwin somehow depended on *backend-page-bytes* in the runtime (which just got multiplied by 8), while it didn't on linux. > > Looks more like a build dependency problem to me. > > The code doesn't seem to do any arithmetic on the start. > > Martin > -- > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Martin C. <cra...@co...> - 2011-01-20 16:33:39
|
Cyrus Harmon wrote on Thu, Jan 20, 2011 at 08:22:37AM -0800: > > Hmm... not sure I'd call it a build dependency, as backing out the *backend-page-bytes* change fixes things, but I'll keep digging. I assume others are seeing the same problem on x86-64 darwin? The address of read-only-space-start is declared only once in source code. Can you try rebuilding from a fresh tree to rule out stale files? Martin > On Jan 20, 2011, at 5:25 AM, Martin Cracauer wrote: > > > James Y Knight wrote on Thu, Jan 20, 2011 at 05:21:07AM -0500: > >> On Jan 20, 2011, at 12:45 AM, Cyrus Harmon wrote: > >>> in core: 0x4000000 - in runtime: 0x20000000 > >>> fatal error encountered in SBCL pid 73170(tid 140735089040544): > >>> core/runtime address mismatch: READ_ONLY_SPACE_START > >> > >> Being a multiple of 8, that sounds like the space's start address on darwin somehow depended on *backend-page-bytes* in the runtime (which just got multiplied by 8), while it didn't on linux. > > > > Looks more like a build dependency problem to me. > > > > The code doesn't seem to do any arithmetic on the start. > > > > Martin > > -- > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ > > > > ------------------------------------------------------------------------------ > > Protect Your Site and Customers from Malware Attacks > > Learn about various malware tactics and how to avoid them. Understand > > malware threats, the impact they can have on your business, and how you > > can protect your company and customers by using code signing. > > http://p.sf.net/sfu/oracle-sfdevnl > > _______________________________________________ > > Sbcl-devel mailing list > > Sbc...@li... > > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ |
From: Cyrus H. <ch...@bo...> - 2011-01-20 16:30:22
|
this and similar changes for the other platforms (osf1, openbsd) should (hopefully) fix things: diff --git a/src/runtime/bsd-os.c b/src/runtime/bsd-os.c index 1b1db92..f8682e2 100644 --- a/src/runtime/bsd-os.c +++ b/src/runtime/bsd-os.c @@ -82,7 +82,7 @@ static void openbsd_init(); void os_init(char *argv[], char *envp[]) { - os_vm_page_size = getpagesize(); + os_vm_page_size = BACKEND_PAGE_BYTES; #ifdef __NetBSD__ netbsd_init(); On Jan 20, 2011, at 2:21 AM, James Y Knight wrote: > On Jan 20, 2011, at 12:45 AM, Cyrus Harmon wrote: >> in core: 0x4000000 - in runtime: 0x20000000 >> fatal error encountered in SBCL pid 73170(tid 140735089040544): >> core/runtime address mismatch: READ_ONLY_SPACE_START > > Being a multiple of 8, that sounds like the space's start address on darwin somehow depended on *backend-page-bytes* in the runtime (which just got multiplied by 8), while it didn't on linux. > > James > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Jim W. <jw...@dr...> - 2011-01-20 17:39:21
|
Cyrus Harmon <ch...@bo...> writes: > this and similar changes for the other platforms (osf1, openbsd) should (hopefully) fix things: > > > diff --git a/src/runtime/bsd-os.c b/src/runtime/bsd-os.c > index 1b1db92..f8682e2 100644 > --- a/src/runtime/bsd-os.c > +++ b/src/runtime/bsd-os.c > @@ -82,7 +82,7 @@ static void openbsd_init(); > void > os_init(char *argv[], char *envp[]) > { > - os_vm_page_size = getpagesize(); > + os_vm_page_size = BACKEND_PAGE_BYTES; > > #ifdef __NetBSD__ > netbsd_init(); Note that the Solaris port had os_vm_page_size = os_real_page_size = sysconf(_SC_PAGESIZE); (the POSIX-ish equivalent of getpagesize() ). Switching this to use BACKEND_PAGE_BYTES works, but before I submit a patch, I was wondering if this is the way ports should work moving forward, or if this is a sign of something else which is going to be reverted? Thanks, -- Jim Wise jw...@dr... |
From: Jim W. <jw...@dr...> - 2011-01-20 17:39:19
|
Jim Wise <jw...@dr...> writes: > Note that the Solaris port had > > os_vm_page_size = os_real_page_size = sysconf(_SC_PAGESIZE); > > (the POSIX-ish equivalent of getpagesize() ). Switching this to use > BACKEND_PAGE_BYTES works, but before I submit a patch, I was wondering > if this is the way ports should work moving forward, or if this is a > sign of something else which is going to be reverted? > > Thanks, Actually, I spoke too soon -- this gets through the build, but the resulting SBCL executable is not functional. I'll play with this more, but any insight into whether this is going to change at a machine-independent level is welcome. -- Jim Wise jw...@dr... |