Re: 23.0.60; Seg fault in xfaces.c at line 6703 (Emacs.app on GNUstep)

[Chris Hall]

On 2008-02-03 10:52:46 -1000 Jason Rumney <jasonr@gnu.org> wrote:

> Chris Hall wrote:
> > I think there are 2 issues here: the presence of the value '0x0' in 
> > a field 
> > meant to contain a pointer to a face_cache struct, and what the 
> > presence of 
> > that value causes to happen.
> >
> > To me it seems that while almost certainly the former is an 
> > Emacs.app 
> > issue, the latter is more likely an Emacs 23.0.60 issue.  I don't 
> > know for 
> > sure, since I'm not an Emacs or Emacs.app hacker.
> >
> > I am aware that sometimes some classes of errors are perhaps best 
> > allowed 
> > to happen and to result in catastrophic failures like segmentation 
> > faults, 
> > but in this case, were this one of my programs I'd probably consider 
> > it a 
> > bug.
>
> If it is a bug to have 0 in that field, why would you hide the bug by 
> avoiding a crash when it is 0?

So it could terminate gracefully while reporting that it had a 0 in 
that field, along with any other available information that might 
prove useful in helping to solve the problem?  Maybe offer to run in 
text mode with that information made available in a buffer with a bug 
report?

I didn't mention anything about 'hiding' it, did I?

With the patch I supplied, at least the user knows there is an issue 
with realizing the default face, rather than SIGSEGV (11).

But of course, and as always, YMMV.

Obviously, the possibility of the default face not being realized was 
anticipated by somebody, and considered serious enough to terminate 
execution -- there was already in place a check for exactly that, and 
the possibility of issuing a message and then deliberately 'erroring 
out' of the program if it hadn't been realized.

> > but in this case,

For whatever reason, there is instead no properly initialized 
'face_cache' struct available, if I am interpreting the '0x0' 
correctly.

AFAIK, the '0x0' is the result of an *un*anticipated case leading to 
the same check.  I don't know, and probably never will, because as I 
mentioned, I am unaware of the larger program execution context, and I 
am time-constrained with respect to learning sufficiently the Emacs 
internals required to make that determination.


Cheers!

Chris Hall