[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chris Hall
Subject: Re: 23.0.60; Seg fault in xfaces.c at line 6703 (Emacs.app on GNUstep)
Date: Sun, 03 Feb 2008 17:20:25 -1000
User-agent: GNUMail (Version 1.2.0)

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.


Chris Hall

reply via email to

[Prev in Thread] Current Thread [Next in Thread]