> The JPEG code is 2d not awt .. I was curious about that.
> Apparently the root of this problem is > > - longjmp will restore the signal mask using sigprocmask() which sets the > > signal mask for the _process_. > > Hmm .. so anyone using a JNI lib that uses setjmp/longjmp would have the same > issue. > Any place in the OS X libraries that end up using it would do the same ... > So I don't see how we can do a guaranteed fix here without knowing that. I don't see how we can guarantee anything when it comes to third party JNI code. > The change here :- > http://cr.openjdk.java.net/~ddehaven/8026385/jdk.0/src/share/native/sun/awt/libpng/png.h.sdiff.html > > is to an upstream libpng and will likely get lost when libpng is next updated. > At the very least you will need to put some JDk specific comments here so its > blindlingly obvious when some one updates it that they are removing our > customisation. > > Alternatively, (and maybe better) is there any place that libpng looks for > any customisations you need to do ? I tried not modifying libpng but still ended up with lingering references to longjmp in pngread.o, despite libpng having png_ptr->longjmp_fn (bug in libpng?). pngread.c calls setjmp to set a default location to jump to in case the caller doesn't call setjmp, so if we continue down this path something in libpng must be modified. The only other option is to create our own setjmp.h and order it before /usr/include/setjmp.h, which seems dubious at best. I'm curious if the libpng changes are even needed since it's only used for splashscreen, which happens very early in the launch process. Also note that we didn't originally even call png_set_longjmp_fn, so any error should have resulted in an abort() instead of a call to longjmp... it appears we could retain the functionality we have today and #undef PNG_SETJMP_SUPPORTED (pngconf.h?). That would put the onus on developers to make sure their pngs don't have errors in them, or libsplashscreen will abort()... > is > > ifdef __APPLE__ > > something that we (JDK) define or the OS X compiler defines ? > ie if we asked to push this upstream would they want something different ? __APPLE__ is defined by all compilers provided by Apple (gcc, clang, I think it even pre-dates Mac OS X). > Of course I have no idea if 'upstream' would want our behaviour anyway .. I have my doubts. -DrD-
