RE: [22.1.90]: Point before start of properties

[Marshall, Simon]

> > 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?
> 
> 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=sparc-sun-solaris2.8-gcc-4.1.2, and I could with CFLAGS="-g -O" and
"-g -O2", but not with CFLAGS="-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="-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="-g -DENABLE_CHECKING=1
> > -DSYSTEM_PURESIZE_EXTRA=1300000", ie, no optimisation, but could not
> > reproduce the abort (or call of error).
> 
> 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.
> 
> 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.
> 
> > Do you think these ENABLE_CHECKING aborts are genuine?
> 
> Maybe.
> 
> > Could there be a problem with the definition of NULL_INTERVAL_P (I
see
> > its definition has changed)?
> 
> 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).
> 
> > So, ENABLE_CHECKING not withstanding, it appears to be a problem
with
> > the optimisation of intervals.c itself.
> > Any other thoughts?
> 
> Not really.  If you can reproduce it without optimizations, 
> 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 Oak, 
Salford Priors, Evesham WR11 8SP. For a list of Misys group operating companies 
please go to http://www.misys.com/html/about_us/group_operating_companies/. 
This email and any attachments have been scanned for known viruses using 
multiple scanners. 
 
We believe that this email and any attachments are virus free, however the 
recipient must take full responsibility for virus checking. This email message 
is intended for the named recipient only. It may be privileged and/or 
confidential. 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 commencement 
of legal relations between you and Misys plc. Please refer to the executed 
contract between you and the relevant member of the Misys group for the 
identity of the contracting party with which you are dealing.