If we don't want to be here thread safe, simpliest way to prevent crash is just making the function static synchronized.
If we want more complex solution, we can use TLS here as in the first of your suggestions. Second suggestion is even better, but I'm not sure how the OutOfMemoryError will be handled in this case, I need to read the sources. -- Ivan On 11/18/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
I like Ivan's point. As far as I know any Java code shouldn't lead to VM crashes. Imagine the following situation: errors happen in parallel threads. In this case the following static pointer first is populated by means of strdup twice, and then freed twice. static char *errMsg = NULL; The second free() would fail. It won't be easy to understand where the problem is. I believe a very easy fix of storing error message copy in a thread local variable should help. Another possible solution is to create a Java string or even an exception object in the error handler and populate a local JNI reference with it. I believe we can even call throwNewExceptionByName here. This adds a possibility of occasional garbage collection in the error handler, but removes a pain with freeing memory. Ivan, Sergey, Oleg, what do you think? On 11/17/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: > Sergey, > > It is ok to have not thread safe code in AWT implementation which can > work incorrectly in some cases. It is not ok (IMHO) if the incorrect > work leads to VM crash. It can be problem as a security hole. > > -- > Best regards, > Ivan > > On 11/17/06, Sergey Soldatov (JIRA) <[EMAIL PROTECTED]> wrote: > > [ http://issues.apache.org/jira/browse/HARMONY-2100?page=comments#action_12450683 ] > > > > Sergey Soldatov commented on HARMONY-2100: > > ------------------------------------------ > > > > I'm not sure there is any reason to do it, since this functionality is not supposed to be run from several threads. AWT itself is not threadsafe and documentation recommends to make all AWT calls from event dispatch thread. I would keep it as is. > > > > > [classlib] java.awt.color.ICC_ProfileRTest fails > > > ------------------------------------------------ > > > > > > Key: HARMONY-2100 > > > URL: http://issues.apache.org/jira/browse/HARMONY-2100 > > > Project: Harmony > > > Issue Type: Bug > > > Components: Classlib > > > Environment: SUSE 9 > > > debug DRLVM > > > Reporter: Alexey Varlamov > > > Assigned To: Alexey Varlamov > > > Priority: Minor > > > Attachments: harmony-2100.patch, quick_fix.diff > > > > > > > > > The java.awt.color.ICC_ProfileRTest passes on JITs and fails on interpreter: > > > junit.framework.AssertionFailedError: IllegalArgumentExceptione expected > > > at java.awt.color.ICC_ProfileRTest.testGetInstance(ICC_ProfileRTest.java:38) > > > at java.lang.reflect.VMReflection.invokeMethod(VMReflection.java) > > > To reproduce: > > > edit $vm/build/lnx_ia32_gcc_debug/deploy/jre/bin/default/harmonyvm.properties, add "-Xint" line to it; > > > cd $classlib > > > ant -Dtest.jre.home=$vm/build/lnx_ia32_gcc_debug/deploy/jre test -Dtest.case=java.awt.color.ICC_ProfileRTest -Dbuild.module=awt > > > > -- > > This message is automatically generated by JIRA. > > - > > If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa > > - > > For more information on JIRA, see: http://www.atlassian.com/software/jira > > -- > Ivan > Intel Enterprise Solutions Software Division > -- Thank you, Alexei
-- Ivan Intel Enterprise Solutions Software Division
