Daniel Novotny writes:
I am now solving a bug in RHEL4
(
https://bugzilla.redhat.com/show_bug.cgi?id=249668), but I got to
very strange behavior while debugging it
in the "bytecode.c" file xemacs abort()s in the function
execute_rare_opcode(), because it somehow got another opcode than
the ones listed in the switch:
There is a known type of bug in the bytecode interpreter where
bytecode interpreter's stack gets corrupted. This kind of bug is due
to a failure of one of the bytecode internal functions to save enough
stack space. That bug has this kind of signature.
inside the function execute_rare_opcode() the "opcode"
parameter
seems to be 0, however when I go one stack frame up,
What function is in the parent frame?
it shows that the REGISTER variable "opcode", which should
get
passed to the function, is 5590 and not 0,
This is already bad. When opcode gets passed to execute_rare_opcode,
it's supposed to be an enum; 5590 is out of range (> 255) and neither
0 nor 5590 % 256 are valid members of the enum.
so the program should get to the "if"
-push constant- and not "else" -execute_rare_opcode()- part
The comment in the "bytecode.c" file is, that it is
heavily
optimized, so maybe this is an compiler/optimalization issue, but
it happens even with -O0, even tried the "-fno-caller-saves" switch
"PROBLEM" file mentions.
The optimizations mentioned have nothing to do with the compiler.
Rather they refer to careful choice of opcodes etc to ensure that the
bytecode interpreter has a small footprint and is likely to remain in
the CPU's cache.
Maybe there is some other compiler switch wrong?
Not likely.
Or could there be race condition in the code perhaps?
Not likely, since it's single-threaded.
I see the file is not touched for several years in the project, so
it probably is correct :)
Maybe. Since you seem to be able to reproduce the crash, it would be
helpful if you can try to find out where that 5590 is coming from. If
you really get 5590 every time, maybe you can put a GDB watch on that
variable.
If it's a compiler issue, it may have to do with misuse of register
variables. You could try compiling without the register declaration.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta