Re: [issue] XEmacs often crashes when "VI emulation" is activated. (RHEL4)
- First Post
- Replies
- Stats
-
Go to
- ----- 2025 -----
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1998 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
----- "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
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?
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
inspecting variables)
> 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
best regards,
Daniel
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Attachments:
- xemacs-vi-mode-wo-register.txt (text/plain — 1.7 KB)
Thursday, 25 September
Thu, 25 Sep
11:01 a.m.
New subject: [issue] XEmacs often crashes when "VI emulation" is activated. (RHEL4)
Daniel Novotny writes:
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
inspecting variables)
Sorry, but my mailreader doesn't handle zip files automatically. You
could wait for me to save and open the zip file manually, but that
will take a while, maybe forever if your mail ends up far enough down
the stack.
Or you can take what hints I can give in 60 seconds, and maybe
somebody else will pick up the ball during the conversation. That's
just the reality of my life for the next month.
> 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
That backtrace is partial, and just shows XEmacs trying to print out
an error it encountered inside the error handler. This is hard to
avoid since XEmacs is known to be in a bad state when it hits an
internal error (AKA "impossible" condition).
We need to see the whole backtrace.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6249
days inactive
6249
days old
1 comments
2 participants
tags (0)
participants (2)
-
Daniel Novotny -
Stephen J. Turnbull