Hey, I know it's only prio 4 in the database. But since Denis already found this "good" and it's a tiny fix, can someone with reviewer status please spend the 10 minutes and check this out?
I (and real customers) would very much appreciate it! Thank you. -hendrik On Oct 1, 2014, at 17:03, Hendrik Schreiber <h...@tagtraum.com> wrote: > Thanks for the endorsement, Denis. > Much appreciated! > > -hendrik > > On Oct 1, 2014, at 13:19, Denis Fokin <denis.fo...@gmail.com> wrote: > >> Hi Hendrick, >> >> I am not a reviewer, but the fix looks good to me. >> >> Thank you, >> Denis. >> >> On 22 Sep 2014, at 12:19, Hendrik Schreiber <h...@tagtraum.com> wrote: >> >>> Hi, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8057830 >>> >>> On OS X, CGLGraphicsConfigInfo is destroyed by >>> OGLGC_DestroyOGLGraphicsConfig, however the pointer to it still hangs >>> around for a while and is not reset to NULL, until we get rid of it with a >>> Disposer later on. >>> >>> In the meantime it appears to be possible that OGLSD_SetScratchSurface is >>> called with the already destroyed CGLGraphicsConfigInfo as argument. The >>> CGLGraphicsConfigInfo is not NULL, but its structs are in a bad state, most >>> likely freed, leading to the observed crash. >>> >>> The suggested change does not solve the problem, of needing to NULL the >>> pointer to CGLGraphicsConfigInfo right where it's destroyed in >>> OGLRenderQueue.c (not really possible IMO). However, it improves the >>> destruction by NULLing some of it struct members and thus allowing us in >>> OGLSD_SetScratchSurface to test those for NULL values. I also added a trace >>> call for when this happens, to aiding potentially creating a better fix in >>> the future. >>> >>> Unfortunately, I have not been able to come up with a reasonable unit test >>> for this, therefore I cannot be certain that it solves the problem. >>> However, as the changes are minimal and obviously harmless, I would very >>> much appreciate it, if somebody decided to sponsor and commit this patch. I >>> have a live application out there based on 8u20 and this is the number one >>> reason for user-reported crashes. >>> >>> Webrev: https://www.beatunes.com/download/webrev_8057830.zip >>> >>> I did a full clean OS X build to test the change. Before and after I >>> encountered the same 11 jdk_2d failures (which made me wonder whether that >>> is normal...). >>> >>> Cheers, >>> >>> -hendrik >>> >>> PS: I'm new to contributing OpenJDK patches, let me know, if I should have >>> done it some other way. Thanks. >> >
