Re: Program received signal SIGSEGV, Segmentation fault.

Re: Program received signal SIGSEGV, Segmentation fault.

[Richard Stallman]

This seg fault does not happen for me.

    #4  0x0816dfca in xfree (block=0x893c5e8) at alloc.c:564
    #5  0x08102e6b in x_set_name (f=0x893c5e0, name=1091742672, explicit=0)
	at xfns.c:1665

Maybe it is freeing something that wasn't allocated with malloc.

(Here's the original message sent to me.)


To: rms@gnu.org
Subject: Re: Program received signal SIGSEGV, Segmentation fault. 
In-Reply-To: Your message of "Sat, 14 Aug 2004 21:01:43 EDT."
             <E1Bw9P5-0000TK-OU@fencepost.gnu.org> 
Date: Fri, 20 Aug 2004 20:22:36 +0200
From: "=?ISO-8859-1?Q?H=E5kon?= Alstadheim" <hakon@alstadheim.priv.no>
X-Spam-Status: No, hits=-0.5 required=5.0
	tests=IN_REP_TO,RCVD_IN_ORBS,REFERENCES
	version=2.55
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)


Short answer: The bug is also in cvs.

Rms wrote:
> Could you try the latest Emacs from CVS on savannah.gnu.org
> and see if it works any better?


Long answer:

I took some time getting back to you because I wanted to clean up some
stale dynamic libraries etc. Emacs 21.3.1 built with the SuSE rpm
spec-file still crashes on me. Now I've tried the CVS version, and yes
it segfaults.

Trying to run it like so: 

 `/usr/src/cvs-emacs/emacs/src/emacs -q --no-site-file'

results in segfault and the the backtrace below immediately when I try
to launch. Allowing init-files makes it last a bit longer. I suspect I
may have some gremlins in my X-resources. Is emacs supposed to be able
to run with a single, separate minibuffer-frame? That is how I run it,
by setting the X-resource:
  
  emacs*minibuffer:       none

Emacs complains that `none' is non-numeric, but using 0 did not do
what I wanted way back when... Hmmm.. maybe that is when emacs started
crashing on me ?? It's gotten worse with every upgrade though.

;; pause for testing .... yup, setting emacs*minibuffer to anything
;; like `no' or 0 results in a minibuffer in the main frames, (which I
;; don't want) but I get no segfault on startup with
;; `/usr/src/cvs-emacs/emacs/src/emacs -q --no-site-file'

  
OK, That is at least one badness in my setup found. I will rectify my
X-resource setup, and keep running 21.3.1. I'll get back to you if the
crashes persist.

To the gdb session :
 -------------------------
Starting program: /usr/src/cvs-emacs/emacs/src/emacs -q --no-site-file

Program received signal SIGSEGV, Segmentation fault.
0x4107b1dd in _int_free () from /lib/tls/libc.so.6
((gdb) backtrace
#0  0x4107b1dd in _int_free () from /lib/tls/libc.so.6
#1  0x4107b61b in free () from /lib/tls/libc.so.6
#2  0x0816e584 in emacs_blocked_free (ptr=0x893c5e8) at alloc.c:955
#3  0x4107b5c5 in free () from /lib/tls/libc.so.6
#4  0x0816dfca in xfree (block=0x893c5e8) at alloc.c:564
#5  0x08102e6b in x_set_name (f=0x893c5e0, name=1091742672, explicit=0)
    at xfns.c:1665
#6  0x080af5ee in prepare_menu_bars () at xdisp.c:8050
#7  0x080b43ac in redisplay_internal (preserve_echo_area=Variable "preserve_echo_area" is not available.
) at xdisp.c:9805
#8  0x08129614 in read_char (commandflag=1, nmaps=2, maps=0xbfffd960,
    prev_event=138502161, used_mouse_menu=0xbfffd9a8) at keyboard.c:2531
#9  0x0812c395 in read_key_sequence (keybuf=0xbfffdac0, bufsize=30,
    prompt=138502161, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:8820
#10 0x0812dfd9 in command_loop_1 () at keyboard.c:1525
#11 0x08182e7d in internal_condition_case (bfun=0x812de30 <command_loop_1>,
    handlers=138563089, hfun=0x8128890 <cmd_error>) at eval.c:1346
#12 0x08127b7c in command_loop_2 () at keyboard.c:1306
#13 0x08182f5a in internal_catch (tag=283011960,
    func=0x8127b60 <command_loop_2>, arg=138502161) at eval.c:1107
#14 0x08128527 in command_loop () at keyboard.c:1273
#15 0x08128612 in recursive_edit_1 () at keyboard.c:978
#16 0x0812872f in Frecursive_edit () at keyboard.c:1039
#17 0x08184083 in Ffuncall (nargs=1, args=0xbfffde50) at eval.c:2733
#18 0x081b04c9 in Fbyte_code (bytestr=137076035, vector=137076132, maxdepth=48)
    at bytecode.c:689
#19 0x081835fa in Feval (form=137076021) at eval.c:2101
#20 0x08182f5a in internal_catch (tag=283011960, func=0x81831d0 <Feval>,
    arg=137076021) at eval.c:1107
#21 0x081afce1 in Fbyte_code (bytestr=137075635, vector=137075708, maxdepth=48)
    at bytecode.c:852
#22 0x08183b50 in funcall_lambda (fun=137075708, nargs=0,
    arg_vector=0xbfffe1a4) at eval.c:2923
#23 0x08183ed3 in Ffuncall (nargs=1, args=0xbfffe1a0) at eval.c:2793
#24 0x081b04c9 in Fbyte_code (bytestr=137081611, vector=137081644, maxdepth=8)
    at bytecode.c:689
#25 0x08183b50 in funcall_lambda (fun=137081644, nargs=0,
    arg_vector=0xbfffe2a4) at eval.c:2923
#26 0x08183ed3 in Ffuncall (nargs=1, args=0xbfffe2a0) at eval.c:2793
#27 0x081b04c9 in Fbyte_code (bytestr=137082107, vector=137083212, maxdepth=96)
    at bytecode.c:689
#28 0x08183b50 in funcall_lambda (fun=137083212, nargs=1,
    arg_vector=0xbfffe3c4) at eval.c:2923
#29 0x08183ed3 in Ffuncall (nargs=2, args=0xbfffe3c0) at eval.c:2793
#30 0x081b04c9 in Fbyte_code (bytestr=137065947, vector=137067220, maxdepth=48)
    at bytecode.c:689
#31 0x08183b50 in funcall_lambda (fun=137067220, nargs=0,
    arg_vector=0xbfffe4d4) at eval.c:2923
#32 0x08183ed3 in Ffuncall (nargs=1, args=0xbfffe4d0) at eval.c:2793
#33 0x081b04c9 in Fbyte_code (bytestr=137060835, vector=137060988, maxdepth=48)
    at bytecode.c:689
#34 0x08183b50 in funcall_lambda (fun=137060988, nargs=0,
    arg_vector=0xbfffe580) at eval.c:2923
#35 0x08183c6f in apply_lambda (fun=137060812, args=138502161, eval_flag=1)
    at eval.c:2845
#36 0x081833ee in Feval (form=140142229) at eval.c:2149
#37 0x08124e71 in top_level_2 () at keyboard.c:1315
#38 0x08182e7d in internal_condition_case (bfun=0x8124e60 <top_level_2>,
    handlers=138563089, hfun=0x8128890 <cmd_error>) at eval.c:1346
#39 0x08127b20 in top_level_1 () at keyboard.c:1323
#40 0x08182f5a in internal_catch (tag=283011960, func=0x8127af0 <top_level_1>,
    arg=138502161) at eval.c:1107
#41 0x08128558 in command_loop () at keyboard.c:1280
#42 0x08128612 in recursive_edit_1 () at keyboard.c:978
#43 0x0812872f in Frecursive_edit () at keyboard.c:1039
#44 0x0811f3f1 in main (argc=3, argv=0xbfffec34) at emacs.c:1687

Re: Program received signal SIGSEGV, Segmentation fault.

[Jan D.]

> This seg fault does not happen for me.
>
>     #4  0x0816dfca in xfree (block=0x893c5e8) at alloc.c:564
>     #5  0x08102e6b in x_set_name (f=0x893c5e0, name=1091742672, 
> explicit=0)
> 	at xfns.c:1665
>
> Maybe it is freeing something that wasn't allocated with malloc.
...

> (Here's the original message sent to me.)
...

>> Could you try the latest Emacs from CVS on savannah.gnu.org
>> and see if it works any better?
>
>
> Long answer:
>
> I took some time getting back to you because I wanted to clean up some
> stale dynamic libraries etc. Emacs 21.3.1 built with the SuSE rpm
> spec-file still crashes on me. Now I've tried the CVS version, and yes
> it segfaults.
>

I've put in a change in CVS that may fix this, can you test a fresh CVS 
version again?

Thanks,

	Jan D.

Re: Program received signal SIGSEGV, Segmentation fault.

[Håkon Alstadheim]

Jan D. Wrote on Thu, 2 Sep: 

> >     #4  0x0816dfca in xfree (block=0x893c5e8) at alloc.c:564
> >     #5  0x08102e6b in x_set_name (f=0x893c5e0, name=1091742672, 
> > explicit=0)
> > 	at xfns.c:1665
>
> I've put in a change in CVS that may fix this, can you test a fresh CVS 
> version again?
> 

Yay! I've only just started it up, but at least it now gets the frames up
without crashing. I'll try to switch over to the cvs version, and run
it for a while longer.


The test case is just:

  xrdb -merge <<end 
  emacs*minibuffer: none
  end
  ./emacs -q --no-site-file 

Emacs 21.3 will run like this for some hours, then segfault. The
previous cvs-version I tried crashed before any frames were put up.
Current cvs is still running after 5 minutes of testing. Also the 
`Warning: Cannot convert string "none" to type Int' in the terminal
window is now gone.