* Re: Program received signal SIGSEGV, Segmentation fault.
[not found] ` <200408201822.i7KIManS011754@alstadheim.priv.no>
@ 2004-08-22 16:52 ` Richard Stallman
2004-09-02 16:25 ` Jan D.
0 siblings, 1 reply; 3+ messages in thread
From: Richard Stallman @ 2004-08-22 16:52 UTC (permalink / raw
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Program received signal SIGSEGV, Segmentation fault.
2004-08-22 16:52 ` Program received signal SIGSEGV, Segmentation fault Richard Stallman
@ 2004-09-02 16:25 ` Jan D.
2004-09-02 19:06 ` Håkon Alstadheim
0 siblings, 1 reply; 3+ messages in thread
From: Jan D. @ 2004-09-02 16:25 UTC (permalink / raw
Cc: Richard Stallman, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Program received signal SIGSEGV, Segmentation fault.
2004-09-02 16:25 ` Jan D.
@ 2004-09-02 19:06 ` Håkon Alstadheim
0 siblings, 0 replies; 3+ messages in thread
From: Håkon Alstadheim @ 2004-09-02 19:06 UTC (permalink / raw
Cc: Richard Stallman, emacs-devel
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-09-02 19:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200408132039.i7DKdH2F006136@alstadheim.priv.no>
[not found] ` <E1Bw9P5-0000TK-OU@fencepost.gnu.org>
[not found] ` <200408201822.i7KIManS011754@alstadheim.priv.no>
2004-08-22 16:52 ` Program received signal SIGSEGV, Segmentation fault Richard Stallman
2004-09-02 16:25 ` Jan D.
2004-09-02 19:06 ` Håkon Alstadheim
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).