<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 25 aug 2014, at 13:33, Dmitry Samersoff <<a href="mailto:dmitry.samersoff@oracle.com">dmitry.samersoff@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Staffan,<br><br>On 2014-08-25 15:26, Staffan Larsen wrote:<br><blockquote type="cite">Dmitry,<br><br>One problem with this fix is that debugInit_exit() is used from many<br>places in the JDWP code. For some of these I think it still does make<br>sense to receive a core dump for analysis. I agree that when parsing<br>options, we do not need a core dump.<br></blockquote><br>jdwp has explicit option to request a coredump at debugInit_exit().<br><br>Is it enough or I should create a more sophisticated fix ?<br></div></blockquote><div><br></div><div>I don’t think that is enough. Often a problem will happen and will not be reproducible. </div><div><br></div><div>Maybe this code:</div><div><br></div><div> if ((arg.error != JDWP_ERROR(NONE)) &&<br> (arg.startCount == 0) &&<br> initOnStartup) {<br> EXIT_ERROR(map2jvmtiError(arg.error), "No transports initialized");<br> }<br><br></div><div>can use some variant of EXIT_ERROR that does not call fatalError() ?</div><div><br></div><div>/Staffan</div><br><blockquote type="cite"><div style="font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>Actually, I don't think that coredump on every call to jni_FatalError()<br>(see jni.cpp:726) is necessary but this hotspot code is here for 6 years<br>and changing it probably out of scope of this fix.<br><br>-Dmitry<br><br><br><blockquote type="cite"><br>/Staffan<br><br><br>On 20 aug 2014, at 17:55, Dmitry Samersoff<br><<a href="mailto:dmitry.samersoff@oracle.com">dmitry.samersoff@oracle.com</a>> wrote:<br><br><blockquote type="cite">Serguei,<br><br>After some additional testing I changed the fix a bit. Please take<br>a look at new version.<br><br><a href="http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/">http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.02/</a><br><br>New version reports JVMTI error to stderr.<br><br>Also jniFatalError is not referenced any more so I remove it.<br><br>-Dmitry<br><br><br><br>On 2014-08-20 12:08, serguei.spitsyn@oracle.com wrote:<br><blockquote type="cite">Ok.<br><br>Thank you for the explanation! Serguei<br><br>On 8/20/14 1:01 AM, Dmitry Samersoff wrote:<br><blockquote type="cite">Serguei,<br><br>1. Historically JDI test-suite had no tests for failed<br>transport initialization behavior and invalid parameters<br>handling.<br><br>2. As a part of JDWP hardening work I added couple of such<br>tests to OptionTest.java - these tests pass invalid parameters<br>to dt_socket transport to make sure that transport doesn't<br>crash (one such crash was discovered and fixed) but just return<br>non-zero exit code to upper level.<br><br>3. After fix for JDK-6694099 any non-zero exit code from<br>transport cause VM to coredump. Dumping multiple cores on busy<br>machine takes a time so harness kills the test by timeout.<br><br>We can just increase timeout for this test but I don't think<br>it's a good idea to dump core when invalid parameters passed to<br>transport.<br><br>So there is the fix.<br><br>4. After the fix tests for negative parameters will return<br>non-zero exit code as expected but will not dump the core.<br><br>-Dmitry<br><br>On 2014-08-20 00:54, serguei.spitsyn@oracle.com wrote:<br><blockquote type="cite">Hi Dmitry,<br><br>The fix seems to be Ok. Just want to make it clear... This<br>fix just changes the bug pattern. It a case of incorrect<br>transport parameters the test is still going to fail but<br>without crash, right?<br><br>Thanks, Serguei<br><br>On 8/19/14 12:09 PM, Dmitry Samersoff wrote:<br><blockquote type="cite">Hi Everybody,<br><br>Please review the fix:<br><br>http://cr.openjdk.java.net/~dsamersoff/JDK-8049226/webrev.01/<br><br><br><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>JDWP call jniFatalError if transport can't be initialized (e.g. wrong<br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">parameters) and jniFatalError call os::abort(). Therefor<br>all transport initialization errors cause vm to coredump.<br><br>I see no reason for debugInit_exit to call jniFatalError so<br>remove this code.<br><br>-Dmitry<br><br></blockquote></blockquote><br></blockquote><br></blockquote><br><br>-- Dmitry Samersoff Oracle Java development team, Saint Petersburg,<br>Russia * I would love to change the world, but they won't give me<br>the sources.<br></blockquote><br></blockquote><br><br>--<span class="Apple-converted-space"> </span><br>Dmitry Samersoff<br>Oracle Java development team, Saint Petersburg, Russia<br>* I would love to change the world, but they won't give me the sources.</div></blockquote></div><br></body></html>