I can confirm that this crash happens rather often. Thank you, Denis.
On 13 Oct 2014, at 11:59, Hendrik Schreiber <h...@tagtraum.com> wrote: > 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. >>> >> >
