Derby
  1. Derby
  2. DERBY-3898

Blob.setBytes differs between embedded and client driver when the specified length is invalid

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.3.3.0, 10.4.2.0, 10.5.1.1, 10.6.1.0
    • Fix Version/s: 10.7.1.1
    • Component/s: JDBC
    • Labels:
    • Urgency:
      Normal
    • Issue & fix info:
      Newcomer
    • Bug behavior facts:
      Embedded/Client difference

      Description

      Blob.setBytes behaves differently with the embedded driver and the client driver.
      Assume a 1 byte array and a specified length of 2: Blob.setBytes(1, new byte[]

      {0x69}

      , 0, 2)
      Embedded: IndexOutOfBoundsException (from java.io.RandomAccessFile.writeBytes or System.arraycopy)
      Client: succeeds, returns insertion count 1

      The behavior should be made consistent, but what is the correct behavior?

      From the Blob.setBytes JavaDoc:
      "Writes all or part of the given byte array to the BLOB value that this Blob object represents and returns the number of bytes written. Writing starts at position pos in the BLOB value; len bytes from the given byte array are written. The array of bytes will overwrite the existing bytes in the Blob object starting at the position pos. If the end of the Blob value is reached while writing the array of bytes, then the length of the Blob value will be increased to accomodate the extra bytes."

      1. Derby3898.java
        1 kB
        Kathey Marsden
      2. derby-3898-1.patch
        13 kB
        Yun Lee
      3. derby-3898-1.stat
        0.4 kB
        Yun Lee
      4. derby-3898-testcase.patch
        3 kB
        Yun Lee
      5. derby-3898-testcase.stat
        0.1 kB
        Yun Lee
      6. enable-javame.diff
        0.9 kB
        Knut Anders Hatlen
      7. overflow.diff
        2 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Dag H. Wanvik added a comment -

          I would say Embedded is correct, taking System.arraycopy as an example of Java "style" in this
          respect (leniency of "array copy" methods, of which setBytes is an instance).
          Looking at Arrays#fill, it is similarly restrictive.

          Show
          Dag H. Wanvik added a comment - I would say Embedded is correct, taking System.arraycopy as an example of Java "style" in this respect (leniency of "array copy" methods, of which setBytes is an instance). Looking at Arrays#fill, it is similarly restrictive.
          Hide
          Kathey Marsden added a comment -

          I found that DB2 with JCC does not throw an exception. I am curious how other databases behave. I am attaching a program to try in case someone else has access to another db and wants to try.

          Show
          Kathey Marsden added a comment - I found that DB2 with JCC does not throw an exception. I am curious how other databases behave. I am attaching a program to try in case someone else has access to another db and wants to try.
          Hide
          Knut Anders Hatlen added a comment -

          MySQL (Connector/J 5.1.7) throws an IndexOutOfBoundsException.
          PostgreSQL (JDBC4 Driver, Version 8.3-603) succeeds and returns 2 (two bytes are inserted, the extra byte is 0).

          Show
          Knut Anders Hatlen added a comment - MySQL (Connector/J 5.1.7) throws an IndexOutOfBoundsException. PostgreSQL (JDBC4 Driver, Version 8.3-603) succeeds and returns 2 (two bytes are inserted, the extra byte is 0).
          Hide
          Kristian Waagan added a comment -

          Triaged July 3, 2009: Assigned normal urgency. Marked as Newcomer, as I think this is easy to fix once the correct behavior has been determined.

          Show
          Kristian Waagan added a comment - Triaged July 3, 2009: Assigned normal urgency. Marked as Newcomer, as I think this is easy to fix once the correct behavior has been determined.
          Hide
          Kathey Marsden added a comment -

          Changing to normal urgency as comments say that was the intent for triage for 10.5.2

          Show
          Kathey Marsden added a comment - Changing to normal urgency as comments say that was the intent for triage for 10.5.2
          Hide
          Yun Lee added a comment -

          When run org.apache.derbyTesting.functionTests.tests.jdbc4.BlobTest against Revision 962387, I have 7 errors on testFreeandMethodsAfterCallingFree(), testGetBinaryStreamLongLastByte(), testGetBinaryStreamLongDrain(), testSetBytesReturnValueLargeStateChange(), testLockingAfterFree(), testLockingAfterFreeWithRR() and testLockingAfterFreeWithDirtyReads(). They all are in NetworkServer mode, and throw the identifical java.lang.NoSuchMethodError: org.apache.derby.client.net.NetStatem
          entRequest.writeScalarStream(ZZIILjava/io/InputStream;ZI)V.

          exception snippet is below:
          4) testGetBinaryStreamLongLastByte(org.apache.derbyTesting.functionTests.tests.j
          dbc4.BlobTest)java.lang.NoSuchMethodError: org.apache.derby.client.net.NetStatem
          entRequest.writeScalarStream(ZZIILjava/io/InputStream;ZI)V
          at org.apache.derby.client.net.NetStatementRequest.buildEXTDTA(NetStatem
          entRequest.java:983)
          at org.apache.derby.client.net.NetStatementRequest.writeExecute(NetState
          mentRequest.java:152)
          at org.apache.derby.client.net.NetPreparedStatement.writeExecute_(NetPre
          paredStatement.java:178)
          at org.apache.derby.client.am.PreparedStatement.writeExecute(PreparedSta
          tement.java:1787)
          at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStat
          ement.java:2017)
          at org.apache.derby.client.am.PreparedStatement.executeX(PreparedStateme
          nt.java:1580)
          at org.apache.derby.client.am.PreparedStatement.execute(PreparedStatemen
          t.java:1565)
          at org.apache.derbyTesting.functionTests.tests.jdbc4.BlobTest.testGetBin
          aryStreamLongLastByte(BlobTest.java:451)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
          109)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57
          )
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57
          )
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
          at junit.extensions.TestSetup.run(TestSetup.java:27)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57
          )

          But I have found writeScalarStream() method in NetStatementRequest actually. Is it OK on your computor, please?

          Show
          Yun Lee added a comment - When run org.apache.derbyTesting.functionTests.tests.jdbc4.BlobTest against Revision 962387, I have 7 errors on testFreeandMethodsAfterCallingFree(), testGetBinaryStreamLongLastByte(), testGetBinaryStreamLongDrain(), testSetBytesReturnValueLargeStateChange(), testLockingAfterFree(), testLockingAfterFreeWithRR() and testLockingAfterFreeWithDirtyReads(). They all are in NetworkServer mode, and throw the identifical java.lang.NoSuchMethodError: org.apache.derby.client.net.NetStatem entRequest.writeScalarStream(ZZIILjava/io/InputStream;ZI)V. exception snippet is below: 4) testGetBinaryStreamLongLastByte(org.apache.derbyTesting.functionTests.tests.j dbc4.BlobTest)java.lang.NoSuchMethodError: org.apache.derby.client.net.NetStatem entRequest.writeScalarStream(ZZIILjava/io/InputStream;ZI)V at org.apache.derby.client.net.NetStatementRequest.buildEXTDTA(NetStatem entRequest.java:983) at org.apache.derby.client.net.NetStatementRequest.writeExecute(NetState mentRequest.java:152) at org.apache.derby.client.net.NetPreparedStatement.writeExecute_(NetPre paredStatement.java:178) at org.apache.derby.client.am.PreparedStatement.writeExecute(PreparedSta tement.java:1787) at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStat ement.java:2017) at org.apache.derby.client.am.PreparedStatement.executeX(PreparedStateme nt.java:1580) at org.apache.derby.client.am.PreparedStatement.execute(PreparedStatemen t.java:1565) at org.apache.derbyTesting.functionTests.tests.jdbc4.BlobTest.testGetBin aryStreamLongLastByte(BlobTest.java:451) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java: 109) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57 ) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57 ) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:23) at junit.extensions.TestSetup.run(TestSetup.java:27) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57 ) But I have found writeScalarStream() method in NetStatementRequest actually. Is it OK on your computor, please?
          Hide
          Yun Lee added a comment -

          In derby-3898-testcase.patch, I have added 7 test cases in BlobTest.java to test the boundary of setBytes() method, each of them run in both Embed and NetworkServer modes. For the current revision, I get 2 erors and 1 failure. It suggests that there are 3 differences between embedded and client driver, 2 of them are about length, and the third is about offset. In particular, it works like below:

          a.
          public void testSetBytesWithTooLongLength() throws SQLException {
          Blob blob = getConnection().createBlob();

          try{
          blob.setBytes(1, new byte[]

          {0x69}, 0, 2);
          fail("IndexOutOfBoundsException should be thrown out for " +
          "wrong argument for Blob.setBytes()!");
          } catch (IndexOutOfBoundsException e) { assertTrue(true); }
          }
          This is what this issue is talking about. It has been agrred that "Embedded is correct" as it throws a IndexOutOfBoundsException by System.arrayCopy(). However, should it be wrapped into a SQLException with SQLState.BLOB_LENGTH_TOO_LONG to provide exact info.

          b.
          public void testSetBytesWithNonPositiveLength() throws SQLException {
          Blob blob = getConnection().createBlob();

          try{
          blob.setBytes(1, new byte[] {0x69}

          , 0, -1);
          } catch (SQLException sqle)

          { assertSQLState("XJ071", sqle); }

          }
          It passes in NetworkServer mode, but fails in Embed mode by throwing an ArrayIndexOutOfBoundsException. Obviously, in both modes Blob.setByets() has catch the nonpositive length, but it doesn't give a consistent exception. Maybe it's best to also throw out a SQLException. in Embed mode.

          c.
          public void testSetBytesWithInvalidOffset() throws SQLException {
          Blob blob = getConnection().createBlob();

          try {
          blob.setBytes(1, new byte[]

          {0xb}, -1, 1);
          } catch (SQLException sqle) { assertSQLState("XJ078", sqle); }

          try {
          blob.setBytes(1, new byte[] {0xb}

          , 2, 1);
          } catch (SQLException sqle)

          { assertSQLState("XJ078", sqle); }

          try {
          blob.setBytes(1, new byte[] {0xb, 0xe}, Integer.MAX_VALUE, 1);
          } catch (SQLException sqle) { assertSQLState("XJ078", sqle); }

          }
          As b., c. passes in NetworkServer mode, but fails in Embed mode by throwing an ArrayIndexOutOfBoundsException. Obviously, in both modes Blob.setByets() has catch the nonpositive length, but it doesn't give a consistent exception. Maybe it's best to also throw out a SQLException in Embed mode.

          Should we create two new issues for b. and c. and provide the same patch for 3 of them? And welcome to enrich relative test cases before patch available!

          Show
          Yun Lee added a comment - In derby-3898-testcase.patch, I have added 7 test cases in BlobTest.java to test the boundary of setBytes() method, each of them run in both Embed and NetworkServer modes. For the current revision, I get 2 erors and 1 failure. It suggests that there are 3 differences between embedded and client driver, 2 of them are about length, and the third is about offset. In particular, it works like below: a. public void testSetBytesWithTooLongLength() throws SQLException { Blob blob = getConnection().createBlob(); try{ blob.setBytes(1, new byte[] {0x69}, 0, 2); fail("IndexOutOfBoundsException should be thrown out for " + "wrong argument for Blob.setBytes()!"); } catch (IndexOutOfBoundsException e) { assertTrue(true); } } This is what this issue is talking about. It has been agrred that "Embedded is correct" as it throws a IndexOutOfBoundsException by System.arrayCopy(). However, should it be wrapped into a SQLException with SQLState.BLOB_LENGTH_TOO_LONG to provide exact info. b. public void testSetBytesWithNonPositiveLength() throws SQLException { Blob blob = getConnection().createBlob(); try{ blob.setBytes(1, new byte[] {0x69} , 0, -1); } catch (SQLException sqle) { assertSQLState("XJ071", sqle); } } It passes in NetworkServer mode, but fails in Embed mode by throwing an ArrayIndexOutOfBoundsException. Obviously, in both modes Blob.setByets() has catch the nonpositive length, but it doesn't give a consistent exception. Maybe it's best to also throw out a SQLException. in Embed mode. c. public void testSetBytesWithInvalidOffset() throws SQLException { Blob blob = getConnection().createBlob(); try { blob.setBytes(1, new byte[] {0xb}, -1, 1); } catch (SQLException sqle) { assertSQLState("XJ078", sqle); } try { blob.setBytes(1, new byte[] {0xb} , 2, 1); } catch (SQLException sqle) { assertSQLState("XJ078", sqle); } try { blob.setBytes(1, new byte[] {0xb, 0xe}, Integer.MAX_VALUE, 1); } catch (SQLException sqle) { assertSQLState("XJ078", sqle); } } As b., c. passes in NetworkServer mode, but fails in Embed mode by throwing an ArrayIndexOutOfBoundsException. Obviously, in both modes Blob.setByets() has catch the nonpositive length, but it doesn't give a consistent exception. Maybe it's best to also throw out a SQLException in Embed mode. Should we create two new issues for b. and c. and provide the same patch for 3 of them? And welcome to enrich relative test cases before patch available!
          Hide
          Kristian Waagan added a comment -

          Hi Yun,

          I'm really not sure what to say here. Both approaches have merit:
          o ArrayIndexOutOfBounds : well known pattern from Java, may simplify the input validation code in Derby
          o SQLException : follows JDBC pattern, higher chance that the exception will be caught and dealt with

          Since the problem in this case isn't really database related, I'm leaning towards AIOOB (as Dag commented too). Funnily enough, the embedded driver is throwing an SQLException, catching it and then throwing an AIOOB.
          If anyone else has opinions it would be nice if you share them now such that we can allow Yun to continue work on this issue.

          When it comes to the test code, I have the following comments:
          a) I don't see the point of statements like 'assertTrue(true)'. Why not simply add a comment?
          b) For tests like the one below, you should add a fail() statement in case the setBytes-method doesn't throw an exception.

          + try {
          + blob.setBytes(1, new byte[]

          {0xb}

          , -1, 1);
          + } catch (SQLException sqle)

          { + assertSQLState("XJ078", sqle); + }

          c) If the tests don't use any API methods from JDBC 4, we usually add them to jdbcapi instead of jdbc4. That way, the tests are run also when the JDK version is 1.4 or 1.5. Are there any suitable existing test classes in jdbcapi?

          I think the problems you had with NoSuchMethod errors were caused by a bad build. Some times it is good to run 'ant clobber' (or 'ant clobber all buildjars') to recompile all classes.

          Thanks,

          Show
          Kristian Waagan added a comment - Hi Yun, I'm really not sure what to say here. Both approaches have merit: o ArrayIndexOutOfBounds : well known pattern from Java, may simplify the input validation code in Derby o SQLException : follows JDBC pattern, higher chance that the exception will be caught and dealt with Since the problem in this case isn't really database related, I'm leaning towards AIOOB (as Dag commented too). Funnily enough, the embedded driver is throwing an SQLException, catching it and then throwing an AIOOB. If anyone else has opinions it would be nice if you share them now such that we can allow Yun to continue work on this issue. When it comes to the test code, I have the following comments: a) I don't see the point of statements like 'assertTrue(true)'. Why not simply add a comment? b) For tests like the one below, you should add a fail() statement in case the setBytes-method doesn't throw an exception. + try { + blob.setBytes(1, new byte[] {0xb} , -1, 1); + } catch (SQLException sqle) { + assertSQLState("XJ078", sqle); + } c) If the tests don't use any API methods from JDBC 4, we usually add them to jdbcapi instead of jdbc4. That way, the tests are run also when the JDK version is 1.4 or 1.5. Are there any suitable existing test classes in jdbcapi? I think the problems you had with NoSuchMethod errors were caused by a bad build. Some times it is good to run 'ant clobber' (or 'ant clobber all buildjars') to recompile all classes. Thanks,
          Hide
          Yun Lee added a comment -

          Thanks for your comment, Kristian.

          NoSuchMethod errors have dissappeared after clean and rebuild.

          I agree with your opinion on test code, and will provide a new patch for them.

          org.apache.derbyTesting.functionTests.tests.jdbc4.BlobTest is used to test the JDBC 4.0 specific <code>Blob</code> methods, it does be not suitable to place the additional boundary test cases for setBytes(). Is it OK to use the test class org.apache.derbyTesting.functionTests.tests.jdbc4.BlobSetMethodsTest.java? Now BlobSetMethodsTest has only two test case for Blob.setBytes(), and it only uses a JDBC4 specific mothod Connection.createBlob() , maybe BlobSetMethodsTest can be changed to use only JDBC3 API and moved into package org.apache.derbyTesting.functionTests.tests.jdbcapi, and insert additional test cases into it?

          Others' opinions on choice between SQLException and AIOOB is welcome! Thanks!

          Show
          Yun Lee added a comment - Thanks for your comment, Kristian. NoSuchMethod errors have dissappeared after clean and rebuild. I agree with your opinion on test code, and will provide a new patch for them. org.apache.derbyTesting.functionTests.tests.jdbc4.BlobTest is used to test the JDBC 4.0 specific <code>Blob</code> methods, it does be not suitable to place the additional boundary test cases for setBytes(). Is it OK to use the test class org.apache.derbyTesting.functionTests.tests.jdbc4.BlobSetMethodsTest.java? Now BlobSetMethodsTest has only two test case for Blob.setBytes(), and it only uses a JDBC4 specific mothod Connection.createBlob() , maybe BlobSetMethodsTest can be changed to use only JDBC3 API and moved into package org.apache.derbyTesting.functionTests.tests.jdbcapi, and insert additional test cases into it? Others' opinions on choice between SQLException and AIOOB is welcome! Thanks!
          Hide
          Yun Lee added a comment -

          In the new patch, BlobSetBytesBoundaryTest.java has been added to run Boundary tests for Blob.setBytes().

          Overall boundary check has been done in Blob.setBytes() and EmbedBlob.setBytes().Now they can perform accordingly, not only for too big length, but also for offset and pos.

          I have run relative tests, they were all OK. Please check it, thanks!

          Show
          Yun Lee added a comment - In the new patch, BlobSetBytesBoundaryTest.java has been added to run Boundary tests for Blob.setBytes(). Overall boundary check has been done in Blob.setBytes() and EmbedBlob.setBytes().Now they can perform accordingly, not only for too big length, but also for offset and pos. I have run relative tests, they were all OK. Please check it, thanks!
          Hide
          Myrna van Lunteren added a comment -

          switching off patch available - I commetted the latest patch with revision 984472.

          Show
          Myrna van Lunteren added a comment - switching off patch available - I commetted the latest patch with revision 984472.
          Hide
          Myrna van Lunteren added a comment -

          Setting to resolved, but leave this for Kristian (as reporter of the bug) to confirm & close.
          Does this need to get backported?

          Show
          Myrna van Lunteren added a comment - Setting to resolved, but leave this for Kristian (as reporter of the bug) to confirm & close. Does this need to get backported?
          Hide
          Knut Anders Hatlen added a comment -

          One small corner case: The patch checks whether (len + offset > bytes.length) is true to detect if the sum of len and offset exceeds the length of the byte buffer. However, if the sum of len and offset is greater than Integer.MAX_VALUE, (len + offset) will overflow and return a negative result. Since a negative value will not be considered greater than bytes.length, the check will fail to detect that the sum is too big.

          Example that shows the bug:

          blob.setBytes(1, new byte[100], 10, Integer.MAX_VALUE);

          The above statement will fail with an IndexOutOfBoundsException on the embedded driver. On the client driver, no error is raised at all. The expected result is an SQLException.

          I've attached a patch which fixes the problem by changing (len + offset > bytes.length) to (len > bytes.length - offset). Since we know at this point in the code that both bytes.length and offset are non-negative, we also know that (bytes.length - offset) cannot overflow. The patch also adds a test case for the bug.

          Show
          Knut Anders Hatlen added a comment - One small corner case: The patch checks whether (len + offset > bytes.length) is true to detect if the sum of len and offset exceeds the length of the byte buffer. However, if the sum of len and offset is greater than Integer.MAX_VALUE, (len + offset) will overflow and return a negative result. Since a negative value will not be considered greater than bytes.length, the check will fail to detect that the sum is too big. Example that shows the bug: blob.setBytes(1, new byte [100] , 10, Integer.MAX_VALUE); The above statement will fail with an IndexOutOfBoundsException on the embedded driver. On the client driver, no error is raised at all. The expected result is an SQLException. I've attached a patch which fixes the problem by changing (len + offset > bytes.length) to (len > bytes.length - offset). Since we know at this point in the code that both bytes.length and offset are non-negative, we also know that (bytes.length - offset) cannot overflow. The patch also adds a test case for the bug.
          Hide
          Knut Anders Hatlen added a comment -

          All the regression tests ran cleanly with the patch.

          Show
          Knut Anders Hatlen added a comment - All the regression tests ran cleanly with the patch.
          Hide
          Knut Anders Hatlen added a comment -

          One other small issue. BlobSetBytesBoundaryTest was added to the list of tests that are not run on Java ME. I successfully ran the test on phoneME, so I assume that was unintentional. The attached patch (enable-javame.diff) adds the test to the jdbcapi suite also on Java ME. Committed revision 986260.

          Show
          Knut Anders Hatlen added a comment - One other small issue. BlobSetBytesBoundaryTest was added to the list of tests that are not run on Java ME. I successfully ran the test on phoneME, so I assume that was unintentional. The attached patch (enable-javame.diff) adds the test to the jdbcapi suite also on Java ME. Committed revision 986260.
          Hide
          Yun Lee added a comment -

          That's right, thanks, Knut.

          Show
          Yun Lee added a comment - That's right, thanks, Knut.
          Hide
          Knut Anders Hatlen added a comment -

          Committed overflow.diff with revision 986345.

          Show
          Knut Anders Hatlen added a comment - Committed overflow.diff with revision 986345.
          Hide
          Kristian Waagan added a comment -

          As an invalid length must be specified to trigger this difference between the drivers, backporting it is not justified for me.
          If anyone else want to do so, feel free to reopen the issue and do the work.

          Closing issue.

          Show
          Kristian Waagan added a comment - As an invalid length must be specified to trigger this difference between the drivers, backporting it is not justified for me. If anyone else want to do so, feel free to reopen the issue and do the work. Closing issue.

            People

            • Assignee:
              Yun Lee
              Reporter:
              Kristian Waagan
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development