From: Richard Stallman <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Program received signal SIGSEGV, Segmentation fault.
Date: Sun, 22 Aug 2004 12:52:49 -0400 [thread overview]
Message-ID: <E1ByvaL-0003CR-HX@fencepost.gnu.org> (raw)
In-Reply-To: <200408201822.i7KIManS011754@alstadheim.priv.no> (hakon@alstadheim.priv.no)
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
next prev parent reply other threads:[~2004-08-22 16:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-13 20:39 Program received signal SIGSEGV, Segmentation fault Håkon Alstadheim
2004-08-13 21:26 ` Andreas Schwab
2004-08-14 8:20 ` Håkon Alstadheim
2004-08-21 19:27 ` Håkon Alstadheim
[not found] ` <E1Bw9P5-0000TK-OU@fencepost.gnu.org>
[not found] ` <200408201822.i7KIManS011754@alstadheim.priv.no>
2004-08-22 16:52 ` Richard Stallman [this message]
2004-09-02 16:25 ` Jan D.
2004-09-02 19:06 ` Håkon Alstadheim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1ByvaL-0003CR-HX@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.