From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nix Newsgroups: gmane.emacs.bugs Subject: bug#10617: 24.0.92; Bidi crash reading a message from emacs-devel Date: Mon, 30 Jan 2012 18:14:28 +0000 Message-ID: <87vcnt5a7v.fsf@spindle.srvr.nix> References: <87ehumm6jt.fsf@spindle.srvr.nix> <83pqe5zfd6.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1327947306 16440 80.91.229.3 (30 Jan 2012 18:15:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 30 Jan 2012 18:15:06 +0000 (UTC) Cc: 10617@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 30 19:15:04 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rrvkt-0006KV-VQ for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Jan 2012 19:15:04 +0100 Original-Received: from localhost ([::1]:34753 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rrvkt-0001wz-7K for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Jan 2012 13:15:03 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:34806) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rrvko-0001wR-0k for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2012 13:15:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rrvkh-0000EV-U1 for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2012 13:14:57 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rrvkh-0000ER-Qe for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2012 13:14:51 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Rrvks-0000ND-FX for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2012 13:15:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Nix Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Jan 2012 18:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10617 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10617-submit@debbugs.gnu.org id=B10617.13279472851394 (code B ref 10617); Mon, 30 Jan 2012 18:15:02 +0000 Original-Received: (at 10617) by debbugs.gnu.org; 30 Jan 2012 18:14:45 +0000 Original-Received: from localhost ([127.0.0.1]:45523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rrvkb-0000MR-AZ for submit@debbugs.gnu.org; Mon, 30 Jan 2012 13:14:45 -0500 Original-Received: from icebox.esperi.org.uk ([81.187.191.129]:46129 helo=mail.esperi.org.uk) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RrvkY-0000MH-EH for 10617@debbugs.gnu.org; Mon, 30 Jan 2012 13:14:44 -0500 Original-Received: from esperi.org.uk (nix@spindle.srvr.nix [192.168.14.15]) by mail.esperi.org.uk (8.14.5/8.14.5) with ESMTP id q0UIESCW030776; Mon, 30 Jan 2012 18:14:28 GMT Original-Received: (from nix@localhost) by esperi.org.uk (8.14.5/8.14.5/Submit) id q0UIESFN003139; Mon, 30 Jan 2012 18:14:28 GMT Emacs: is that a Lisp interpreter in your editor, or are you just happy to see me? In-Reply-To: <83pqe5zfd6.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 27 Jan 2012 11:03:49 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-DCC-URT-Metrics: spindle 1060; Body=2 Fuz1=2 Fuz2=2 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:56236 Archived-At: On 27 Jan 2012, Eli Zaretskii spake thusly: >> From: Nix >> Emacs: no job too big... no job. >> Date: Thu, 26 Jan 2012 22:40:22 +0000 >> >> I just got a bidi crash reading an emacs-devel message in Gnus (bzr >> r106941). > > I'm curious: why do you think this crash has anything to do with bidi? > There are no bidi-related functions anywhere in the backtrace you > show. Oh. Maybe I jumped to conclusions, but the fact that I got it when viewing a heavily-bidi message roused suspicions too strong to see past :) emacs is too reliable, that's the problem: if it kept crashing all the time I'd not make this sort of assumption, but since this is my first crash in months I assumed that most of it was bug-free! >> (but you can't see the bidi goodness there, if it *is* meant to be good >> to find the periods transposed to the other end of the line while the >> lines themselves still read in L2R, but right-justified. Weird, but >> maybe intended, I dunno.) > > This weird display is mandated by the Unicode Bidirectional Algorithm, > because the quoted part of the message is treated as a single > right-to-left paragraph. It is a single paragraph because there are > no empty lines in it, and it takes a right-to-left paragraph direction > because the first strong directional character is an Arabic letter, > whose directionality is right to left. It's not a bug then, good :) >> It is quite clear from the backtrace that the second parameter to >> char_table_ref() has been garbaged, apparently being set to 2^32/1000 >> (again, passing strange). > > Sorry, I don't believe backtraces from optimized builds, they lie > through their teeth. Backtraces from optimized GCC builds on x86_64 Linux (and, on modern GCC's, on i386 too) don't work by doing frame pointer walking anymore, they do DWARF walking. If that lies, the stack is severely corrupted and exception handling will also crash: perhaps not terribly relevant for most C programs but still a sign that keeping this particular data structure un-fudged-up is considered important. (There are the usual modifications due to inlining and sibcalls but they are easy to compensate for.) So it's a good bit more reliable than it used to be. You can generally rely on the function names being valid. Looking at variable values from optimized builds still sucks giant asteroids through micropipettes though. :( so the parameters in the backtraces might sometimes be lying or outdated. >> I still have the coredump: any debugging I can do, just ask. > > It would be interesting to see it->current, it->position, it->sp, and > it->string in frames #6 and #8. Frame 6: (gdb) print it->current $3 = { pos = { charpos = 1430, bytepos = 1394 }, overlay_string_index = -1, string_pos = { charpos = -1, bytepos = -1 }, dpvec_index = -1 } (gdb) print it->position $4 = { charpos = 1430, bytepos = 1394 } (gdb) print it->sp $5 = 0 (gdb) print it->string $6 = 12065314 Frame 8: (gdb) print it->current $7 = { pos = { charpos = 1430, bytepos = 1394 }, overlay_string_index = -1, string_pos = { charpos = -1, bytepos = -1 }, dpvec_index = -1 } (gdb) print it->position $8 = { charpos = 1430, bytepos = 1394 } (gdb) print it->sp $9 = 0 (gdb) print it->string $10 = 12065314 (i.e. unchanged) > Also, what do you have in the buffer > at the position(s) shown by it->current and it->position (the > functions in etc/emacs-buffer.gdb might come in handy for finding this > out). I'm afraid optimized-build hell has kicked in here: There is no member named data. I suspect this will be undiagnosable unless I can reproduce this in an unoptimized build :( >> (However, the thing was compiled with optimization, so debugging is >> visibly degraded. I'm just about to upgrade GDB to 7.4: maybe that >> will help a bit.) >> >> No recipe from emacs -Q yet (a bit hard given that this is provoked by >> Gnus-plus-nnml). Tomorrow I'll try to come up with a reproduction recipe >> based on the text of the message alone. > > A newer GDB will help, but please also try this in an unoptimized > build. If you can reproduce it there, we will have much better > chances of finding the culprit. I'll try that soon. I doubt we can get much further with this as it stands :( > Also, please show the results of "xbacktrace" (starting GDB from the > Emacs src directory should cause that be done automagically). "There is no member named data" again. Sigh :( >> In GNU Emacs 24.0.92.2 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars) >> of 2012-01-26 on spindle >> Windowing system distributor `The X.Org Foundation', version 11.0.11003901 >> configured using `configure '--without-pop' '--without-kerberos' '--without-hesiod' '--without-mmdf' '--with-x-toolkit=lucid' '--with-wide-int' 'NO_FAST_MATH=t'' > > Can you tell whether you built with libraries mentioned in INSTALL > under "Complex Text Layout support libraries", and if so, which > versions thereof? I didn't build with any of the complex text layout support libraries at all. > Also, do you have any problems whatsoever displaying etc/HELLO in its > entirety? No. -- NULL && (void)