[Bug: 21.5-b27] Can't move cursor in edit-faces buffer

[Ron Isaacson]

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:

       --with-cppflags=-idirafter/usr/include/wnn

     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
     png_err_stct.setjmp_buffer.

     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
Morgan Stanley
ron.isaacson at 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.