Thanks for the reply. Sorry it's taken so long to respond. I've been
tearing my hair out over this trying to apply your advice. I've got
it narrowed down to a local issue, but I just can't figure out why
it's happening.
>>>> On Mon, 16 Sep 2002 16:49:38 +0900, "Stephen J.
Turnbull"
>>>> <stephen(a)xemacs.org> said:
You've got bad bytecode from somewhere:
#7 0x8091d67 in execute_rare_opcode (stack_ptr=0xbfffd3e4,
program_ptr=0x871a5c6 "*\bìñ(\b\\F(\bäÆ]\b!", opcode=185)
at bytecode.c:1479
#8 0x8090f5b in execute_optimized_program (
program=0x871a5b8 "d\220u\b´Dn\bd¼*\bô¹*\bìñ(\b\\F(\bäÆ]\b!",
stack_depth=4, constants_data=0x86ab230) at bytecode.c:658
The `¹' (compare frame #7 with frame #8) is not a legal bytecode.
One
possibility is it's supposed to be immediate data, but somehow XEmacs
is not advancing program_ptr correctly.
It must be data. These .elcs are the same ones supplied in the XEmacs
package and work fine with the Sun and cygwin machines, and now even
with some of the linux boxes.
If that doesn't help, then the fact that the same code works on
other
platforms, combined with the Linux vendor being "Red Card", indicates
a GCC optimization which screws up the bytecode interpreter. What
version of GCC (gcc --version) are you using?
2.95.3. That's the version we have in our AFS based repository.
Just in case I also tried the 2.96 that comes with Red Hat. We've had
bad experiences with that one before though so we normally avoid it.
In this case, it made no difference.
We may need to disable some optimization.
Dave> Compiler: gcc -g -O3 -Wall -Wno-switch -Winline
Dave> -Wmissing-prototypes -Wsign-compare -Wshadow
Maybe CFLAGS=-no-strict-aliasing would help.
2.95.3 doesn't understand that one but...
Two more tries: (a) CFLAGS=-O2 in the environment and (b)
--use-union-type to ./configure.
a combination of these two did the trick (actually, I just got rid of
-O completely), at least for the most part. It works fine for linux
boxes that use our "released" tree of software, but I get the dump in
exactly the same spot on machines running our "beta" tree. Time to
get boned up on strace again, I guess.
I think you can safely close this on your end.
Thanks again for the help,
--
Dave Goldberg
Associate Department Head, Research Computing Facility
The Mitre Corporation \ MS K331 \ 202 Burlington Rd. \ Bedford, MA 01730
dsg(a)mitre.org \ 781-271-3887