[OpenJDK 2D-Dev] <AWT Dev> Request for review: 8026385: [macosx] (awt) setjmp/longjmp changes the process signal mask on OS X

Phil Race philip.race at oracle.com
Tue May 13 20:32:19 UTC 2014


On 5/13/2014 1:13 PM, David DeHaven wrote:
>
> 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.

-phil.



More information about the 2d-dev mailing list