Ron Isaacson wrote:
> > I know I should be using customize-face instead,
> > but that dumps core when xft is enabled.
> Can't reproduce that. Please make sure to include a C back trace, and
> please turn error-checking on.
Actually, it dumps core whether or not xft is enabled. I built with
all error checking and assertions, but didn't see anything. I'm having
trouble getting a backtrace out of the core file; once I get help from
one of my gdb-guru colleagues, I'll send a detailed report. Thanks!
Ok, got some more details on this. The coredump was completely
unusable, but gdb helped narrow it down to two problems which
converged with unfortunate results:
1. We build most software with minimal dependencies on /usr/lib, so
it works across OS releases. For example, libpng comes from a
central location, and we have a build wrapper that sets CPPFLAGS
to include -I/our/path/to/libpng, and also -L and -Wl,-rpath.
In our args to xemacs's configure, we also use:
along with lots of other craziness to get wnn to work correctly.
Unfortunately, --with-cppflags REPLACES the contents of the
inherited CPPFLAGS, instead of appending to it. So we end up
without our central include paths in CPPFLAGS at compile-time,
and we pick up lots of header files from /usr, while getting the
matching libs from our central location at build-time & runtime.
2. Because of the above, at runtime, png_create_read_struct
(glyphs-eimage.c:875) throws an error ("Incompatible libpng
version in application and library"). This gets passed to the
error handler, png_ptr->error_fn, which points to png_error_func
(glyphs-eimage.c:821). This function, in turn, does a longjmp to
The problem is that the setjmp_buffer in the png_err_stct lexical
struct isn't set until line 902. This is inside png_instantiate,
but not until AFTER the call to png_create_read_struct, which is
the function that throws the error! So at the time png_error_func
gets called, setjmp_buffer contains 0. This explains why the
corefile has no usable stack trace.
You might argue that #1 is our problem, and that if you specify
--with-cppflags, that's an override to the default behavior of
inheriting CPPFLAGS. We've got an easy workaround for that, but it
still might be something to consider.
#2 is definitely not our problem. :-) I think you need to ensure that
png_err_stct.setjmp_buffer is set to a valid address BEFORE passing
png_error_func as a parameter to anything. Otherwise, any runtime
error from png_create_read_struct will get you into the same boat.
ron.isaacson(a)morganstanley.com / (212) 276-0268
NOTICE: If received in error, please destroy and notify sender. Sender
does not waive confidentiality or privilege, and use is prohibited.
XEmacs-Beta mailing list