🚀 go-pugleaf

In GNU Emacs 19.25.94.1 (sparc-sun-sunos4shr) of Mon Aug 15 1994 on uluru

Emacs 19.25.94 was configured from unmodified sources with 
--infodir=`pwd`/info --with-gcc --with-x11 --verbose sparc-sun-sunos4shr:

  Where should the build process find the source code?    /usr/local/lib/emacs/19.25.94
  What operating system and machine description files should Emacs use?
        `s/sunos4shr.h' and `m/sparc.h'
  What compiler should emacs be built with?               gcc -g -O 
  Should Emacs use the GNU version of malloc?             yes
  Should Emacs use the relocating allocator for buffers?  yes
  What window system should Emacs use?                    x11
  What toolkit should Emacs use?                          none
  Where do we find X Windows header files?                /usr/X11R6/include
  Where do we find X Windows libraries?                   /usr/X11R6/lib

The gcc version used was 2.6.0, the X11R6 patchlevel was fix-03, and
the SunOS 4.1.2 libc shared library had both patch 100532-03 applied
and the /usr/lib/libresolv.a routines added in.

Emacs was running on my X Window display and a big compilation was
going on (generating tons of output) while I was browsing the GNU C
library on-line info manual (libc.info) with info.  The info files
were compressed with gzip 1.2.4 and I was performing a regexp search
with the s key when Emacs crashed with a segmentation fault.  I should
note that I also had efs 1.9 loaded as well, which is probably
significant since the crash occured in the file handler lookup code.

The file /tmp/emacsa07527 was left after the crash.  Its contents were
identical to the gzipped file /usr/local/info/libc.info-13.gz, that
is, it still contained binary data that was going to be gunzipped.

I have observed similar crashes in 19.25, 19.25.92, and 19.25.94
before although I have not been able to reproduce them on will.  The
triggering action is almost invariably a shell command sometime after
efs's dired has been loaded.  I autoload efs itself, so it hasn't
always been loaded when the crash occurred although I DID see "loading
efs" in the minibuffer once just before a crash even though there was
no reason Emacs should have thought it was handling a remote filename.

The gdb post-mortem is not very informative, but I enclose it anyway
in case it helps narrow down the problem.
--
John Interrante <interran@uluru.stanford.edu>

Current directory is /usr/local/bin/
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.13 (sparc-sun-sunos4.1.2), 
Copyright 1994 Free Software Foundation, Inc...
Core was generated by `emacs'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/X11R6/lib/libX11.so.4.20...done.
Reading symbols from /usr/lib/libc.so.1.7.1...done.
Reading symbols from /usr/lib/libdl.so.1.0...done.
#0  0xf76bec98 in kill ()
(gdb) bt
#0  0xf76bec98 in kill ()
#1  0x2d9f0 in fatal_error_signal (sig=11) at emacs.c:168
#2  <signal handler called>
#3  0x5ff94 in re_search_2 (bufp=0x1014e0, string1=0x0, size1=0, 
    string2=0x295194 "/tmp/emacsa07527", size2=2013260429, startpos=305927, 
    range=2013260429, regs=0x0, stop=2013260429) at regex.c:3165
#4  0x5fe10 in re_search (bufp=0x1014e0, string=0x295194 "/tmp/emacsa07527", 
    size=2013260429, startpos=0, range=2013260429, regs=0x0) at regex.c:3069
#5  0x59140 in fast_string_match (regexp=52035556, string=53039500)
    at search.c:249
#6  0x4e6e0 in Ffind_file_name_handler (filename=53039500, operation=85541244)
    at fileio.c:247
#7  0x4ec74 in Fexpand_file_name (name=53039500, defalt=52972928)
    at fileio.c:732
#8  0x73e4c in Ffuncall (nargs=134990492, args=0xf7ffe0c8) at eval.c:2059
#9  0x73898 in Fapply (nargs=2, args=0xf7ffe23c) at eval.c:1798
#10 0x73e4c in Ffuncall (nargs=135252952, args=0xf7ffe238) at eval.c:2059
#11 0x87ce4 in Fbyte_code (bytestr=52384040, vector=69124864, maxdepth=2)
    at bytecode.c:422
#12 0x74434 in funcall_lambda (fun=102647040, nargs=3, arg_vector=0xf7ffe444)
    at eval.c:2231
#13 0x73f6c in Ffuncall (nargs=102647040, args=0xf7ffe440) at eval.c:2106
#14 0x73a54 in call3 (fn=18798856, arg1=18047360, arg2=53039500, arg3=52972928)
    at eval.c:1895
#15 0x4ec9c in Fexpand_file_name (name=53039500, defalt=52972928)
    at fileio.c:734
#16 0x8d8a8 in Fcall_process (nargs=6, args=0xf7ffebb4) at callproc.c:209
#17 0x8dfc0 in Fcall_process_region (nargs=8, args=0xf7ffebac)
    at callproc.c:539
#18 0x73e4c in Ffuncall (nargs=135256460, args=0xf7ffeba8) at eval.c:2059
#19 0x87ce4 in Fbyte_code (bytestr=51178624, vector=67955988, maxdepth=8)
    at bytecode.c:422
#20 0x74434 in funcall_lambda (fun=101510192, nargs=4, arg_vector=0xf7ffedc4)
    at eval.c:2231
#21 0x73f6c in Ffuncall (nargs=101510192, args=0xf7ffedc0) at eval.c:2106
#22 0x87ce4 in Fbyte_code (bytestr=52920684, vector=69530368, maxdepth=4)
    at bytecode.c:422
#23 0x74434 in funcall_lambda (fun=102866048, nargs=1, arg_vector=0xf7ffefd4)
    at eval.c:2231
#24 0x73f6c in Ffuncall (nargs=102866048, args=0xf7ffefd0) at eval.c:2106
#25 0x87ce4 in Fbyte_code (bytestr=52924604, vector=69530240, maxdepth=1)
    at bytecode.c:422
#26 0x74434 in funcall_lambda (fun=102902848, nargs=1, arg_vector=0xf7fff1d4)
    at eval.c:2231
#27 0x73f6c in Ffuncall (nargs=102902848, args=0xf7fff1d0) at eval.c:2106
#28 0x87ce4 in Fbyte_code (bytestr=52926352, vector=68618752, maxdepth=1)
    at bytecode.c:422
#29 0x74434 in funcall_lambda (fun=102900000, nargs=1, arg_vector=0xf7fff534)
    at eval.c:2231
#30 0x73f6c in Ffuncall (nargs=102900000, args=0xf7fff530) at eval.c:2106
#31 0x706b0 in Fcall_interactively (function=19391532, record=17996804)
    at callint.c:586
#32 0x35a58 in Fcommand_execute (cmd=19391532, record=17996804)
    at keyboard.c:5261
#33 0x2ffdc in command_loop_1 () at keyboard.c:1230
#34 0x7235c in internal_condition_case (bfun=0x2f69c <command_loop_1>, 
    handlers=17997104, hfun=0x2f08c <cmd_error>) at eval.c:1096
#35 0x2f420 in command_loop_2 () at keyboard.c:879
#36 0x71eb4 in internal_catch (tag=17997084, func=0x2f3fc <command_loop_2>, 
    arg=17996804) at eval.c:886
#37 0x2f3cc in command_loop () at keyboard.c:859
#38 0x2eed4 in recursive_edit_1 () at keyboard.c:694
#39 0x2f004 in Frecursive_edit () at keyboard.c:736
#40 0x2e430 in main (argc=1, argv=0xf7fffcac, envp=0xf7fffcb4) at emacs.c:762
(gdb) up
#1  0x2d9f0 in fatal_error_signal (sig=11) at emacs.c:168
(gdb) i loc
No locals.
(gdb) p fatal_error_code
$1 = 11
(gdb) p fatal_error_in_progress
$2 = 1
(gdb) up 2
#3  0x5ff94 in re_search_2 (bufp=0x1014e0, string1=0x0, size1=0, 
    string2=0x295194 "/tmp/emacsa07527", size2=2013260429, startpos=305927, 
    range=2013260429, regs=0x0, stop=2013260429) at regex.c:3165
(gdb) i loc
d = 0x2ec000 <Address 0x2ec000 out of bounds>
lim = 0
irange = 2012954502
range = 2012904481
regs = (struct re_registers *) 0x0
stop = 2013260429
val = 50021
fastmap = 0x101568 ""
translate = 0x0
total_size = 2013260429
endpos = 50021
(gdb) p *bufp
$3 = {
  buffer = 0x26f000 "\b\001\001/\022\003", 
  allocated = 3200, 
  used = 26, 
  syntax = 0, 
  fastmap = 0x101568 "", 
  translate = 0x0, 
  re_nsub = 0, 
  can_be_null = 0, 
  regs_allocated = 0, 
  fastmap_accurate = 1, 
  no_sub = 0, 
  not_bol = 0, 
  not_eol = 0, 
  newline_anchor = 1
}
(gdb) up
#4  0x5fe10 in re_search (bufp=0x1014e0, string=0x295194 "/tmp/emacsa07527", 
    size=2013260429, startpos=0, range=2013260429, regs=0x0) at regex.c:3069
(gdb) up
#5  0x59140 in fast_string_match (regexp=52035556, string=53039500)
    at search.c:249
(gdb) up
#6  0x4e6e0 in Ffind_file_name_handler (filename=53039500, operation=85541244)
    at fileio.c:247
(gdb) i loc
string = 53039500
elt = 53039500
chain = 85541244
inhibited_handlers = 85292364
(gdb) p Qnil
$4 = 17996804
(gdb) p Vinhibit_file_name_handlers
$5 = 85292364
(gdb) p Vinhibit_file_name_operation
$6 = 18047360
(gdb) q

Debugger finished