----- "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
Daniel Novotny writes:
> I am now solving a bug in RHEL4
), 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?
execute_optimized_program () - it all was in my bugreport ZIP file,
I sent with the previous mail (the text file xemacs-vi-mode-bugreport.txt
shows my GDB session, with me going up and down the stack and
> 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.
If it's a compiler issue, it may have to do with misuse of register
variables. You could try compiling without the register declaration.
Interesting, when I comment out the register declaration specifier
on all the variables, I am getting another error elsewhere in the code:
100% reproducible the same thing again, a segfault
I attach the "where" backtrace in this mail
XEmacs-Beta mailing list