Re: Core Dump in 21.1.3
Vin Shelton <acs(a)xemacs.org> writes in xemacs-beta(a)xemacs.org:
I'm consistently getting a core dump in 21.1.3 when trying to
open a
particular compressed tarfile:
ftp://prep.ai.mit.edu/gnu/userv/userv-0.64.1.tar.gz. I've included
the installation info and a backtrace. I've been unable to
reproduce this in a -vanilla xemacs.
This is a bad crash. What kind of stuff do you do in .emacs? Also,
what command are you using to open the file. If I visit the file with
`C-x C-f /prep.ai.mit.edu:/userv/userv-0.64.1.tar.gz' I get `File mode
specification error: (error "truncated tar file")', but no crash.
I will try a no-Mule XEmacs later. Any information you can provide
towards replicating the crash will be helpful.
Also, do you get the same crash in 21.2?
The compiler used to build this was:
gcc version gcc-2.95 19990608 (prerelease).
#3 0x1167fc in search_buffer (buf=0x7f4600, string=-559700851,
bufpos=-291240955, buflim=1031, n=1,
RE=-291239917, trt=0x28b4a4 "", inverse_trt=0x28b5ac "",
posix=0)
at /u/shelton/new/src/xemacs-21.1-19990616/src/search.c:1367
This is dubious code at best. Casting pointers to signed integers is
probably not a good thing to do. Using tiny fixed-sized buffers
without doing any range checking is Just Plain Stupid(TM). What is
the value of cursor and *cursor when it crashes?
{
/* Use signed comparison if appropriate
to make cursor+infinity sure to be > p_limit.
Assuming that the buffer lies in a range of addresses
that are all "positive" (as ints) or all
"negative",
either kind of comparison will work as long
as we don't step by infinity. So pick the kind
that works when we do step by infinity. */
if ((EMACS_INT) (p_limit + infinity) >
(EMACS_INT) p_limit)
while ((EMACS_INT) cursor <=
1367: (EMACS_INT) p_limit)
cursor += BM_tab[*cursor];
else
while ((EMACS_UINT) cursor <=
(EMACS_UINT) p_limit)
cursor += BM_tab[*cursor];
}
--
泣き面に蜂