1180 2015-07-24 15:41:45 +0200 Buffers.newDirectIntBuffer(int[]) does not set limit 2015-09-27 01:30:11 +0200 1 1 3 JogAmp Gluegen core 2.3.2 All all RESOLVED INVALID --- normal --- 0 johan sgothel --- gluegen ce9187bbbf62389fc7897a87f36952cdd23674f6 gluegen c7ecc12a3b9281360e2121f02e9985be3b680f7f gluegen c7edf7debd03ac688fca32d91b4f98f21de2a7af jogl 8e1f5fc43ba84d5e6373f0c29089ac32b7ce95dd --- oldest_to_newest 4801 0 johan 2015-07-24 15:41:45 +0200 Discussion here http://forum.jogamp.org/Buffers-newDirectIntBuffer-int-does-not-set-limit-td4034959.html Details reproduced from the forum here: I noticed that Buffers.newDirectIntBuffer(int[]) does not set the limit of the buffer. This causes a driver crash on OSX. When using this form: final IntBuffer indexBuf = Buffers.newDirectIntBuffer(triIndexes); This is the trace output when I upload the data to the driver: glBindBuffer(<int> 0x8893, <int> 0x3) glBufferData(<int> 0x8893, <long> 0, <java.nio.Buffer> java.nio.DirectIntBufferU[pos=0 lim=0 cap=89034], <int> 0x88E4) and finally the driver crashes when it is time to render: glDrawElements(<int> 0x4, <int> 0x15BCA, <int> 0x1405, <long> 0)# # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x000000010fd4b3b0, pid=1443, tid=31031 # # JRE version: Java(TM) SE Runtime Environment (8.0-b132) (build 1.8.0-b132) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b70 mixed mode bsd-amd64 compressed oops) # Problematic frame: # C [libsystem_platform.dylib+0x13b0] _platform_memmove$VARIANT$Nehalem+0x70 But if I do this: final IntBuffer indexBuf = Buffers.newDirectIntBuffer(triIndexes.length); for (int triIndex : triIndexes) { indexBuf.put(triIndex) ; } The trace for uploading the buffer is this: glBindBuffer(<int> 0x8893, <int> 0x3) glBufferData(<int> 0x8893, <long> 356136, <java.nio.Buffer> java.nio.DirectIntBufferU[pos=0 lim=89034 cap=89034], <int> 0x88E4) Notice the limit is set to the number of ints I put into the buffer and now the driver does not crash. 4802 1 johan 2015-07-24 15:46:08 +0200 In the forum Xerxes suggested using niobuffer#clear() instead of rewind. Maybe flip() is more appropriate in this case. Anyway, the forum has a patch from Xerxes that I currently can not test since I haven't set up to build gluegen. 4803 2 708 xerxes 2015-07-24 16:52:47 +0200 Created attachment 708 gluegen-rewind-to-clear.patch I took a quick look and wrote a proposed "fix". By replacing the use of NIO Buffer rewind with clear. gluegen-rewind-to-clear.patch Please test! All gluegen junit.run tests pass on my machine with the patch applied. Using clear sounds counter intuitive but the java doc confirm that it is the right thing to do. http://docs.oracle.com/javase/7/docs/api/java/nio/Buffer.html#clear%28%29 "public final Buffer clear() Clears this buffer. The position is set to zero, the limit is set to the capacity, and the mark is discarded. Invoke this method before using a sequence of channel-read or put operations to fill this buffer. For example: buf.clear(); // Prepare buffer for reading in.read(buf); // Read data This method does not actually erase the data in the buffer, but it is named as if it did because it will most often be used in situations in which that might as well be the case." 4804 3 709 xerxes 2015-07-24 18:56:12 +0200 Created attachment 709 junit-Test-Buffers-positionLimitCapacityAfterArrayAllocation.patch junit test to check that position limit and capacity is set as intended after Buffers.newDirect*Buffer(*[]) allocation. 4805 4 sgothel 2015-07-24 19:02:01 +0200 (In reply to comment #2) > Created attachment 708 [details] > gluegen-rewind-to-clear.patch > > I took a quick look and wrote a proposed "fix". By replacing the use of NIO > Buffer rewind with clear. ByteBuffer.asIntBuffer(): The new buffer's position will be zero, its capacity and its limit will be the number of bytes remaining in this buffer divided by four, and its mark will be undefined. For all the array NIO Buffer create method in Buffers, we do as: 'ByteBuffer' -> as<Type>() -> nativeOrder -> 'fill data' -> rewind() The limit/capacity shall be handled by 'as<Type>()', see above. Hence the patch shall not be required. +++ Further, we need to see how the 'limit' gets broken and why (and how) it is used in our glBufferData(..) ? Quite weird .. 4806 5 johan 2015-07-24 19:43:09 +0200 I am pressed for time so can not make a test case for several days. However I strongly suspect the reason for the driver crash is my code. I do this: gl.glBindBuffer(GL4.GL_ELEMENT_ARRAY_BUFFER, this.vbos[bufferIndex]); final int bufferSizeInBytes = values.remaining() * Buffers.SIZEOF_INT; gl.glBufferData(GL4.GL_ELEMENT_ARRAY_BUFFER, bufferSizeInBytes, values, GL4.GL_STATIC_DRAW); Notice that I use 'remaining()' to see how much data is in the buffer. Remaining is the difference between limit-position. So my code assumes that the buffer is at position 0 and limit is set to the number of elements in the buffer. When limit is 0 that is probably the reason for breaking the driver. However, I would assume (maybe falsely) that: Buffers.newDirectIntBuffer(int[]) would be equivalent to allocating a buffer and then 'put' all the data from the array i.e. limit should be the number of elements in the array. So that I can flip() the buffer and be ready to read from it. 4807 6 sgothel 2015-07-24 22:02:42 +0200 (In reply to comment #3) > Created attachment 709 [details] > junit-Test-Buffers-positionLimitCapacityAfterArrayAllocation.patch > > junit test to check that position limit and capacity is set as intended > after Buffers.newDirect*Buffer(*[]) allocation. Your git patch has been merged. Minor nagging: Please use 'Bug 1180' instead of any other notation in you git commit message and elsewhere, otherwise we have a hard time to find related pieces of code. 4808 7 sgothel 2015-07-24 22:04:54 +0200 (In reply to comment #5) > I am pressed for time so can not make a test case for several days. However > I strongly suspect the reason for the driver crash is my code. I do this: > > > gl.glBindBuffer(GL4.GL_ELEMENT_ARRAY_BUFFER, this.vbos[bufferIndex]); > final int bufferSizeInBytes = values.remaining() * Buffers.SIZEOF_INT; > gl.glBufferData(GL4.GL_ELEMENT_ARRAY_BUFFER, bufferSizeInBytes, values, > GL4.GL_STATIC_DRAW); > > > Notice that I use 'remaining()' to see how much data is in the buffer. > Remaining is the difference between limit-position. So my code assumes that > the buffer is at position 0 and limit is set to the number of elements in > the buffer. When limit is 0 that is probably the reason for breaking the > driver. Thank you ... I will attempt to make a unit test. > > However, I would assume (maybe falsely) that: > Buffers.newDirectIntBuffer(int[]) would be equivalent to allocating a buffer > and then 'put' all the data from the array i.e. limit should be the number > of elements in the array. So that I can flip() the buffer and be ready to > read from it. Yes .. limit shall be equal to capacity. A unit test for Buffers in this regard has been added to GlueGen: ce9187bbbf62389fc7897a87f36952cdd23674f6 c7ecc12a3b9281360e2121f02e9985be3b680f7f 4809 8 sgothel 2015-07-24 22:53:06 +0200 gluegen c7edf7debd03ac688fca32d91b4f98f21de2a7af: Add test for remaining() jogl 8e1f5fc43ba84d5e6373f0c29089ac32b7ce95dd: Refine TestMapBufferRead01NEWT, add TestMapBufferRead02NEWT: Add assertion checks and latter test uses FloatBuffer .. so far, everything passes 4812 9 johan 2015-07-25 09:29:33 +0200 The problem was that I assumed position to be set so that the buffer should be flipped before reading from it. This is not the case: public class BuffersTest { @Test public void testFlipReadOnExplicitlyPutBuffer() { IntBuffer explicit = Buffers.newDirectIntBuffer(3); explicit.put(1) ; explicit.put(2) ; explicit.put(3) ; explicit.flip() ; assertTrue(explicit.get() == 1) ; assertTrue(explicit.get() == 2) ; assertTrue(explicit.get() == 3) ; } @Test public void testFlipReadOnArrayCreatedBuffer() { IntBuffer implicit = Buffers.newDirectIntBuffer(new int[] {1,2,3}); implicit.flip() ; assertTrue(implicit.get() == 1) ; assertTrue(implicit.get() == 2) ; assertTrue(implicit.get() == 3) ; } } I don't think this is a bug, more like I made the wrong assumption about how the Buffers class worked. Will close this issue if I can. 4815 10 sgothel 2015-07-25 14:38:42 +0200 Indeed, the Buffers method acts as if flip() has already being called, i.e. pos=0 and limit=capacity=array.lenght. Hence this bug report is invalid, not 'fixed'. Thank you. We may want to consider to add API documentation about the state of created buffers, i.e. pos, limit and capacity. 708 2015-07-24 16:52:47 +0200 2015-07-24 16:52:47 +0200 gluegen-rewind-to-clear.patch gluegen-rewind-to-clear.patch text/plain 3397 xerxes ZGlmZiAtLWdpdCBhL3NyYy9qYXZhL2NvbS9qb2dhbXAvY29tbW9uL25pby9CdWZmZXJzLmphdmEg Yi9zcmMvamF2YS9jb20vam9nYW1wL2NvbW1vbi9uaW8vQnVmZmVycy5qYXZhCmluZGV4IGFhZTJi ZTguLmRmMGMxNjQgMTAwNjQ0Ci0tLSBhL3NyYy9qYXZhL2NvbS9qb2dhbXAvY29tbW9uL25pby9C dWZmZXJzLmphdmEKKysrIGIvc3JjL2phdmEvY29tL2pvZ2FtcC9jb21tb24vbmlvL0J1ZmZlcnMu amF2YQpAQCAtODAsNyArODAsNyBAQCBwdWJsaWMgY2xhc3MgQnVmZmVycyB7CiAgICAgfQogCiAg ICAgcHVibGljIHN0YXRpYyBCeXRlQnVmZmVyIG5ld0RpcmVjdEJ5dGVCdWZmZXIoZmluYWwgYnl0 ZVtdIHZhbHVlcywgZmluYWwgaW50IG9mZnNldCwgZmluYWwgaW50IGxlbmd0aCkgewotICAgICAg ICByZXR1cm4gKEJ5dGVCdWZmZXIpbmV3RGlyZWN0Qnl0ZUJ1ZmZlcihsZW5ndGgpLnB1dCh2YWx1 ZXMsIG9mZnNldCwgbGVuZ3RoKS5yZXdpbmQoKTsKKyAgICAgICAgcmV0dXJuIChCeXRlQnVmZmVy KW5ld0RpcmVjdEJ5dGVCdWZmZXIobGVuZ3RoKS5wdXQodmFsdWVzLCBvZmZzZXQsIGxlbmd0aCku Y2xlYXIoKTsKICAgICB9CiAKICAgICBwdWJsaWMgc3RhdGljIEJ5dGVCdWZmZXIgbmV3RGlyZWN0 Qnl0ZUJ1ZmZlcihmaW5hbCBieXRlW10gdmFsdWVzLCBmaW5hbCBpbnQgb2Zmc2V0KSB7CkBAIC0x MDEsNyArMTAxLDcgQEAgcHVibGljIGNsYXNzIEJ1ZmZlcnMgewogICAgIH0KIAogICAgIHB1Ymxp YyBzdGF0aWMgRG91YmxlQnVmZmVyIG5ld0RpcmVjdERvdWJsZUJ1ZmZlcihmaW5hbCBkb3VibGVb XSB2YWx1ZXMsIGZpbmFsIGludCBvZmZzZXQsIGZpbmFsIGludCBsZW5ndGgpIHsKLSAgICAgICAg cmV0dXJuIChEb3VibGVCdWZmZXIpbmV3RGlyZWN0RG91YmxlQnVmZmVyKGxlbmd0aCkucHV0KHZh bHVlcywgb2Zmc2V0LCBsZW5ndGgpLnJld2luZCgpOworICAgICAgICByZXR1cm4gKERvdWJsZUJ1 ZmZlciluZXdEaXJlY3REb3VibGVCdWZmZXIobGVuZ3RoKS5wdXQodmFsdWVzLCBvZmZzZXQsIGxl bmd0aCkuY2xlYXIoKTsKICAgICB9CiAKICAgICBwdWJsaWMgc3RhdGljIERvdWJsZUJ1ZmZlciBu ZXdEaXJlY3REb3VibGVCdWZmZXIoZmluYWwgZG91YmxlW10gdmFsdWVzLCBmaW5hbCBpbnQgb2Zm c2V0KSB7CkBAIC0xMjIsNyArMTIyLDcgQEAgcHVibGljIGNsYXNzIEJ1ZmZlcnMgewogICAgIH0K IAogICAgIHB1YmxpYyBzdGF0aWMgRmxvYXRCdWZmZXIgbmV3RGlyZWN0RmxvYXRCdWZmZXIoZmlu YWwgZmxvYXRbXSB2YWx1ZXMsIGZpbmFsIGludCBvZmZzZXQsIGZpbmFsIGludCBsZW5ndGgpIHsK LSAgICAgICAgcmV0dXJuIChGbG9hdEJ1ZmZlciluZXdEaXJlY3RGbG9hdEJ1ZmZlcihsZW5ndGgp LnB1dCh2YWx1ZXMsIG9mZnNldCwgbGVuZ3RoKS5yZXdpbmQoKTsKKyAgICAgICAgcmV0dXJuIChG bG9hdEJ1ZmZlciluZXdEaXJlY3RGbG9hdEJ1ZmZlcihsZW5ndGgpLnB1dCh2YWx1ZXMsIG9mZnNl dCwgbGVuZ3RoKS5jbGVhcigpOwogICAgIH0KIAogICAgIHB1YmxpYyBzdGF0aWMgRmxvYXRCdWZm ZXIgbmV3RGlyZWN0RmxvYXRCdWZmZXIoZmluYWwgZmxvYXRbXSB2YWx1ZXMsIGZpbmFsIGludCBv ZmZzZXQpIHsKQEAgLTE0Myw3ICsxNDMsNyBAQCBwdWJsaWMgY2xhc3MgQnVmZmVycyB7CiAgICAg fQogCiAgICAgcHVibGljIHN0YXRpYyBJbnRCdWZmZXIgbmV3RGlyZWN0SW50QnVmZmVyKGZpbmFs IGludFtdIHZhbHVlcywgZmluYWwgaW50IG9mZnNldCwgZmluYWwgaW50IGxlbmd0aCkgewotICAg ICAgICByZXR1cm4gKEludEJ1ZmZlciluZXdEaXJlY3RJbnRCdWZmZXIobGVuZ3RoKS5wdXQodmFs dWVzLCBvZmZzZXQsIGxlbmd0aCkucmV3aW5kKCk7CisgICAgICAgIHJldHVybiAoSW50QnVmZmVy KW5ld0RpcmVjdEludEJ1ZmZlcihsZW5ndGgpLnB1dCh2YWx1ZXMsIG9mZnNldCwgbGVuZ3RoKS5j bGVhcigpOwogICAgIH0KIAogICAgIHB1YmxpYyBzdGF0aWMgSW50QnVmZmVyIG5ld0RpcmVjdElu dEJ1ZmZlcihmaW5hbCBpbnRbXSB2YWx1ZXMsIGZpbmFsIGludCBvZmZzZXQpIHsKQEAgLTE2NCw3 ICsxNjQsNyBAQCBwdWJsaWMgY2xhc3MgQnVmZmVycyB7CiAgICAgfQogCiAgICAgcHVibGljIHN0 YXRpYyBMb25nQnVmZmVyIG5ld0RpcmVjdExvbmdCdWZmZXIoZmluYWwgbG9uZ1tdIHZhbHVlcywg ZmluYWwgaW50IG9mZnNldCwgZmluYWwgaW50IGxlbmd0aCkgewotICAgICAgICByZXR1cm4gKExv bmdCdWZmZXIpbmV3RGlyZWN0TG9uZ0J1ZmZlcihsZW5ndGgpLnB1dCh2YWx1ZXMsIG9mZnNldCwg bGVuZ3RoKS5yZXdpbmQoKTsKKyAgICAgICAgcmV0dXJuIChMb25nQnVmZmVyKW5ld0RpcmVjdExv bmdCdWZmZXIobGVuZ3RoKS5wdXQodmFsdWVzLCBvZmZzZXQsIGxlbmd0aCkuY2xlYXIoKTsKICAg ICB9CiAKICAgICBwdWJsaWMgc3RhdGljIExvbmdCdWZmZXIgbmV3RGlyZWN0TG9uZ0J1ZmZlcihm aW5hbCBsb25nW10gdmFsdWVzLCBmaW5hbCBpbnQgb2Zmc2V0KSB7CkBAIC0xODUsNyArMTg1LDcg QEAgcHVibGljIGNsYXNzIEJ1ZmZlcnMgewogICAgIH0KIAogICAgIHB1YmxpYyBzdGF0aWMgU2hv cnRCdWZmZXIgbmV3RGlyZWN0U2hvcnRCdWZmZXIoZmluYWwgc2hvcnRbXSB2YWx1ZXMsIGZpbmFs IGludCBvZmZzZXQsIGZpbmFsIGludCBsZW5ndGgpIHsKLSAgICAgICAgcmV0dXJuIChTaG9ydEJ1 ZmZlciluZXdEaXJlY3RTaG9ydEJ1ZmZlcihsZW5ndGgpLnB1dCh2YWx1ZXMsIG9mZnNldCwgbGVu Z3RoKS5yZXdpbmQoKTsKKyAgICAgICAgcmV0dXJuIChTaG9ydEJ1ZmZlciluZXdEaXJlY3RTaG9y dEJ1ZmZlcihsZW5ndGgpLnB1dCh2YWx1ZXMsIG9mZnNldCwgbGVuZ3RoKS5jbGVhcigpOwogICAg IH0KIAogICAgIHB1YmxpYyBzdGF0aWMgU2hvcnRCdWZmZXIgbmV3RGlyZWN0U2hvcnRCdWZmZXIo ZmluYWwgc2hvcnRbXSB2YWx1ZXMsIGZpbmFsIGludCBvZmZzZXQpIHsKQEAgLTIwNiw3ICsyMDYs NyBAQCBwdWJsaWMgY2xhc3MgQnVmZmVycyB7CiAgICAgfQogCiAgICAgcHVibGljIHN0YXRpYyBD aGFyQnVmZmVyIG5ld0RpcmVjdENoYXJCdWZmZXIoZmluYWwgY2hhcltdIHZhbHVlcywgZmluYWwg aW50IG9mZnNldCwgZmluYWwgaW50IGxlbmd0aCkgewotICAgICAgICByZXR1cm4gKENoYXJCdWZm ZXIpbmV3RGlyZWN0Q2hhckJ1ZmZlcihsZW5ndGgpLnB1dCh2YWx1ZXMsIG9mZnNldCwgbGVuZ3Ro KS5yZXdpbmQoKTsKKyAgICAgICAgcmV0dXJuIChDaGFyQnVmZmVyKW5ld0RpcmVjdENoYXJCdWZm ZXIobGVuZ3RoKS5wdXQodmFsdWVzLCBvZmZzZXQsIGxlbmd0aCkuY2xlYXIoKTsKICAgICB9CiAK ICAgICBwdWJsaWMgc3RhdGljIENoYXJCdWZmZXIgbmV3RGlyZWN0Q2hhckJ1ZmZlcihmaW5hbCBj aGFyW10gdmFsdWVzLCBmaW5hbCBpbnQgb2Zmc2V0KSB7Cg== 709 2015-07-24 18:56:12 +0200 2015-07-24 18:56:12 +0200 junit-Test-Buffers-positionLimitCapacityAfterArrayAllocation.patch junit-Test-Buffers-positionLimitCapacityAfterArrayAllocation.patch text/plain 3048 xerxes ZGlmZiAtLWdpdCBhL3NyYy9qdW5pdC9jb20vam9nYW1wL2NvbW1vbi9uaW8vQnVmZmVyc1Rlc3Qu amF2YSBiL3NyYy9qdW5pdC9jb20vam9nYW1wL2NvbW1vbi9uaW8vQnVmZmVyc1Rlc3QuamF2YQpp bmRleCBjNmE4OWYxLi43MTc0MDE1IDEwMDY0NAotLS0gYS9zcmMvanVuaXQvY29tL2pvZ2FtcC9j b21tb24vbmlvL0J1ZmZlcnNUZXN0LmphdmEKKysrIGIvc3JjL2p1bml0L2NvbS9qb2dhbXAvY29t bW9uL25pby9CdWZmZXJzVGVzdC5qYXZhCkBAIC0zMSw3ICszMSwxNCBAQAogICovCiBwYWNrYWdl IGNvbS5qb2dhbXAuY29tbW9uLm5pbzsKIAoraW1wb3J0IGphdmEubmlvLkJ5dGVCdWZmZXI7Citp bXBvcnQgamF2YS5uaW8uQ2hhckJ1ZmZlcjsKK2ltcG9ydCBqYXZhLm5pby5Eb3VibGVCdWZmZXI7 CitpbXBvcnQgamF2YS5uaW8uRmxvYXRCdWZmZXI7CiBpbXBvcnQgamF2YS5uaW8uSW50QnVmZmVy OworaW1wb3J0IGphdmEubmlvLkxvbmdCdWZmZXI7CitpbXBvcnQgamF2YS5uaW8uU2hvcnRCdWZm ZXI7CisKIGltcG9ydCBvcmcuanVuaXQuVGVzdDsKIAogaW1wb3J0IGNvbS5qb2dhbXAuanVuaXQu dXRpbC5TaW5nbGV0b25KdW5pdENhc2U7CkBAIC00OCw2ICs1NSw1NiBAQCBpbXBvcnQgb3JnLmp1 bml0LnJ1bm5lcnMuTWV0aG9kU29ydGVyczsKIHB1YmxpYyBjbGFzcyBCdWZmZXJzVGVzdCBleHRl bmRzIFNpbmdsZXRvbkp1bml0Q2FzZSB7CiAKICAgICBAVGVzdAorICAgIHB1YmxpYyB2b2lkIHBv c2l0aW9uTGltaXRDYXBhY2l0eUFmdGVyQXJyYXlBbGxvY2F0aW9uKCkgeworICAgICAgICBieXRl W10gYnl0ZURhdGEgPSB7IDEsIDIsIDMsIDQsIDUsIDYsIDcsIDggfTsKKyAgICAgICAgZmluYWwg Qnl0ZUJ1ZmZlciBieXRlQnVmZmVyID0gQnVmZmVycy5uZXdEaXJlY3RCeXRlQnVmZmVyKGJ5dGVE YXRhKTsKKyAgICAgICAgYXNzZXJ0RXF1YWxzKDAsIGJ5dGVCdWZmZXIucG9zaXRpb24oKSk7Cisg ICAgICAgIGFzc2VydEVxdWFscyg4LCBieXRlQnVmZmVyLmxpbWl0KCkpOworICAgICAgICBhc3Nl cnRFcXVhbHMoOCwgYnl0ZUJ1ZmZlci5jYXBhY2l0eSgpKTsKKyAgICAgICAgYXNzZXJ0RXF1YWxz KDUsIGJ5dGVCdWZmZXIuZ2V0KDQpKTsKKworICAgICAgICBkb3VibGVbXSBkb3VibGVEYXRhID0g eyAxLCAyIH07CisgICAgICAgIGZpbmFsIERvdWJsZUJ1ZmZlciBkb3VibGVCdWZmZXIgPSBCdWZm ZXJzLm5ld0RpcmVjdERvdWJsZUJ1ZmZlcihkb3VibGVEYXRhKTsKKyAgICAgICAgYXNzZXJ0RXF1 YWxzKDAsIGRvdWJsZUJ1ZmZlci5wb3NpdGlvbigpKTsKKyAgICAgICAgYXNzZXJ0RXF1YWxzKDIs IGRvdWJsZUJ1ZmZlci5saW1pdCgpKTsKKyAgICAgICAgYXNzZXJ0RXF1YWxzKDIsIGRvdWJsZUJ1 ZmZlci5jYXBhY2l0eSgpKTsKKworICAgICAgICBmbG9hdFtdIGZsb2F0RGF0YSA9IHsgMS4wZiwg Mi4wZiwgMy4wZiB9OworICAgICAgICBmaW5hbCBGbG9hdEJ1ZmZlciBmbG9hdEJ1ZmZlciA9IEJ1 ZmZlcnMubmV3RGlyZWN0RmxvYXRCdWZmZXIoZmxvYXREYXRhKTsKKyAgICAgICAgYXNzZXJ0RXF1 YWxzKDAsIGZsb2F0QnVmZmVyLnBvc2l0aW9uKCkpOworICAgICAgICBhc3NlcnRFcXVhbHMoMywg ZmxvYXRCdWZmZXIubGltaXQoKSk7CisgICAgICAgIGFzc2VydEVxdWFscygzLCBmbG9hdEJ1ZmZl ci5jYXBhY2l0eSgpKTsKKworICAgICAgICBpbnRbXSBpbnREYXRhID0geyAxLCAyLCAzLCA0IH07 CisgICAgICAgIGZpbmFsIEludEJ1ZmZlciBpbnRCdWZmZXIgPSBCdWZmZXJzLm5ld0RpcmVjdElu dEJ1ZmZlcihpbnREYXRhKTsKKyAgICAgICAgYXNzZXJ0RXF1YWxzKDAsIGludEJ1ZmZlci5wb3Np dGlvbigpKTsKKyAgICAgICAgYXNzZXJ0RXF1YWxzKDQsIGludEJ1ZmZlci5saW1pdCgpKTsKKyAg ICAgICAgYXNzZXJ0RXF1YWxzKDQsIGludEJ1ZmZlci5jYXBhY2l0eSgpKTsKKyAgICAgICAgYXNz ZXJ0RXF1YWxzKDMsIGludEJ1ZmZlci5nZXQoMikpOworCisgICAgICAgIGxvbmdbXSBsb25nRGF0 YSA9IHsgMSwgMiwgMywgNCwgNSB9OworICAgICAgICBmaW5hbCBMb25nQnVmZmVyIGxvbmdCdWZm ZXIgPSBCdWZmZXJzLm5ld0RpcmVjdExvbmdCdWZmZXIobG9uZ0RhdGEpOworICAgICAgICBhc3Nl cnRFcXVhbHMoMCwgbG9uZ0J1ZmZlci5wb3NpdGlvbigpKTsKKyAgICAgICAgYXNzZXJ0RXF1YWxz KDUsIGxvbmdCdWZmZXIubGltaXQoKSk7CisgICAgICAgIGFzc2VydEVxdWFscyg1LCBsb25nQnVm ZmVyLmNhcGFjaXR5KCkpOworICAgICAgICBhc3NlcnRFcXVhbHMoNCwgbG9uZ0J1ZmZlci5nZXQo MykpOworCisgICAgICAgIHNob3J0W10gc2hvcnREYXRhID0geyAxLCAyLCAzLCA0LCA1LCA2IH07 CisgICAgICAgIGZpbmFsIFNob3J0QnVmZmVyIHNob3J0QnVmZmVyID0gQnVmZmVycy5uZXdEaXJl Y3RTaG9ydEJ1ZmZlcihzaG9ydERhdGEpOworICAgICAgICBhc3NlcnRFcXVhbHMoMCwgc2hvcnRC dWZmZXIucG9zaXRpb24oKSk7CisgICAgICAgIGFzc2VydEVxdWFscyg2LCBzaG9ydEJ1ZmZlci5s aW1pdCgpKTsKKyAgICAgICAgYXNzZXJ0RXF1YWxzKDYsIHNob3J0QnVmZmVyLmNhcGFjaXR5KCkp OworICAgICAgICBhc3NlcnRFcXVhbHMoNCwgc2hvcnRCdWZmZXIuZ2V0KDMpKTsKKworICAgICAg ICBjaGFyW10gY2hhckRhdGEgPSB7IDEsIDIsIDMsIDQsIDUsIDYsIDcgfTsKKyAgICAgICAgZmlu YWwgQ2hhckJ1ZmZlciBjaGFyQnVmZmVyID0gQnVmZmVycy5uZXdEaXJlY3RDaGFyQnVmZmVyKGNo YXJEYXRhKTsKKyAgICAgICAgYXNzZXJ0RXF1YWxzKDAsIGNoYXJCdWZmZXIucG9zaXRpb24oKSk7 CisgICAgICAgIGFzc2VydEVxdWFscyg3LCBjaGFyQnVmZmVyLmxpbWl0KCkpOworICAgICAgICBh c3NlcnRFcXVhbHMoNywgY2hhckJ1ZmZlci5jYXBhY2l0eSgpKTsKKyAgICAgICAgYXNzZXJ0RXF1 YWxzKDYsIGNoYXJCdWZmZXIuZ2V0KDUpKTsKKyAgICB9CisKKyAgICBAVGVzdAogICAgIHB1Ymxp YyB2b2lkIHNsaWNlKCkgewogCiAgICAgICAgIGZpbmFsIEludEJ1ZmZlciBidWZmZXIgPSBCdWZm ZXJzLm5ld0RpcmVjdEludEJ1ZmZlcig2KTsK