From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: allocate_string_data memory corruption Date: Mon, 23 Jan 2006 15:21:42 -0500 Message-ID: References: <87vewha2zl.fsf@stupidchicken.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1138049993 1560 80.91.229.2 (23 Jan 2006 20:59:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 23 Jan 2006 20:59:53 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 23 21:59:51 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F18mb-0001VC-Qc for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2006 21:59:26 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F18pG-0007wJ-7f for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2006 16:02:10 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F18J0-00013C-US for emacs-devel@gnu.org; Mon, 23 Jan 2006 15:28:52 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F18FT-0007Wy-A2 for emacs-devel@gnu.org; Mon, 23 Jan 2006 15:25:12 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F18Es-00077e-Km for emacs-devel@gnu.org; Mon, 23 Jan 2006 15:24:36 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1F18Jf-0000ue-Nu for emacs-devel@gnu.org; Mon, 23 Jan 2006 15:29:31 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id A94962CE9BE; Mon, 23 Jan 2006 15:21:48 -0500 (EST) Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id A51D64AC15A; Mon, 23 Jan 2006 15:21:42 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id 94040E6C1E; Mon, 23 Jan 2006 15:21:42 -0500 (EST) Original-To: Chong Yidong In-Reply-To: (Stefan Monnier's message of "Wed, 18 Jan 2006 15:48:33 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.854, requis 5, autolearn=not spam, AWL 0.05, BAYES_00 -4.90) X-MailScanner-From: monnier@iro.umontreal.ca X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:49455 Archived-At: >> In this function, data->string is set to s, and nbytes is set to >> nbytes. If check_sblock is a no-op, there should be no change. >> However, we get an abort on the second debugging check: > Most likely the thing that's happening is that check_sblock takes a "long" > time during which there's a higher probability for a signal to arrive and > the bug itself is that one of the signal handlers does some string > allocation (or some other manipulation of those data structures). > I'd try something like > eassert (!in_allocate_string_data); > in_allocate_string_data = 1; > ... > check_sblock(); > ... > in_allocate_string_data = 0; > BTW, it's possible that -DSYNC_INPUT fixes the bug. My recent eassert (!handling_signal) patch uncovered another case where Lisp objects are allocated asynchronously (and this time, it's allocating a string rather than a vector, so it's more serious): A backtrace is attached. I don't know how to go about fixing this problem (other than use -DSYNC_INPUT). I seem to remember discussions in the past about moving the note_mouse_movement code to the normal main loop (i.e. generate a special Lisp event and bind it in special-event-map) which could solve this problem, but at the cost of delaying the processing of mouse_movement even more than -DSYNC_INPUT would. Stefan #0 abort () at emacs.c:464 #1 0x00000000006136c7 in die (msg=0x736410 "assertion failed: !handling_signal", file=0x736190 "alloc.c", line=1845) at alloc.c:6127 #2 0x0000000000609d50 in allocate_string () at alloc.c:1845 #3 0x000000000060b182 in make_uninit_multibyte_string (nchars=63, nbytes=63) at alloc.c:2454 #4 0x000000000060b117 in make_uninit_string (length=63) at alloc.c:2435 #5 0x000000000060acfd in make_unibyte_string (contents=0x10047b8 "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1", length=63) at alloc.c:2349 #6 0x000000000060acc2 in make_string (contents=0x10047b8 "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1", nbytes=63) at alloc.c:2334 #7 0x000000000060b0fa in build_string (str=0x10047b8 "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1") at alloc.c:2423 #8 0x000000000053227e in x_load_font (f=0x1b9bb40, fontname=0x10047b8 "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1", size=0) at xterm.c:9726 #9 0x000000000054f2fd in fs_load_font (f=0x1b9bb40, c=0, fontname=0x10047b8 "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1", id=-1, face=0x0) at fontset.c:700 #10 0x000000000054ef6e in fontset_font_pattern (f=0x1b9bb40, id=102, c=0) at fontset.c:633 #11 0x0000000000516fc3 in choose_face_font (f=0x1b9bb40, attrs=0x210da48, fontset=102, c=0, needs_overstrike=0x7fbfffc264) at xfaces.c:6888 #12 0x0000000000507d08 in load_face_font (f=0x1b9bb40, face=0x210d9d0, c=0) at xfaces.c:1257 #13 0x00000000005184d6 in realize_face (cache=0x174e8c0, attrs=0x7fbfffc380, c=0, base_face=0x0, former_face_id=-1) at xfaces.c:7153 #14 0x00000000005145c4 in lookup_face (f=0x1b9bb40, attr=0x7fbfffc380, c=0, base_face=0x0) at xfaces.c:5685 #15 0x0000000000519b2c in face_at_string_position (w=0x1f9de00, string={i = 6917529027653345456, s = {val = 12263600, type = Lisp_String}, u = {val = 12263600, type = Lisp_String}}, pos=1, bufpos=0, region_beg=0, region_end=0, endptr=0x7fbfffc504, base_face_id=14, mouse_p=1) at xfaces.c:7786 #16 0x000000000048fdec in note_mode_line_or_margin_highlight (window={i = -9223372036821623296, s = {val = 33152512, type = Lisp_Vectorlike}, u = {val = 33152512, type = Lisp_Vectorlike}}, x=20, y=53, area=ON_MODE_LINE) at xdisp.c:22128 #17 0x000000000049010a in note_mouse_highlight (f=0x1b9bb40, x=121, y=494) at xdisp.c:22219 #18 0x0000000000523b09 in note_mouse_movement (frame=0x1b9bb40, event=0x7fbfffcb30) at xterm.c:3614 #19 0x000000000052b3ff in handle_one_xevent (dpyinfo=0x10315b0, eventp=0x7fbfffcfd0, finish=0x7fbfffcf6c, hold_quit=0x7fbfffe120) at xterm.c:6573 #20 0x000000000052bfee in XTread_socket (sd=2, expected=1, hold_quit=0x7fbfffe120) at xterm.c:7021 #21 0x0000000000580165 in read_avail_input (expected=1) at keyboard.c:6710 #22 0x0000000000580356 in handle_async_input () at keyboard.c:6856