Derby
  1. Derby
  2. DERBY-1583

With grant revoke enabled, defining a trigger whose actions updates a table (from different schema) results in NPE

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.2.1.6
    • Fix Version/s: 10.2.2.0, 10.3.1.4
    • Component/s: SQL
    • Labels:
      None
    • Urgency:
      Urgent

      Description

      While working on SQL authorization work, I ran across a test case where Derby will throw a NPE when a trigger is defined with it's action as update a table from another schema. I don't have much details on why but following is the test case. Derby is trying to put privilege requirement for a column into privilege requirements list and it expects the column's tableUUID to be not null but in this particular case, it is null.

      connect 'jdbc:derby:c:/dellater/dbmain;create=true' user 'mamta1' as mamta1;
      create table t11TriggerRevokeTest (c111 int not null primary key, c12 int);
      grant TRIGGER on t11TriggerRevokeTest to mamta2;
      create table t12TriggerRevokeTest (c121 int, c122 int, c123 int);
      grant UPDATE(c122, c121) on t12TriggerRevokeTest to mamta2;
      connect 'jdbc:derby:c:/dellater/dbmain;create=true' user 'mamta2' as mamta2;
      create trigger tr11t11 after insert on mamta1.t11TriggerRevokeTest for each statement mode db2sql
      update mamta1.t12TriggerRevokeTest set c122 = 99;

      The stack trace looks as follows
      ij(MAMTA2)> ERROR XJ001: Java exception: ': java.lang.NullPointerException'.java.lang.NullPointerException
      at org.apache.derby.impl.sql.compile.CompilerContextImpl.addRequiredColumnPriv(CompilerContextImpl.java:741)
      at org.apache.derby.impl.sql.compile.ResultColumn.bindResultColumnByName(ResultColumn.java:682)
      at org.apache.derby.impl.sql.compile.ResultColumnList.bindResultColumnsByName(ResultColumnList.java:635)
      at org.apache.derby.impl.sql.compile.ResultSetNode.bindResultColumns(ResultSetNode.java:682)
      at org.apache.derby.impl.sql.compile.SelectNode.bindResultColumns(SelectNode.java:751)
      at org.apache.derby.impl.sql.compile.UpdateNode.bind(UpdateNode.java:348)
      at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:344)
      at org.apache.derby.impl.sql.GenericStatement.prepareStorable(GenericStatement.java:591)
      at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.compileStatement(SPSDescriptor.java:353)
      at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.prepareAndRelease(SPSDescriptor.java:283)
      at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(CreateTriggerConstantAction.java:367)
      at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(CreateTriggerConstantAction.java:272)
      at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56)
      at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:357)
      at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1181)
      at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:584)
      at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516)
      at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:313)
      at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433)
      at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310)
      at org.apache.derby.impl.tools.ij.Main.go(Main.java:207)
      at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:173)
      at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
      at org.apache.derby.tools.ij.main(ij.java:60)

      1. setTableDescriptor.diff
        3 kB
        Bryan Pendleton
      2. setTableDescriptor.diff
        0.3 kB
        Bryan Pendleton
      3. skipAddPriv_v2.diff
        8 kB
        Bryan Pendleton
      4. skipAddPriv_v3.diff
        9 kB
        Bryan Pendleton
      5. skipAddPriv.diff
        3 kB
        Bryan Pendleton

        Issue Links

          Activity

          Hide
          Yip Ng added a comment -

          Hi Mamta, I also hit this problem with one of my testcases, my first hunch is that Derby is not using the cache for table descriptor that was bound but created a new table descriptor from the system table with unbound info therefore causing the NPE. I think the place to set a breakpoint to verify this is at verifyTargetTable() method of DMLModStatementNode class and see if the targetTableDescriptor return from there is different from the one that got bound. If I recall correctly, Derby only use the cache to get the table descriptor when it is in compilation mode...

          Show
          Yip Ng added a comment - Hi Mamta, I also hit this problem with one of my testcases, my first hunch is that Derby is not using the cache for table descriptor that was bound but created a new table descriptor from the system table with unbound info therefore causing the NPE. I think the place to set a breakpoint to verify this is at verifyTargetTable() method of DMLModStatementNode class and see if the targetTableDescriptor return from there is different from the one that got bound. If I recall correctly, Derby only use the cache to get the table descriptor when it is in compilation mode...
          Hide
          Rick Hillegas added a comment -

          Assigning normal priority.

          Show
          Rick Hillegas added a comment - Assigning normal priority.
          Hide
          Mamta A. Satoor added a comment -

          Bryan Pendleton ran existing test altertable.sql with derby.database.sqlAuthorization=true and the test ran into null pointer exceptions. (email thread can be found at http://www.nabble.com/derby.database.sqlAuthorization-question----usage-error-or-bug--tf2153778.html#a5949205)

          The stack trace of the first null pointer exception encountered by altertable.sql has similar code path as the stack trace encountered by this jira entry and might be related. I thought I would put this information here for someone who might look into this bug.

          Show
          Mamta A. Satoor added a comment - Bryan Pendleton ran existing test altertable.sql with derby.database.sqlAuthorization=true and the test ran into null pointer exceptions. (email thread can be found at http://www.nabble.com/derby.database.sqlAuthorization-question----usage-error-or-bug--tf2153778.html#a5949205 ) The stack trace of the first null pointer exception encountered by altertable.sql has similar code path as the stack trace encountered by this jira entry and might be related. I thought I would put this information here for someone who might look into this bug.
          Hide
          Rick Hillegas added a comment -

          Bumping urgency.

          Show
          Rick Hillegas added a comment - Bumping urgency.
          Hide
          Bryan Pendleton added a comment -

          I attached a possible patch for this as a comment to DERBY-1754.

          Show
          Bryan Pendleton added a comment - I attached a possible patch for this as a comment to DERBY-1754 .
          Hide
          Bryan Pendleton added a comment -

          Attached is setTableDescriptor.diff, a patch proposal with a simple test included.

          The patch is the same idea noted as a comment to DERBY-1754; namely, to
          set the tableDescriptor into the column descriptor when building the column
          descriptor in SYSCOLUMNSRowFactory.

          Please have a look and tell me what you think.

          Show
          Bryan Pendleton added a comment - Attached is setTableDescriptor.diff, a patch proposal with a simple test included. The patch is the same idea noted as a comment to DERBY-1754 ; namely, to set the tableDescriptor into the column descriptor when building the column descriptor in SYSCOLUMNSRowFactory. Please have a look and tell me what you think.
          Hide
          Yip Ng added a comment -

          Hi Bryan:

          The setTableDescriptor.diff only contains the svn stat.

          Show
          Yip Ng added a comment - Hi Bryan: The setTableDescriptor.diff only contains the svn stat.
          Hide
          Yip Ng added a comment -

          I haven't review Bryan's patch in details yet (listed in DERBY-1754) but after the patch is applied, DERBY-1583 (this jira) and DERBY-1724 (which also NPE on addRequiredColumnPriv method), the NullPointerException no longer surfaces.

          Show
          Yip Ng added a comment - I haven't review Bryan's patch in details yet (listed in DERBY-1754 ) but after the patch is applied, DERBY-1583 (this jira) and DERBY-1724 (which also NPE on addRequiredColumnPriv method), the NullPointerException no longer surfaces.
          Hide
          Bryan Pendleton added a comment -

          Sorry about the bad attachment, Yip, thanks for catching it.

          Let's try this again: attaching setTableDescriptor.diff (again), this time with the actual diff.

          Meanwhile, my derbyall run completed, and I did have one failure, so I'll need to
          investigate this to see if it was caused by the patch:

                          • Diff file derbyall/derbylang/update.diff
              • Start: update jdk1.4.2_11 derbyall:derbylang 2006-08-26 14:42:38 ***
                587 del
                < ERROR 42X04: Column 'DERBY10431.A_COL' is either not in any table in the FROM list or appears within a join specification and is outside the scope of the join specification or appears in a HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'DERBY10431.A_COL' is not a column in the target table.
                587a587
                > 1 row inserted/updated/deleted
                Test Failed.
          Show
          Bryan Pendleton added a comment - Sorry about the bad attachment, Yip, thanks for catching it. Let's try this again: attaching setTableDescriptor.diff (again), this time with the actual diff. Meanwhile, my derbyall run completed, and I did have one failure, so I'll need to investigate this to see if it was caused by the patch: Diff file derbyall/derbylang/update.diff Start: update jdk1.4.2_11 derbyall:derbylang 2006-08-26 14:42:38 *** 587 del < ERROR 42X04: Column 'DERBY10431.A_COL' is either not in any table in the FROM list or appears within a join specification and is outside the scope of the join specification or appears in a HAVING clause and is not in the GROUP BY list. If this is a CREATE or ALTER TABLE statement then 'DERBY10431.A_COL' is not a column in the target table. 587a587 > 1 row inserted/updated/deleted Test Failed.
          Hide
          Bryan Pendleton added a comment -

          The update diff looks like a genuine interaction between the patch proposal and
          the checkTableNameAndScrubResultColumns() method of DERBY-1043.
          I'll need to study the DERBY-1043 change to understand how these patches interact.

          Show
          Bryan Pendleton added a comment - The update diff looks like a genuine interaction between the patch proposal and the checkTableNameAndScrubResultColumns() method of DERBY-1043 . I'll need to study the DERBY-1043 change to understand how these patches interact.
          Hide
          Bryan Pendleton added a comment -

          The interaction with the DERBY-1043 change persuades me that the setTableDescriptor.diff
          proposal is incorrect. Specifically, if you look at ResultColumn.getTableName(), it is clear
          that it is perfectly valid for a ColumnDescriptor to have a null tableDescriptor pointer. The
          case exposed by the DERBY-1043 tests involves a column reference in the setClause of
          an update statement, where the ResultColumn contains a ColumnReference, but it also
          contains an expression, and the expression is a separate ColumnReference which
          refers to some particular table; it is the table of the expression that is the most important,
          not the table of the column descriptor itself, since the column's value is to be set with the
          value of the expression.

          Therefore, I shall now pursue a different theory, namely that CompilerContextImpl.
          addRequiredColumnPriv is incorrectly assuming that a ColumnDescriptor will always
          have an underlying TableDescriptor.

          I'll also add a link from DERBY-1724 to this bug, because they look closely related.

          Show
          Bryan Pendleton added a comment - The interaction with the DERBY-1043 change persuades me that the setTableDescriptor.diff proposal is incorrect. Specifically, if you look at ResultColumn.getTableName(), it is clear that it is perfectly valid for a ColumnDescriptor to have a null tableDescriptor pointer. The case exposed by the DERBY-1043 tests involves a column reference in the setClause of an update statement, where the ResultColumn contains a ColumnReference, but it also contains an expression, and the expression is a separate ColumnReference which refers to some particular table; it is the table of the expression that is the most important, not the table of the column descriptor itself, since the column's value is to be set with the value of the expression. Therefore, I shall now pursue a different theory, namely that CompilerContextImpl. addRequiredColumnPriv is incorrectly assuming that a ColumnDescriptor will always have an underlying TableDescriptor. I'll also add a link from DERBY-1724 to this bug, because they look closely related.
          Hide
          Mamta A. Satoor added a comment -

          Bryan, looking at the stack track, it seems that we are trying to add a column privilege requirement in the execute phase of create trigger. When I had first encountered this NPE, I vaguely remember that this same colunm requirement was already added during the compile phase of the trigger and hence we might not need to add any privilege requiement at execute phase. I think you will have todo more research to see if theory is good.

          Show
          Mamta A. Satoor added a comment - Bryan, looking at the stack track, it seems that we are trying to add a column privilege requirement in the execute phase of create trigger. When I had first encountered this NPE, I vaguely remember that this same colunm requirement was already added during the compile phase of the trigger and hence we might not need to add any privilege requiement at execute phase. I think you will have todo more research to see if theory is good.
          Hide
          Bryan Pendleton added a comment -

          Attached is an alternate proposal for a patch to this issue.
          skipAddPriv.diff is based on the idea that if a particular
          ColumnDescriptor has no associated TableDescriptor at the
          time that CompilerContextImpl.addRequiredColumnPriv is
          called, then there is no column privilege that needs to be added.

          This patch passes derbyall, and in particular the update.sql test
          which failed with the previous patch proposal does not fail with
          this patch proposal. Moreover, I successfully tested the DERBY-1754
          test case as well as the test case for this bug (the test case for
          this bug is included in the diff as a new regression test).

          Please have a look at this patch proposal and let me know what you think.

          Show
          Bryan Pendleton added a comment - Attached is an alternate proposal for a patch to this issue. skipAddPriv.diff is based on the idea that if a particular ColumnDescriptor has no associated TableDescriptor at the time that CompilerContextImpl.addRequiredColumnPriv is called, then there is no column privilege that needs to be added. This patch passes derbyall, and in particular the update.sql test which failed with the previous patch proposal does not fail with this patch proposal. Moreover, I successfully tested the DERBY-1754 test case as well as the test case for this bug (the test case for this bug is included in the diff as a new regression test). Please have a look at this patch proposal and let me know what you think.
          Hide
          Mamta A. Satoor added a comment -

          Bryan, the patch looks good to me. Just couple minor comments
          1)Can you please put a comment for if (td == nulll) check in CompilerContextImpl.addRequiredColumnPriv which says when this if condition will be true and may be reference to this jira entry in that comment?
          2)Also, in the new test case for create trigger with update as trigger action, can you add couple dmls which demonstrates that the trigger gets fired and does what it is expected to do? Then revoke one of the required privileges to show that trigger gets dropped and some dmls after that which will show that the trigger doesn't fire anymore.

          Thanks for working on this issue

          Show
          Mamta A. Satoor added a comment - Bryan, the patch looks good to me. Just couple minor comments 1)Can you please put a comment for if (td == nulll) check in CompilerContextImpl.addRequiredColumnPriv which says when this if condition will be true and may be reference to this jira entry in that comment? 2)Also, in the new test case for create trigger with update as trigger action, can you add couple dmls which demonstrates that the trigger gets fired and does what it is expected to do? Then revoke one of the required privileges to show that trigger gets dropped and some dmls after that which will show that the trigger doesn't fire anymore. Thanks for working on this issue
          Hide
          Bryan Pendleton added a comment -

          Thanks, Mamta! These are good ideas. I will submit a revised patch.

          Show
          Bryan Pendleton added a comment - Thanks, Mamta! These are good ideas. I will submit a revised patch.
          Hide
          Bryan Pendleton added a comment -

          Attached is skipAddPriv_v2.diff. This patch proposal includes
          improved comments in the code, as well as additional tests.
          The grantRevokeDDL test is enhanced as Mamta suggested,
          to verify that the trigger is operating as we expect it to, and to
          verify that it is revoked as we expect. Also, the test case from
          DERBY-1754 is included as part of this patch proposal.

          derbyall passes with this patch.

          Please let me know your reactions on this patch.

          Show
          Bryan Pendleton added a comment - Attached is skipAddPriv_v2.diff. This patch proposal includes improved comments in the code, as well as additional tests. The grantRevokeDDL test is enhanced as Mamta suggested, to verify that the trigger is operating as we expect it to, and to verify that it is revoked as we expect. Also, the test case from DERBY-1754 is included as part of this patch proposal. derbyall passes with this patch. Please let me know your reactions on this patch.
          Hide
          Mamta A. Satoor added a comment -

          Bryan, thanks for taking care of my comments. I will take a look at the new patch later tonight.

          I wondered though if you could try your patch with the test case attached to DERBY-1724. DERBY-1724 runs into NPE when grant is in a transaction. The NPE is in the same method where you added the null check for tabledescriptor and your check might fix DERBY-1724.
          I haven't researched into that bug and hence don't know why the NPE manifests itself only inside a transaction.

          Show
          Mamta A. Satoor added a comment - Bryan, thanks for taking care of my comments. I will take a look at the new patch later tonight. I wondered though if you could try your patch with the test case attached to DERBY-1724 . DERBY-1724 runs into NPE when grant is in a transaction. The NPE is in the same method where you added the null check for tabledescriptor and your check might fix DERBY-1724 . I haven't researched into that bug and hence don't know why the NPE manifests itself only inside a transaction.
          Hide
          Bryan Pendleton added a comment -

          I will have a look at DERBY-1724.

          Show
          Bryan Pendleton added a comment - I will have a look at DERBY-1724 .
          Hide
          Bryan Pendleton added a comment -

          Mamta, thanks for the suggestion about DERBY-1724.
          I think it is definitely another manifestation of the same bug.

          Attached is skipAddPriv_v3.diff, which includes the DERBY-1724
          test case as part of the grantRevokeDDL.sql tests.

          I ran the DERBY-1724 test case interactively, and without the
          patch I get the NPE, and with the patch I get reasonable results.

          So I think that we can mark DERBY-1724 as a duplicate of this
          bug, assuming that we decide to proceed with this patch.

          Reviewers, please review skipAddPriv_v3.diff instead of the v2 patch.

          Show
          Bryan Pendleton added a comment - Mamta, thanks for the suggestion about DERBY-1724 . I think it is definitely another manifestation of the same bug. Attached is skipAddPriv_v3.diff, which includes the DERBY-1724 test case as part of the grantRevokeDDL.sql tests. I ran the DERBY-1724 test case interactively, and without the patch I get the NPE, and with the patch I get reasonable results. So I think that we can mark DERBY-1724 as a duplicate of this bug, assuming that we decide to proceed with this patch. Reviewers, please review skipAddPriv_v3.diff instead of the v2 patch.
          Hide
          Mamta A. Satoor added a comment -

          I reviewed the patch skipAddPriv_v3.diff and looks like it should do the trick and take care of following 3 NPE bugs
          1)This particular jira entry
          2)DERBY-1754 sqlAuthorization mode causes Null Pointer Exception during ALTER TABLE
          3)DERBY-1724 Executing grant statement within a transaction leads to a NPE later when the db owner attempts to update a table

          If derbyall has run with no new failures, then I think this patch is good to go. Thanks for taking this on, Bryan.

          Show
          Mamta A. Satoor added a comment - I reviewed the patch skipAddPriv_v3.diff and looks like it should do the trick and take care of following 3 NPE bugs 1)This particular jira entry 2) DERBY-1754 sqlAuthorization mode causes Null Pointer Exception during ALTER TABLE 3) DERBY-1724 Executing grant statement within a transaction leads to a NPE later when the db owner attempts to update a table If derbyall has run with no new failures, then I think this patch is good to go. Thanks for taking this on, Bryan.
          Hide
          Yip Ng added a comment -

          Mamta, just curious, why did the NPE occurs in transaction mode in DERBY-1724 but not in autocommit mode?

          Show
          Yip Ng added a comment - Mamta, just curious, why did the NPE occurs in transaction mode in DERBY-1724 but not in autocommit mode?
          Hide
          Mamta A. Satoor added a comment -

          Yip, I haven't debugged DERBY-1724 yet to know why NPE is only in transaction mode.

          Show
          Mamta A. Satoor added a comment - Yip, I haven't debugged DERBY-1724 yet to know why NPE is only in transaction mode.
          Hide
          Bryan Pendleton added a comment -

          Thanks Mamta and Yip for the review! I will try to figure out why the DERBY-1724
          NPE is related to transaction handling. I probably won't get to this until this weekend.
          If anybody else figures this out in the meantime, please let us know!

          Show
          Bryan Pendleton added a comment - Thanks Mamta and Yip for the review! I will try to figure out why the DERBY-1724 NPE is related to transaction handling. I probably won't get to this until this weekend. If anybody else figures this out in the meantime, please let us know!
          Hide
          Mike Matrigali added a comment -

          I ran a successful run of a full set of tests on XP, sun1.42 jvm. Committed change to trunk.

          m3_142:174>svn commit

          Sending java\engine\org\apache\derby\impl\sql\compile\CompilerContextImpl.java
          Sending java\testing\org\apache\derbyTesting\functionTests\master\altertable.out
          Sending java\testing\org\apache\derbyTesting\functionTests\master\grantRevokeDDL.out
          Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\altertable_derby.properties
          Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\grantRevokeDDL.sql
          Transmitting file data .....
          Committed revision 438942.

          Show
          Mike Matrigali added a comment - I ran a successful run of a full set of tests on XP, sun1.42 jvm. Committed change to trunk. m3_142:174>svn commit Sending java\engine\org\apache\derby\impl\sql\compile\CompilerContextImpl.java Sending java\testing\org\apache\derbyTesting\functionTests\master\altertable.out Sending java\testing\org\apache\derbyTesting\functionTests\master\grantRevokeDDL.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\altertable_derby.properties Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\grantRevokeDDL.sql Transmitting file data ..... Committed revision 438942.
          Hide
          Bryan Pendleton added a comment -

          I'm becoming increasingly convinced that the DERBY-1724 behavior is related to whether
          the DataDictionary cache is in DDL mode or in COMPILE mode. This is coupled
          with the fact that ColumnDescriptor objects in the dictionary cache don't have a
          table descriptor field when they are first loaded; the table descriptor value gets set
          by FromBaseTable.genResultColList. So if a data dictionary cache mode switch
          occurs, which has the side effect of clearing the cache, and then addRequiredColumnPriv
          comes along but there has been no intervening call to FBT.genResultColList, the
          ColumnDescriptor's TableDescriptor will be null, leading to the NPE.

          I'll try to work up a more clear and coherent description of all of this processing; this is
          just some rough notes to record what I think I see in the heat of debugging...

          Show
          Bryan Pendleton added a comment - I'm becoming increasingly convinced that the DERBY-1724 behavior is related to whether the DataDictionary cache is in DDL mode or in COMPILE mode. This is coupled with the fact that ColumnDescriptor objects in the dictionary cache don't have a table descriptor field when they are first loaded; the table descriptor value gets set by FromBaseTable.genResultColList. So if a data dictionary cache mode switch occurs, which has the side effect of clearing the cache, and then addRequiredColumnPriv comes along but there has been no intervening call to FBT.genResultColList, the ColumnDescriptor's TableDescriptor will be null, leading to the NPE. I'll try to work up a more clear and coherent description of all of this processing; this is just some rough notes to record what I think I see in the heat of debugging...
          Hide
          Bryan Pendleton added a comment -

          I've tried to expand upon the rough notes above in the wiki, at
          http://wiki.apache.org/db-derby/DataDictionary
          and
          http://wiki.apache.org/db-derby/DataDictionaryCaching

          Please help by correcting any mistakes in those notes and expanding on any unclear sections.

          I've satisfied myself that DERBY-1724 is a duplicate of this bug and that the importance of
          the transaction handling in the DERBY-1724 repro is indeed that it disables the DataDictionary
          cache and hence makes it easier to hit the conditions for this bug.

          I am intending to merge the revision 438942 change (skipAddPriv_v3.diff) to the 10.2 branch today.

          Thanks again to everybody for their continued help on this bug!

          Show
          Bryan Pendleton added a comment - I've tried to expand upon the rough notes above in the wiki, at http://wiki.apache.org/db-derby/DataDictionary and http://wiki.apache.org/db-derby/DataDictionaryCaching Please help by correcting any mistakes in those notes and expanding on any unclear sections. I've satisfied myself that DERBY-1724 is a duplicate of this bug and that the importance of the transaction handling in the DERBY-1724 repro is indeed that it disables the DataDictionary cache and hence makes it easier to hit the conditions for this bug. I am intending to merge the revision 438942 change (skipAddPriv_v3.diff) to the 10.2 branch today. Thanks again to everybody for their continued help on this bug!
          Hide
          Bryan Pendleton added a comment -

          Merged the fix to the 10.2 branch and marked the bug as resolved.

          Thanks Mamta and Yip for the reviews; thanks Mike for reviewing and committing to the trunk!

          Show
          Bryan Pendleton added a comment - Merged the fix to the 10.2 branch and marked the bug as resolved. Thanks Mamta and Yip for the reviews; thanks Mike for reviewing and committing to the trunk!
          Hide
          Andrew McIntyre added a comment -

          This issue has been resolved for over a year with no further movement. Closing.

          Show
          Andrew McIntyre added a comment - This issue has been resolved for over a year with no further movement. Closing.

            People

            • Assignee:
              Bryan Pendleton
              Reporter:
              Mamta A. Satoor
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development