www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/07/07/09:20:20

Date: Mon, 7 Jul 1997 16:19:44 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Esa DOT Peuha AT Helsinki DOT FI
cc: djgpp AT delorie DOT com
Subject: Re: Emacs 22 env vars bug
In-Reply-To: <Pine.SOL.3.96.970707132450.27739A-100000@kruuna.Helsinki.FI>
Message-ID: <Pine.SUN.3.91.970707161226.10910D-100000@is>
MIME-Version: 1.0

On Mon, 7 Jul 1997, Esa A E Peuha wrote:

> Playing around with environment variables does indeed show that emacs.exe
> from em1934b.zip crashes when there are exactly 22 entries in the DOS
> environment list (as showed by set command without arguments). Number of
> variables set in djgpp.env doesn't affect this. However, if there is at
> least one entry that is at least 64 characters long, emacs _doesn't_
> crash. Does this help anyone to figure out anything about this bug? (I
> doubt it.)

It all points to `malloc' and friends (not DJGPP's `malloc', since Emacs 
has its own relocatable allocator which replaces the one from libc), or 
to `putenv', or to their interaction.  My Emacs is unstripped, and the 
crashes indeed point to functions called by `malloc'.  Having large env 
var means that a larger chunk of memory is requested from the system, 
which can affect the bug.

> Next, I tried to rebuild emacs to get a symifiable traceback, but
> surprisingly the executable produced by the makefiles in em1934s1.zip
> doesn't manifest this bug (it also complaining about missing directory
> `c:/emacs/'). How do I get emacs.exe exactly like the one distributed
> except unstripped?

Please tell what were the commands you used to configure and build Emacs 
from sources.  The only reason for any difference might be that the 
distributed binary was built with slightly patched libc, but it certainly 
shouldn't complain about no c:/emacs missing.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019