>> 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()... >> >> > > That's an interesting question and the answer might extend to the > splashscreen changes too. > Its platform specific code and on MAC, the thread is created using pthreads > directly and that > thread goes away once splashscreen is done. But its running at the same time > as the VM > is booting up and creating threads and setting their signal masks. So I don't > think you can > guarantee that it won't mess up the masks on the JRE threads if the PNG is > bad. And I'm > also not sure you want to remove error handling from the library either. > So a HIGHLY VISIBLE DO NOT REMOVE comment might be the best you can do here.
I have a better idea: png_default_error is the only place where png_longjmp is called. We could call png_set_error_fn to set up our own error handler (for Mac only), compile with PNG_SETJMP_SUPPORTED unset so it doesn't pull in setjmp/longjmp and our own implementation of the error handler would call _longjmp, which would jump back to where we call setjmp currently. I still think a bad png will cause it to abort() with the code as written today... I could be wrong though. I need to track down a bad png to test with. -DrD-
