Harmony
  1. Harmony
  2. HARMONY-2100

[classlib] java.awt.color.ICC_ProfileRTest fails

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Classlib
    • Labels:
      None
    • Environment:
      SUSE 9
      debug DRLVM
    • Patch Info:
      Patch Available

      Description

      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

      1. harmony-2100.patch
        2 kB
        Oleg Khaschansky
      2. quick_fix.diff
        0.9 kB
        Ivan Volosyuk

        Activity

        Hide
        Alexey Varlamov added a comment -

        Applied harmony-2100.patch at r476162.

        Show
        Alexey Varlamov added a comment - Applied harmony-2100.patch at r476162.
        Hide
        Sergey Soldatov added a comment -

        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.

        Show
        Sergey Soldatov added a comment - 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.
        Hide
        Ivan Volosyuk added a comment -

        If the implementation is not thread safe, let's mark the method in Java as synchronized with corresponding comment. Thus we can detect possible problem more efficiently instead of having hard to reproduce crashes.

        Show
        Ivan Volosyuk added a comment - If the implementation is not thread safe, let's mark the method in Java as synchronized with corresponding comment. Thus we can detect possible problem more efficiently instead of having hard to reproduce crashes.
        Hide
        Oleg Khaschansky added a comment -

        Thanks Alexey, Ivan. Here's a new patch for this issue, a bit more complete. Regarding thread safety - it is not explicitely stated in the API specification that this code should be thread safe, but if you have a simple solution in mind your suggestions are welcome!

        Show
        Oleg Khaschansky added a comment - Thanks Alexey, Ivan. Here's a new patch for this issue, a bit more complete. Regarding thread safety - it is not explicitely stated in the API specification that this code should be thread safe, but if you have a simple solution in mind your suggestions are welcome!
        Hide
        Alexei Fedotov added a comment -

        Cool! Interpreter proved itself to be useful again.

        Show
        Alexei Fedotov added a comment - Cool! Interpreter proved itself to be useful again.
        Hide
        Gregory Shimansky added a comment -

        It looks like this issue is actually in classlib. Changing summary and component.

        Show
        Gregory Shimansky added a comment - It looks like this issue is actually in classlib. Changing summary and component.
        Hide
        Ivan Volosyuk added a comment -

        Quick fix for the problem. Fixed use of dangling stack pointers. Code still not thread safe.

        Show
        Ivan Volosyuk added a comment - Quick fix for the problem. Fixed use of dangling stack pointers. Code still not thread safe.
        Hide
        Ivan Volosyuk added a comment -

        The problem is in NativeCMM.c

        Function gl_cmsErrorHandler() stores string pointer allocated on stack into static variable. As interpreter uses more stack for method execution this place gets overwritten before it is used. Moreover, the code is not thread-safe.

        Show
        Ivan Volosyuk added a comment - The problem is in NativeCMM.c Function gl_cmsErrorHandler() stores string pointer allocated on stack into static variable. As interpreter uses more stack for method execution this place gets overwritten before it is used. Moreover, the code is not thread-safe.
        Hide
        Ivan Volosyuk added a comment -

        Fails on suse9

        Show
        Ivan Volosyuk added a comment - Fails on suse9
        Hide
        Ivan Volosyuk added a comment -

        Bug doesn't reproducible on Fedora5

        Show
        Ivan Volosyuk added a comment - Bug doesn't reproducible on Fedora5

          People

          • Assignee:
            Alexey Varlamov
            Reporter:
            Alexey Varlamov
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development