From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Marshall, Simon" Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: RE: [22.1.90]: Point before start of properties Date: Tue, 19 Feb 2008 10:37:39 -0000 Message-ID: <6EE216E1AA959543A555C60FF34FB7670300E86B@maileube01.misys.global.ad> References: <6EE216E1AA959543A555C60FF34FB76702E48034@maileube01.misys.global.ad><87wspcj0ou.fsf@stupidchicken.com><6EE216E1AA959543A555C60FF34FB76702EED4A1@maileube01.misys.global.ad><6EE216E1AA959543A555C60FF34FB76702EEDA6E@maileube01.misys.global.ad> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1203417604 10784 80.91.229.12 (19 Feb 2008 10:40:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Feb 2008 10:40:04 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org, Chong Yidong To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 19 11:40:27 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JRPtc-0000VG-D3 for ged-emacs-devel@m.gmane.org; Tue, 19 Feb 2008 11:40:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRPt7-0005s4-JV for ged-emacs-devel@m.gmane.org; Tue, 19 Feb 2008 05:39:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRPt2-0005rt-69 for emacs-devel@gnu.org; Tue, 19 Feb 2008 05:39:44 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRPt0-0005qc-A7 for emacs-devel@gnu.org; Tue, 19 Feb 2008 05:39:42 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRPt0-0005qP-2G for emacs-devel@gnu.org; Tue, 19 Feb 2008 05:39:42 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JRPsz-0008HR-MC for emacs-devel@gnu.org; Tue, 19 Feb 2008 05:39:41 -0500 Original-Received: from mail.gnu.org ([199.232.76.166] helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1JRPsz-0004iY-BE for emacs-pretest-bug@gnu.org; Tue, 19 Feb 2008 05:39:41 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1JRPsw-0008G1-40 for emacs-pretest-bug@gnu.org; Tue, 19 Feb 2008 05:39:41 -0500 Original-Received: from cluster-a.mailcontrol.com ([80.69.8.190]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JRPsv-0008Eb-Fa for emacs-pretest-bug@gnu.org; Tue, 19 Feb 2008 05:39:37 -0500 Original-Received: from rly06a.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly06a.srv.mailcontrol.com (MailControl) with ESMTP id m1JAcd9N013164 for ; Tue, 19 Feb 2008 10:39:15 GMT Original-Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly06a.srv.mailcontrol.com (MailControl) id m1JAbhQT011985 for emacs-pretest-bug@gnu.org; Tue, 19 Feb 2008 10:37:43 GMT Original-Received: from maileube01.misys.global.ad ([217.196.233.105]) by rly06a-eth0.srv.mailcontrol.com (envelope-sender Simon.Marshall@misys.com) (MIMEDefang) with ESMTP id m1JAaQhk009794; Tue, 19 Feb 2008 10:37:43 +0000 (GMT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [22.1.90]: Point before start of properties Thread-Index: AchyZ9Z5f0nFoIVVRKiAQlUUJN8f4QAcrV+w X-Scanned-By: MailControl A-08-00-01 (www.mailcontrol.com) on 10.65.1.116 X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:89564 gmane.emacs.pretest.bugs:21217 Archived-At: > > Yes. Btw, I didn't mention before that gcc gives me lots of warnings of > > the form "dispnew.c:3061: warning: incompatible implicit declaration of > > built-in function 'alloca'". (That is the reason why I tried undefing > > GNU_MALLOC and HAVE_ALLOCA, though IIRC I could not get rid of the > > warnings and made no difference to the problem of calling error at > > intervals.c:794.) Could this be relevant? >=20 > Any warning outside of intervals.c seem unlikely to be a good source of > the problem. Do you ever get any kind of warning when compiling > intervals.c? No. > Also you said that the problem could be triggered with gcc-4.1.2 even > without optimization, is that really true? If so, can you try again > with gcc-4.1.2 and no optimizations, to get better debug info? Ah, I did say that didn't I. A typo I think. (I cannot reproduce it without optimisation, though I have since installed 4.2.3 over the top of 4.1.2. I tried to reproduce it today with CC=3Dsparc-sun-solaris2.8-gcc-4.1.2, and I could with CFLAGS=3D"-g -O" and "-g -O2", but not with CFLAGS=3D"-g". Apologies for that.) > Another thing: do you know if your compilation uses USE_LSB_TAG or not? > Is it a 64bit or 32bit memory model? > Have you tried to compile it with -DUSE_LISP_UNION_TYPE just to see if > it hides the problem (or give some compilation warning at least)? I'm guessing it's 32bit. With CFLAGS=3D"-g -O2 -DUSE_LISP_UNION_TYPE", there were no suspicious compiler warnings (non at all for intervals.c) and it still hit the intervals.c:794 breakpoint. > > I can understand not being able to see i0 in intervals_equal, but I > > don't understand not being able to see prev and newi in the caller. I > > tried to reproduce this with CFLAGS=3D"-g -DENABLE_CHECKING=3D1 > > -DSYSTEM_PURESIZE_EXTRA=3D1300000", ie, no optimisation, but could not > > reproduce the abort (or call of error). >=20 > The fact that you don't get the assertion failure when compiling without > optimizations indicates that this assertion failure is unlikely to > be a fluke, tho the "CHECK (!INT_LISPLIKE (i)" thingy is fishy. >=20 > The fields of the i1 interval don't seem to be valid (0x8 can't be > a left pointer, the right point seems to be misaligned (maybe it's > actually a string and the up_obj bit should be set), total_length and > position could only make sense in a buffer of at least 5-6MB). > Then again, we have no idea if we're really looking at i1 and > its contents. >=20 > > Do you think these ENABLE_CHECKING aborts are genuine? >=20 > Maybe. >=20 > > Could there be a problem with the definition of NULL_INTERVAL_P (I see > > its definition has changed)? >=20 > The INT_LISPLIKE thingy is fishy. I suspect that it may misfire (the > "struct interval" may have size 28, so intervals pointers may not all be > aligned on multiples of 8, which implies that an interval pointer may > have the same tag bits as a buffer). >=20 > > So, ENABLE_CHECKING not withstanding, it appears to be a problem with > > the optimisation of intervals.c itself. > > Any other thoughts? >=20 > Not really. If you can reproduce it without optimizations,=20 > then you may > be able to track it down more precisely and figure out if it's > a compiler bug or an Emacs bug. Thanks for the suggestions and the careful reading of my report. Is there anything else you think I could try, eg, to deal with the size of struct interval? I can confirm that it is 28, though it is 28 with or without optimisation. I tried padding it to 32 by adding a dummy int to it, but it still hit the breakpoint with optimisation. I don't like the thought of trying to break up intervals.c, to binary search for a particular problem function, so any other suggestions are welcome. Simon. "Misys" is the trade name for Misys plc (registered in England and Wales).= Registration Number: 01360027. Registered office: Burleigh House, Chapel O= ak, Salford Priors, Evesham WR11 8SP. For a list of Misys group operating c= ompanies please go to http://www.misys.com/html/about_us/group_operating_co= mpanies/. This email and any attachments have been scanned for known viruse= s using multiple scanners.=20 =20 We believe that this email and any attachments are virus free, however the = recipient must take full responsibility for virus checking. This email mess= age is intended for the named recipient only. It may be privileged and/or c= onfidential. If you are not the named recipient of this email please notify= us immediately and do not copy it or use it for any purpose, nor disclose = its contents to any other person. This email does not constitute the commen= cement of legal relations between you and Misys plc. Please refer to the ex= ecuted contract between you and the relevant member of the Misys group for = the identity of the contracting party with which you are dealing.=20