gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] RE: [Axiom-developer] system::getenv does not return MSYS en


From: Page, Bill
Subject: [Gcl-devel] RE: [Axiom-developer] system::getenv does not return MSYS environ ment variables
Date: Tue, 7 Dec 2004 23:09:41 -0500

Tim,

On Tuesday, December 07, 2004 7:17 PM you wrote:
> 
> It could depend on how you are launching the program.
> If you launch main.c using an icon and launch your
> test program by an MSYS shell command they could be
> running in different environments.

Yes, I understand. But I am runing AXIOMsys only from
within the MSYS shell the way we must during the build.

> 
> Try running AXIOMsys from a shell command and then ask
> for the value of the environment variables using the
> )lisp axiom command and the )sys axiom command and see
> if they differ.

I just spent the last 3 hours worrying that all of this
was not reproducible and that I must have just been
going crazy last night. Now I know that it is only hard
to reproduce. My first attempt to do the equivalent of
what you suggested above actually worked (contrary to
my previous email and my emails of last night). The
short story is that I can now reproduce this problem by
attempting to build the database files several times
while trying variations ( ':' '\' and '/' ) of the AXIOM
variable in Windows.

The long story follows:

I could not do exactly what you suggest above because
I am not working with a complete build of AXIOM. I am
working with Mike's original /cvs/head/axiom build. I am
specifically looking at the database build problem. Until
Mike's work last night we did not have a 2.6.5 version
that built all the way up to the database problem. 
I have not yet tried to install all of Mike's changes
to the 2.6.5 build but I will likely shift this work
over to 2.6.5 once I can get it that far.

Anyway, my procedure is to run Mike's /cvs/head version up
to the point where it fails in make-databases. I detailed
what I was doing in several emails last night. If you wade
through that (something I just finished doing) you will
see that I isolated the "syntax error" messages as occurring
during the execution of the make-databases function.

AXIONsys is actually built but the database files are still
missing from mnt. They can actually be found in int but
they have not been renamed.

It is possible to start AXIOMsys anyway but it bails out
into the BOOT> prompt which where I can start executing
lisp commands. That is where is am doing my tests. Last
night tried to see what was going on in make-databases
and experimented with several file access commands like
probe-file and namestring. At least one of the failure
messages probably occurs when namestring is called to
convert a NIL. That's when I tried (|getEnv| "AXIOM") which
is used in one place to construct part of a file name. It
just calls system::getenv in turn.

I discovered that I could not longer get the AXIOM
environment variable using |getEnv| nor system::getenv. But
that outside of AXIOMsys, echo $AXIOM as fine. And my test
program (see previous message) also was fine. Every time
I tried to use system:getenv for the AXIOM variable it
failed. But the PATH variable was retrieved just fine.

That is all I knew until Camm asked about my report
tonight. I wrote up exact the test that I had done the
night before. But when you asked me to do a few more
tests, I found that the failure no longer occurred. Of
course in the mean time the machine on which I had been
working had been powered down and rebooted...

So what exactly did I do to reproduce the problem again?
I just did a 'make clean' and ran the build up to the
make-databases failure again. Then I started reading my
notes from last night (something I was reminded to do from
Mike's recent comments :) and followed the same steps of
setting the AXIOM variable in Windows before starting MSYS.
Re-running the build caused the "syntax errors" to change
to "rm not found" just like I reported last night. As Mike
noted, system commands like "rm" and "sort" occur in some
of the boot code that is used during the make-databases
function.

But here is where it gets weird. Doing the above also subtly
screws up the Windows environment. Now I was suddenly unable
to retrieve the value of the PATH variable this time
using system:getenv and several attempts and stopping the
MSYS shell checking Windows and restarting MSYS only made
this worse. Other environment variables started disappearing.
Right now the system is about back in the state is was last
night. Even logging out and back into Windows doesn't cure
the problem. (I fully expect that a full reboot a would :)

So, what have a learned: One thing, I guess is that compiling
AXIOM under GCL can really subtly mess up the Windows memory
management!

I also looked at the GCL code for getenv in main.c and I
noticed a scary section involving a call to free on the
pointer returned by the system getenv call. I imagine that
would really mess up Windows memory - but as far as I can
tell that option is not used during the Windows build.
Right?

I agree with Mike that we should focus on removing the
non-portable code from bootsys (and maybe elsewhere too?)
although I don't have any direct evidence that the problem
I am seeing with environment variables is necessarily
related those non-portable functions but they do appear at
about the same time. I rather suspect that it is some Windows
memory corruption that is the "first cause" of the failure
and these other commands are not really the problem. Perhaps
changing the Windows environment variables just allows the
process to go a little further. But they are probably easier
to fix than memory.

It is quire remarkable then that simply copying in new
database files and continuing actually allows the build
to complete. So far I have not seen any evidence of any
memory management problems in the running Axiom build
that I extracted from Mike's original cvs/head build, but
then I have not actually tried any commands that manipulate
files.

I apologize that this email once again has got so long.
Maybe I should go back to leaving this debugging stuff to
the experts like Camm and Mike! 

Regards,
Bill Page.




reply via email to

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