On 2016-08-12 12:04, Dmitry Samersoff wrote: > David, > > Updated webrev is: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.04/ > > Windows is absolutely different story that requires significant efforts > to reproduce error conditions and test changes. Also it has nothing to > do with ARMv7. > > So I would prefer to address windows issues separately either as a part > of JDK-8159799 or as a separate CR. > > -Dmitry > > On 2016-08-12 03:24, David Holmes wrote: >> Hi Dmitry, >> >> On 12/08/2016 2:55 AM, Dmitry Samersoff wrote: >>> David, >>> >>> Please see updated webrev. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.03/ >>> >>> I didn't touch windows version because it quite different from *NIX one. >> >> Do we ever see failures on Windows? Is so we should add diagnostics >> there too even if they are different to *NIX. >> >> I would still like to see what file it is working with. We need some >> logging in here: >> >> bool AttachListener::is_init_trigger() { >> if (init_at_startup() || is_initialized()) { >> return false; // initialized at startup or already >> initialized >> } >> char fn[PATH_MAX+1]; >> sprintf(fn, ".attach_pid%d", os::current_process_id()); >> int ret; >> struct stat64 st; >> RESTARTABLE(::stat64(fn, &st), ret); >> if (ret == -1) { >> + log ("failed to find attach file: %s, trying alternate", fn) >> snprintf(fn, sizeof(fn), "%s/.attach_pid%d", >> os::get_temp_directory(), os::current_process_id()); >> RESTARTABLE(::stat64(fn, &st), ret); >> + if (ret == -1) { >> + log("failed to find attach file: %s", fn); >> + } >> } >> >> All failure paths need to show us what it was that failed. >> >> typos: trigerred -> triggered >> >> Thanks, >> David >> >>> -Dmitry >>> >>> On 2016-08-08 02:40, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> On 5/08/2016 7:25 PM, Dmitry Samersoff wrote: >>>>> Everybody, >>>>> >>>>> Please review the fix: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.02/ >>>>> >>>>> Problem: >>>>> Tests fail intermittently because it can't attach to child process, >>>>> these attach failures is hard to debug because attach framework >>>>> doesn't provide enough diagnostic information. >>>>> >>>>> Solution: >>>>> >>>>> a) Increase attach timeout >>>>> b) Slightly change attach loop to save a bit of CPU power. >>>>> c) Add some logging to attach listener. >>>>> >>>>> It's just a first step in this direction. Complete cleanup of attach >>>>> code (remove LinuxThreads support and convert all printing to UL) is >>>>> not >>>>> a goal of this fix - I'll file a separate CR for it. >>>> >>>> I still think you need more logging now to aid in debugging these cases. >>>> In particular we want to be able to verify that the path of the attach >>>> file is what we expect in all cases ie whether we find the .attach_pid >>>> file in cwd or whether we are looking in temp directory, and whether we >>>> ultimately succeed or fail. >>>> >>>> Plus whatever you do now should be done consistently for all platforms. >>>> >>>> Thanks, >>>> David >>>> >>>>> -Dmitry >>>>> >>> >>> > >
-- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
