🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.epoch.misc
Article #1191

epoch 4.2 dumps core during load

#1191
From: Kevin Burton
Date: Fri, 18 Sep 1992 22:46
191 lines
8397 bytes
I have built epoch 4.2 on my Sparcstation 1 running SunOS 4.1.1 and OpenLook
two times with no problems. The second time I changes the site-init.el file
and added some of the lisp modules that I was using all of the time. Now I
am on my third time and it doesn't work. I am not sure if it is the file
or if it is some bug in epoch. 

(All of these builds were with gcc 2.2.2,gld 2.0, and gas 1.38.1.)

The first file it dumps core on is derek-title.el which was written by
Derek Ney for the purpose of setting x-window titles. I retrieved it from
/outgoing/marca/epoch on ftp.ncsa.uiuc.edu. I run gdb and find out that
it core dumped in screen.c:

----- gdb screen ------
DEFUN ("epoch::screen-list",Fscreen_list,Sscreen_list,0,1,0,
      "Return a list of screens. If the argument is present and not nil\
then unmapped screens are returned in the list. The minibuf screen is _never_\
in the list") (unmap) Lisp_Object unmap;
{
  Lisp_Object block = rootblock;
  Lisp_Object list = Qnil;
  struct gcpro gcpro1;

  GCPRO1(list);
  do
    {
      if (!EQ(block,minibuf_rootblock) &&
	  (XXSCREEN(XROOT(block)->x11)->mapped || !NIL(unmap)))
	list = Fcons(block,list);
==>     block = XROOT(block)->next;
    }
  while (!EQ(block,rootblock));
  UNGCPRO;
  return list;
}
----- gdb screen end ------

Here is the stack traceback:

----- gdb screen ------
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.6, Copyright 1992 Free Software Foundation, Inc...
(gdb) core core
Core was generated by `temacs'.
Program terminated with signal 11, Segmentation fault.
#0  0xd044 in Fscreen_list (unmap=18083892) at screen.c:1737
(gdb) where
#0  0xd044 in Fscreen_list (unmap=18083892) at screen.c:1737
#1  0x465c8 in Ffuncall (nargs=607156, args=0xf7ffe080) at eval.c:1788
#2  0x51b88 in Fbyte_code (bytestr=51185652, vector=67962916, maxdepth=1288192)
    at bytecode.c:283
#3  0x45c00 in Feval (form=84740076) at eval.c:1444
#4  0x43bd4 in Fprogn (args=1288192) at eval.c:315
#5  0x46ac8 in funcall_lambda (fun=84740184, nargs=0, arg_vector=0xf7ffe404)
    at eval.c:1930
#6  0x466c8 in Ffuncall (nargs=84740184, args=0xf7ffe400) at eval.c:1818
#7  0x51b88 in Fbyte_code (bytestr=51636220, vector=68584520, maxdepth=1288192)
    at bytecode.c:283
#8  0x45c00 in Feval (form=85324468) at eval.c:1444
#9  0x4bcd8 in readevalloop (readcharfun=18171292, stream=0x127b2c, 
    evalfun=0x4560c <Feval>, printflag=0) at lread.c:408
#10 0x4b8a0 in Fload (str=51635712, noerror=16777215, nomessage=18083852, 
    nosuffix=18083852) at lread.c:225
#11 0x45c2c in Feval (form=85279668) at eval.c:1448
#12 0x4bcd8 in readevalloop (readcharfun=18171292, stream=0x127b18, 
    evalfun=0x4560c <Feval>, printflag=0) at lread.c:408
#13 0x4b8a0 in Fload (str=51635696, noerror=16777215, nomessage=18083852, 
    nosuffix=18083852) at lread.c:225
#14 0x45c2c in Feval (form=85334116) at eval.c:1448
#15 0x4bcd8 in readevalloop (readcharfun=18171292, stream=0x127b04, 
    evalfun=0x4560c <Feval>, printflag=0) at lread.c:408
#16 0x4b8a0 in Fload (str=51630248, noerror=16777215, nomessage=18083852, 
    nosuffix=18083852) at lread.c:225
#17 0x45c2c in Feval (form=85279332) at eval.c:1448
#18 0x2244c in top_level_2 () at keyboard.c:561
#19 0x44e40 in internal_condition_case (bfun=0x2243c <top_level_2>, 
    handlers=18084112, hfun=0x220e0 <cmd_error>) at eval.c:1018
#20 0x2248c in top_level_1 () at keyboard.c:569
#21 0x4496c in internal_catch (tag=18084092, func=0x22454 <top_level_1>, 
    arg=18083852) at eval.c:826
#22 0x223b4 in command_loop () at keyboard.c:534
#23 0x22058 in recursive_edit_1 () at keyboard.c:420
#24 0x21fe8 in Frecursive_edit () at keyboard.c:402
#25 0x219b4 in main (argc=5, argv=0xf7ffefb8, envp=0xf7ffefcc) at emacs.c:565
(gdb) 
----- gdb screen end ------

The output from make looks like:
	Finding pointers to doc strings...
	Finding pointers to doc strings...done
	Loading site-init...
	Loading derek-title...
	make[1]: *** [epoch] Segmentation fault (core dumped)
	make: *** [doall] Error 1

So I decide to take derek-title out of the load but then I get stuck on a file
keys.el from the same place I got derek-title.el. Now the program dies in a
function called Fx_rebind_key in x11fns.c. The applicable section is:

----- gdb screen ------
     BLOCK_INPUT();
     xkey = XStringToKeysym(XSTRING(keycode)->data);
     if (xkey == NoSymbol)
       {
         UNBLOCK_INPUT();
         error("Invalid X-key name");
       }
 
==>  xkmap = XGetModifierMapping(XD_display);

     modlist = (KeySym *) alloca(xkmap->max_keypermod * 8 * sizeof(KeySym));
----- gdb screen end ------

And the stack trace is:

----- gdb screen ------
Core was generated by `temacs'.
Program terminated with signal 11, Segmentation fault.
#0  0x5c954 in XGetModifierMapping ()
(gdb) where
#0  0x5c954 in XGetModifierMapping ()
#1  0x8f0c in Fx_rebind_key (keycode=65386, modifiers=0, newstring=51855168)
    at x11fns.c:219
#2  0x46614 in Ffuncall (nargs=602020, args=0xf7ffe3f8) at eval.c:1794
#3  0x51b88 in Fbyte_code (bytestr=51854356, vector=68400648, maxdepth=1288192)
    at bytecode.c:283
#4  0x45c00 in Feval (form=85279652) at eval.c:1444
#5  0x4bcd8 in readevalloop (readcharfun=18171292, stream=0x127b2c, 
    evalfun=0x4560c <Feval>, printflag=0) at lread.c:408
#6  0x4b8a0 in Fload (str=51637004, noerror=16777215, nomessage=18083852, 
    nosuffix=18083852) at lread.c:225
#7  0x45c2c in Feval (form=85279668) at eval.c:1448
#8  0x4bcd8 in readevalloop (readcharfun=18171292, stream=0x127b18, 
    evalfun=0x4560c <Feval>, printflag=0) at lread.c:408
#9  0x4b8a0 in Fload (str=51635696, noerror=16777215, nomessage=18083852, 
    nosuffix=18083852) at lread.c:225
#10 0x45c2c in Feval (form=85334116) at eval.c:1448
#11 0x4bcd8 in readevalloop (readcharfun=18171292, stream=0x127b04, 
    evalfun=0x4560c <Feval>, printflag=0) at lread.c:408
#12 0x4b8a0 in Fload (str=51630248, noerror=16777215, nomessage=18083852, 
    nosuffix=18083852) at lread.c:225
#13 0x45c2c in Feval (form=85279332) at eval.c:1448
#14 0x2244c in top_level_2 () at keyboard.c:561
#15 0x44e40 in internal_condition_case (bfun=0x2243c <top_level_2>, 
    handlers=18084112, hfun=0x220e0 <cmd_error>) at eval.c:1018
#16 0x2248c in top_level_1 () at keyboard.c:569
#17 0x4496c in internal_catch (tag=18084092, func=0x22454 <top_level_1>, 
    arg=18083852) at eval.c:826
#18 0x223b4 in command_loop () at keyboard.c:534
#19 0x22058 in recursive_edit_1 () at keyboard.c:420
#20 0x21fe8 in Frecursive_edit () at keyboard.c:402
#21 0x219b4 in main (argc=5, argv=0xf7ffefb8, envp=0xf7ffefcc) at emacs.c:565
(gdb)
----- gdb screen end ------

The output from make looks like:
	Finding pointers to doc strings...
	Finding pointers to doc strings...done
	Loading site-init...
	Loading thing...
	Loading imouse...
	Loading marc-modeline...
	Loading keys...
	make[1]: *** [epoch] Segmentation fault (core dumped)
	make: *** [doall] Error 1

Any ideas ? I have changed the config.h to have 

	#ifndef PURESIZE
	#ifdef HAVE_X_WINDOWS
	#define PURESIZE 520000
	#else
	#define PURESIZE 320000
	#endif
	#endif

Is this a problem? On the last build I had to increase it to remove
the "Pure Lisp Storage exhausted" message. I do vaguely remember that
someone reported something about PURESIZE above some value causes problems.
If this is so what is the value ?

Thanks for your time.

-
Kevin Burton
Noran Instruments				voice: (608) 831-6511 x317
2551 West Beltline Highway, Room 532		  FAX: (608) 836-7224
Middleton, WI 53562				email: kburton@noran.com
Technical Details
Message-ID: <9209182246.AA19406@iowa.YP.solsys>
Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!iowa.UUCP!kburton

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fc7ee,576d903c5911fb9f,start
X-Google-Attributes: gidfc7ee,public
X-Google-ArrivalTime: 1992-09-18 12:32:26 PST
Newsgroups: gnu.epoch.misc
Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!iowa.UUCP!kburton
From: kburton@iowa.UUCP (Kevin Burton)
Subject: epoch 4.2 dumps core during load
Message-ID: <9209182246.AA19406@iowa.YP.solsys>
Sender: daemon@cis.ohio-state.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 18 Sep 1992 22:46:31 GMT
Lines: 191