🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.emacs.bug
Article #87951

(none)

#87951
From: Chris Moore
Date: Wed, 17 Aug 1994 16:29
76 lines
5431 bytes
In GNU Emacs 19.25.94.1 (sparc-sun-sunos4.1.3, X toolkit) of Wed Aug
17 1994 on sun25, I just had gdb tell me:

Program received signal SIGSEGV, Segmentation fault.

Here's the stack trace (I had compiled with "-g -O", if that's
significant):

(gdb) where
#0  0x61504 in re_search_2 (bufp=0x36c3f0, string1=0x0, size1=0, string2=0x4ec814 "/tmp/emacsa00174", size2=4846196, 
    startpos=83640, range=4846196, regs=0x0, stop=4846196) at regex.c:3166
#1  0x6135c in re_search (bufp=0x36c3f0, string=0x4ec814 "/tmp/emacsa00174", size=4846196, startpos=0, range=4846196, 
    regs=0x0) at regex.c:3069
#2  0x5a710 in fast_string_match (regexp=54081932, string=55494668) at search.c:249
#3  0x4fca8 in Ffind_file_name_handler (filename=55494668, operation=87787324) at fileio.c:247
#4  0x50214 in Fexpand_file_name (name=55494668, defalt=55465472) at fileio.c:732
#5  0x8e240 in Fcall_process (nargs=6, args=0xefffc45c) at callproc.c:209
#6  0x8e958 in Fcall_process_region (nargs=8, args=0xefffc454) at callproc.c:539
#7  0x753c0 in Ffuncall (nargs=137663964, args=0xefffc450) at eval.c:2059
#8  0x88644 in Fbyte_code (bytestr=52404072, vector=69181540, maxdepth=8) at bytecode.c:422
#9  0x75998 in funcall_lambda (fun=102735656, nargs=3, arg_vector=0xefffc68c) at eval.c:2231
#10 0x754e0 in Ffuncall (nargs=102735656, args=0xefffc688) at eval.c:2106
#11 0x88644 in Fbyte_code (bytestr=52405076, vector=69182320, maxdepth=3) at bytecode.c:422
#12 0x75998 in funcall_lambda (fun=102736676, nargs=1, arg_vector=0xefffc8ac) at eval.c:2231
#13 0x754e0 in Ffuncall (nargs=102736676, args=0xefffc8a8) at eval.c:2106
#14 0x88644 in Fbyte_code (bytestr=52400384, vector=69177796, maxdepth=1) at bytecode.c:422
#15 0x75998 in funcall_lambda (fun=102732008, nargs=0, arg_vector=0xefffcb68) at eval.c:2231
#16 0x754e0 in Ffuncall (nargs=102732008, args=0xefffcb64) at eval.c:2106
#17 0x753c0 in Ffuncall (nargs=137660476, args=0xefffcb60) at eval.c:2059
#18 0x74f40 in call1 (fn=20572424, arg1=21047156) at eval.c:1850
#19 0x7addc in mapcar1 (leni=9, vals=0xefffcc90, fn=20572424, seq=88248284) at fns.c:1052
#20 0x7af50 in Fmapcar (fn=20572424, seq=88248284) at fns.c:1109
#21 0x753c0 in Ffuncall (nargs=137661760, args=0xefffce18) at eval.c:2059
#22 0x88644 in Fbyte_code (bytestr=51776508, vector=68553896, maxdepth=2) at bytecode.c:422
#23 0x75998 in funcall_lambda (fun=102108096, nargs=2, arg_vector=0xefffd044) at eval.c:2231
#24 0x754e0 in Ffuncall (nargs=102108096, args=0xefffd040) at eval.c:2106
#25 0x88644 in Fbyte_code (bytestr=51775428, vector=68552936, maxdepth=2) at bytecode.c:422
#26 0x75998 in funcall_lambda (fun=102107024, nargs=1, arg_vector=0xefffd270) at eval.c:2231
#27 0x754e0 in Ffuncall (nargs=102107024, args=0xefffd26c) at eval.c:2106
#28 0x88644 in Fbyte_code (bytestr=51772660, vector=68549892, maxdepth=1) at bytecode.c:422
#29 0x75998 in funcall_lambda (fun=102104268, nargs=1, arg_vector=0xefffd5d4) at eval.c:2231
#30 0x754e0 in Ffuncall (nargs=102104268, args=0xefffd5d0) at eval.c:2106
#31 0x71c7c in Fcall_interactively (function=20784652, record=20536324) at callint.c:586
#32 0x36f00 in Fcommand_execute (cmd=20784652, record=20536324) at keyboard.c:5261
#33 0x314d4 in command_loop_1 () at keyboard.c:1230
#34 0x738fc in internal_condition_case (bfun=0x30b94 <command_loop_1>, handlers=20536624, hfun=0x30584 <cmd_error>)
    at eval.c:1096
#35 0x30914 in command_loop_2 () at keyboard.c:879
#36 0x73458 in internal_catch (tag=20536604, func=0x308f0 <command_loop_2>, arg=20536324) at eval.c:886
#37 0x308c0 in command_loop () at keyboard.c:859
#38 0x303d0 in recursive_edit_1 () at keyboard.c:694
#39 0x30504 in Frecursive_edit () at keyboard.c:736
#40 0x2f928 in main (argc=1, argv=0xefffdd94, envp=0xefffdd9c) at emacs.c:762
(gdb) 

I'm not able to repeat the problem.  It happened as I was doing a
'find-file' on a gzipped file, using crypt++.el v2.77.  Here's the LCD
for it:

========================================================================
;;; LCD Archive Entry:
;;; crypt++|Rod Whitby and Lawrence R. Dodd|dodd@roebling.poly.edu|
;;; Code for handling all sorts of compressed and encrypted files.|
;;; 1993/12/07 14:28:36|2.77|~/misc/crypt++.el.Z|
========================================================================

I still have the gdb running, so if you're quick you can send me
commands to type at it if you need further information.

Chris.
--
Chris.Moore@src.bae.co.uk /      Chris Moore      \ Argue for your limitations
                         / Sowerby Research Centre \   and they will surely
                         \  British Aerospace PLC  /      become yours.
tel: +44 272 363375       \      BRISTOL, UK      /          -- Richard Bach
Technical Details
Message-ID: <9408171415.AA00346@sun25.src.bae.co.uk>
Path: arc1-ca.pugleaf.net!bga.com!news.sprintlink.net!uunet!newsfeed.ACO.net!news.sztaki.hu!EU.net!howland.reston.ans.net!math.ohio-state.edu!cis.ohio-state.edu!src.bae.co.uk!Chris.Moore

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fb2f1,b14032349d3cbf65
X-Google-Attributes: gidfb2f1,public
X-Google-ArrivalTime: 1994-08-17 09:42:51 PST
Path: arc1-ca.pugleaf.net!bga.com!news.sprintlink.net!uunet!newsfeed.ACO.net!news.sztaki.hu!EU.net!howland.reston.ans.net!math.ohio-state.edu!cis.ohio-state.edu!src.bae.co.uk!Chris.Moore
From: Chris.Moore@src.bae.co.uk (Chris Moore)
Newsgroups: gnu.emacs.bug
Subject: (none)
Date: 17 Aug 1994 12:29:09 -0400
Organization: GNUs Not Usenet
Lines: 76
Sender: daemon@cis.ohio-state.edu
Approved: bug-gnu-emacs@prep.ai.mit.edu
Distribution: gnu
Message-ID: <9408171415.AA00346@sun25.src.bae.co.uk>