gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] 2.6.2.....


From: Camm Maguire
Subject: Re: [Gcl-devel] 2.6.2.....
Date: 14 Apr 2004 10:47:46 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

[ Guys -- most important stuff is at the bottom.]

"Mike Thomas" <address@hidden> writes:

> Hi Camm.
> 
> | A few thoughts:
> 
> Thanks for these.
> 
> Before launching into this I followed up on last night's print output by
> tracing a few of the parent functions to the problem point but that just
> made the problem go away - frustration at every turn.
> 
> ;(trace new-append-directories)
> ;(trace append-directories)
> ;(trace compute-system-path)
> 
> 

Where are these functions?

> | 1) It looks like the problem starts here, is there a carriage return
> |    at the front of the filename?
> 
> Not in the system definition file at least.  It's all random anyway and the
> problem has been extant for a long time now.
> 

No, clearly not in the sys def file.  I was thinking of setting a
breakpoint in gdb at the line reporting this load and conditionalizing
the breakpoint on the first char in ...->st.st_self being \r or \n.

> 
> | 2) Can you please run with (setq si::*notify-gbc* t)?  The erratic
> |    nature of the problem indicates that it is possible that some windows
> |    specific code is holding on to a pointer to a relocatable piece of
> |    memory across a GBC call.  I had suspected fix_filename, but it
> |    does not appear that there are any allocs in there.
> 
> What about "o/pathname.d"?
> 

Can't see anything Windows specific here.

> I scanned the file last night looking for stuff left on the value stack etc
> but was pretty tired and could easily have missed something.
> 
> Regarding (setq si::*notify-gbc* t), the previous GC occurs just after
> kclmac.o is compiled:
> 
> ....
> Finished compiling binary-gcl/kclmac.o.
> [GC for 48 STRING pages..(T=1).GC finished]
> ....
> 
> which is 16 successfully compiled and loaded files earlier than the
> particular point of failure recorded below:
> 
> ...........
> ;      - Loading binary file "binary-gcl/displm.o"
> Loading binary-gcl/displm.o
> start address -T 1021f000 Finished loading binary-gcl/displm.o
> 
> ;    - Compiling module "rat-macros"
> ;      - Compiling source file
> ;        "c:/lang/source/gcl/maxima-2004-02-19/src/ratmac.lisp"
> Compiling c:/lang/source/gcl/maxima-2004-02-19/src/ratmac.lisp.
> Error in LET [or a callee]: Cannot create the file
> binary-gcl/c:/lang/source/gcl/maxima-2004-02-19/src/k/ratmac.data.
> 
> Fast links are on: do (use-fast-links nil) for debugging
> Broken at CONDITIONS::CLCS-OPEN.  Type :H for Help.
>  1 (Continue) Retry opening file
> #p"binary-gcl/c:/lang/source/gcl/maxima-2004-02-19/src/k/ratmac.data".
>  2 (Abort) Return to top level.
> dbl:>>
> 

OK, my suggestion would be to break at this error trap, find the
address of the bad string (i.e. ...->st.st_self), 'watch *(char
*)<address>)' and rerun.  You'd need to put the maxima lisp compile
commands in a separate file and load it.

Vadim, can you also help with this step??

> 
> 
> |
> | 3) Is the problem always triggered on a source .lsp file when
> |    compiling, or does it ever first appear when loading a .o?
> 
> I can't remember a first appearance while loading an object file.  That may
> be wrong although I am fairly certain that last night and today the problem
> appeared before that point.
> 
> 
> 
> |
> | 4) Is the gcc 3.3.3 maxima compile issue gone?  If so, my
> |    understanding is that this is the last of the three original
> |    problems, 2 of which were ansi test failures in head and stable,
> |    and one of which was maxima compile failure with gcc 3.3.3.
> 
> Woops; I forgot that little landmine.  Frustratingly, it is still there.
> 
> I'll specify gcc 3.3.1 for the release.

This one is important, IMHO.  Could someone please give me the details
of the failure with 3.3.3?  All I know now is that 'it doesn't work'.
Would really appreciate a gdb session showing the failure.  Vadim, if
you could help here too, it would be most appreciated.


> 
> Cheers
> 
> Mike Thomas.
> 
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]