From xemacs-m  Mon Jun 30 14:54:12 1997
Received: from crystal.WonderWorks.COM (crystal.WonderWorks.com [192.203.206.1])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id OAA28433
	for <xemacs-beta@xemacs.org>; Mon, 30 Jun 1997 14:54:10 -0500 (CDT)
Received: by crystal.WonderWorks.COM 
	id QQcwff22830; Mon, 30 Jun 1997 15:54:11 -0400 (EDT)
Date: Mon, 30 Jun 1997 15:54:11 -0400 (EDT)
Message-Id: <QQcwff22830.199706301954@crystal.WonderWorks.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Kyle Jones <kyle_jones@wonderworks.com>
To: xemacs-beta@xemacs.org
Subject: Output of test-atoms
In-Reply-To: <u8soy06roz.fsf@arthur.rhein-neckar.de>
References: <u8soy06roz.fsf@arthur.rhein-neckar.de>
X-Mailer: VM 6.33 under 20.3 "Athens" XEmacs  Lucid (beta10)
X-Face: /cA45WHG7jWq>(O3&Z57Y<"WsX5ddc,4c#w0F*zrV#=M
        0@~@,s;b,aMtR5Sqs"+nU.z^CSFQ9t`z2>W,S,]:[+2^
        Nbf6v4g>!&,7R4Ot4Wg{&tm=WX7P["9%a)_da48-^tGy
        ,qz]Z,Zz\{E.,]'EO+F)@$KtF&V

Andreas Jaeger writes:
 > 
 > I've tried for the first time for ages to compile with mule and got
 > the following message from test-atoms:
 > Bad plist in browse-url-iximosaic, 0
 > 
 > My setup: Linux 2.0.31-pre2, i486, glibc 2.1 snapshot, XFree3.3. I've
 > grabbed only xemacs-20.3-b10.tar.gz and build otherwise successfully
 > so far (xemacs is still bytecompiling the lisp file).

Is there anyone who has seen the 0 plist problem who is not
running Linux?

This is an odd memory corruption problem.  Per Abrahamsen
reported it as early as 20 March this year.  Since then
LRECORD_SYMBOL has been undefined which made the Lisp_Symbol
struct four bytes smaller (was 24 bytes, now 20 bytes).  And
we still see the problem.  So the corruption seems to have
moved along with the struct slot.  Another interesting fact
is that the plist slot of teh struct is at the end of the
struct in memory.  XEmacs allocates memory for symbols in
roughly 2K blocks, which hold around 100 symbols.  It would
be interesting to know if the symbol whose plist is getting
zeroed is at the end of one of these memory blocks.

I can't dupolicate the problem so all I can do is speculate.

