Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4893893

Valid object references are being randomly set back to null



    • Type: Bug
    • Status: Closed
    • Priority: P2
    • Resolution: Duplicate
    • Affects Version/s: 1.4.1_02
    • Fix Version/s: None
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • CPU:
    • OS:


      See also bug 4884022
      To reproduce follow the steps in 4884022. You will see random failures of the search
      engine with j2se 1.4.1_x but it appears to work with 1.4.2. Here are some notes from 4884022

      I have reproduced this much more reliably on my machine, mwr.
      I'm sure it's a jvm bug. It happens with
      1.4.1_01-b01 and 1.4.1_02-b06
      but the good news is that
      1.4.2-b28 (current)
      seems to fix it (can't be 100% sure though...)

      I heard there was a push for 1.4.2 in Orion. I'm afraid we will have
      on-going nasty problems unles we upgrade the jvm.

      What's happening is extremely disturbing. I have an object
      which starts off life as non-null and then, sooner or later it
      becomes null. It is non-deterministic (I'm guessing garbage
      collection related).

      Blah s = new Blah();
      use s for a while
      suddenly s is null. Oh dear...
      I can reproduce this easily on the older jvms.

      The Portal Server source code is in ps/search/src/com/sun/portal/search/db/NovaResultSet.java.
      At around line 384 we have this code....

      SOIF s = null;
      try {
      AAA s = getDb().fetch(getSToken(), dbkeyval, dbview, 0, getTransaction());
      catch (RDMException e) {
      CSLog.error(1, 1, "Exception when reading db: ", e);
      BBB if (s == null) {
      CSLog.error(1, 1, "Search hit not found in db: " + dbkeyval);
      return null; // XXX - exception?

      if (doHighlights) {
      String[] highlightTags = new String[6];
      String[] fldHighlightTags = new String[6];
      System.arraycopy(hltags, 0, highlightTags, 0, 6);
      System.arraycopy(hltags, 6, fldHighlightTags, 0, 6);
      buildHighlightInfo(hit, s, view,
      highlightTags, defaultPassageContext, defaultPassageSize, defaultMaxPassages,
      fldHighlightTags, defaultFldPassageContext, defaultFldPassageSize, defaultFldMaxPassages,
                  // remove non-view attrs since we had to fetch the whole RD from the db to highlight it
                  for (Iterator it = s.keySet().iterator(); it.hasNext(); ) {
                      if (!view.contains(it.next()))

      // XXX it may be better to only return the score if requested
      if (view == null || view.contains("score"))
      CCC s.replace("score", "" + Math.round((hit.getScore()*100.0f)));

      return s;

      At point A an object, s is created.
      At point B s is tested for null.
      At point C s is randomly null, despite not being null at B.
      I have other scenarios which are more easy to test fot that this which require running multiple searches in parallel (perhaps that just speeds up the failure - threading issues are not necessarily implicated)

      The allocation of s is associated with parsing a SleepyCat db record. This record is returned by a JNI call to C. The allocation and initialisation of s is entirely in Java however.

      ###@###.### 2003-07-21


          Issue Links



              Unassigned Unassigned
              duke J. Duke (Inactive)
              0 Vote for this issue
              0 Start watching this issue