1183 2015-07-27 14:28:25 +0200 NullPointerException at jogamp.newt.driver.x11.ScreenDriver.collectNativeMonitorModesAndDevicesImpl(ScreenDriver.java:124) upon startup 2015-09-27 01:29:46 +0200 1 1 3 JogAmp Newt x11 2.3.2 embedded_arm all RESOLVED FIXED --- normal --- 1 gottfried.haider sgothel gottfried.haider xerxes xerxes --- jogl 4ff4f735c421ef343a8c447fa699c01444bd5e9b jogl 217d8b78a3d70d9be59d4537c7565118dfe1e277 jogl a213c39fa9d741d519df56bc4d4abb86113985f4 --- oldest_to_newest 4822 0 gottfried.haider 2015-07-27 14:28:25 +0200 Using Eric Anholt's vc4 mesa driver on the Raspberry Pi with jogl 2.3.1 and Xerxes' fixes on top, I am often receiving the following NullPointerException upon startup of a Processing sketch that used the 3D renderer: java.lang.NullPointerException, at jogamp.newt.driver.x11.ScreenDriver.collectNativeMonitorModesAndDevicesImpl(ScreenDriver.java:124), at jogamp.newt.ScreenImpl.collectNativeMonitorModes(ScreenImpl.java:630), at jogamp.newt.ScreenImpl.initMonitorState(ScreenImpl.java:566), at jogamp.newt.ScreenImpl.createNative(ScreenImpl.java:196), at jogamp.newt.ScreenImpl.addReference(ScreenImpl.java:235), at processing.opengl.PSurfaceJOGL.initScreen(PSurfaceJOGL.java:126), at processing.opengl.PSurfaceJOGL.initFrame(PSurfaceJOGL.java:105), at processing.core.PApplet.initSurface(PApplet.java:10243), at processing.core.PApplet.runSketch(PApplet.java:10129) at processing.core.PApplet.main(PApplet.java:9898) Any hint as to how to debug this further would be greatly appreciated. Thanks gohai 4827 1 xerxes 2015-07-28 00:02:03 +0200 I recall i have seen this exception and remember it to be caused because the static initialization of GraphicsConfigurationFactory.initSingleton(); has not yet been run. In most JOGL applications GraphicsConfigurationFactory.initSingleton(); is triggered during the NativeWindowFactory static block before you create a NewtWindow. Processing 3 codebase initializes the NEWT Screen early before reaching the line when it create the Newt Window. https://github.com/processing/processing/blob/master/core/src/processing/opengl/PSurfaceJOGL.java#L100-L123 I will try reproduce the bug and check if i can remedy it by placing a GraphicsConfigurationFactory.initSingleton(); inside the X11 ScreenDriver static block since the ScreenDriver depend on that GraphicsConfigurationFactory has been initialized. 4830 2 xerxes 2015-07-28 00:38:58 +0200 If you are running on a raspberry pi system with both the /opt/vc driver and the /usr/lib/... mesa3d driver present then GraphicsConfigurationFactory.initSingleton() will skip to register X11 because it think it is on a bcm.vc.iv system. http://jogamp.org/git/?p=jogl.git;a=blob;f=src/nativewindow/classes/com/jogamp/nativewindow/GraphicsConfigurationFactory.java;hb=HEAD#l121 A workaround to allow your program to create both X11 and bcm.vc.iv newt window at the same time is to run the following code early in your program. GraphicsConfigurationFactory.initSingleton() try { ReflectionUtil.callStaticMethod("jogamp.nativewindow.x11.X11GraphicsConfigurationFactory", "registerFactory", null, null, GraphicsConfigurationFactory.class.getClassLoader()); } catch (final Exception e) { throw new RuntimeException(e); } 4832 3 xerxes 2015-07-28 02:38:30 +0200 I can reproduce this bug using the 20150726-1747-vc4-image.zip system image from http://sukzessiv.net/~gohai/vc4-buildbot/build/ when running the YellowTail processing 3 demo with the X11 mesa3d driver installed and without the /opt/vc driver. It do not trigger all the time. If I re-run the demo then it launches fine. The thesis in comment #2 that both the /opt/vc and /usr/lib mesa3d has to be installed at the same time to trigger this bug is not true. We need to ensure the static initialization order as suggested in comment #1 and as discussed in jogamp irc: http://jogamp.org/log/irc/jogamp_20150727135426.html#l74 4833 4 gottfried.haider 2015-07-28 12:52:50 +0200 This seems to happens less frequently for me on http://sukzessiv.net/~gohai/vc4-buildbot/build/20150727-1947-vc4-image.zip, which has a recent snapshot of JOGL, but it still happens. The Processing demo that made it trigger two out of three tries for me with this build was: Demos/Tests/SpecsTest. Thanks for looking into this! 4836 5 sgothel 2015-07-28 14:17:01 +0200 "Xerxes' fixes on top", referring to Xerxes WIP regarding Bug 1178. 4856 6 gottfried.haider 2015-07-29 10:56:57 +0200 Sorry for not being specific enough.. I was referring to the JavaEmitter's JVMUtil_NewDirectByteBufferCopy one. Also seeing this with autobuild from July 25. 4868 7 sgothel 2015-08-04 15:30:24 +0200 This crash is confined to the Raspi ARM? This crash is confined to Eric's 'alpha' OpenGL driver? 4870 8 sgothel 2015-08-04 15:34:05 +0200 (In reply to comment #7) > This crash is confined to the Raspi ARM? > This crash is confined to Eric's 'alpha' OpenGL driver? If I digg through these issues, I need to know a reliable recipe for reproduction ofc .. It would be nice, if this can be reproduced w/ our unit tests or a new unit test! Same for Bug 1185. 4871 9 715 xerxes 2015-08-05 10:57:04 +0200 Created attachment 715 TestInitScreen.java The attached test-program TestInitScreen.java can reproduce this bug in about one of three runs using a RaspberryPi 1 b+ (the "old" one using an armv6 cpu) Steps to reproduce: Boot the pi to X11, I was using Eric Anholts experimental X11 glamor driver when I managed to reproduce this. javac -cp jogamp-fat.jar:. TestInitScreen.java java -cp jogamp-fat.jar:. TestInitScreen Output: pi@raspberrypi ~/2.3.2 $ java -cp jogamp-fat.jar:. TestInitScreen Exception in thread "main" java.lang.NullPointerException at jogamp.newt.driver.x11.ScreenDriver.collectNativeMonitorModesAndDevicesImpl(ScreenDriver.java:124) at jogamp.newt.ScreenImpl.collectNativeMonitorModes(ScreenImpl.java:630) at jogamp.newt.ScreenImpl.initMonitorState(ScreenImpl.java:566) at jogamp.newt.ScreenImpl.createNative(ScreenImpl.java:196) at jogamp.newt.ScreenImpl.addReference(ScreenImpl.java:235) at TestInitScreen.testInitScreenBug1183(TestInitScreen.java:42) at TestInitScreen.main(TestInitScreen.java:46) X11Util.Display: Shutdown (JVM shutdown: true, open (no close attempt): 1/1, reusable (open, marked uncloseable): 0, pending (open in creation order): 1) X11Util: Open X11 Display Connections: 1 X11Util: Open[0]: NamedX11Display[:0.0, 0xb61d20, refCount 1, unCloseable false] 4872 10 xerxes 2015-08-05 11:24:02 +0200 (In reply to comment #7) > This crash is confined to the Raspi ARM? > This crash is confined to Eric's 'alpha' OpenGL driver? It can be reproduced with both the "regular" framebuffer X11 driver found on the default Raspbian system and by using Eric Anholt's glamour X11 driver. It is *very* easy to reproduce this bug using the "regular" X11 framebuffer driver + mesa3d software rasterizer using a Raspbian system if you disable the bcm.vc.iv driver by moving the /opt/vc to /opt/vc.off and then run the test program: javac -cp jogamp-fat.jar:. TestInitScreen.java java -cp jogamp-fat.jar:. TestInitScreen 4873 11 xerxes 2015-08-05 12:35:09 +0200 (In reply to comment #10) > (In reply to comment #7) > > This crash is confined to the Raspi ARM? > > This crash is confined to Eric's 'alpha' OpenGL driver? > > It can be reproduced with both the "regular" framebuffer X11 driver found on > the default Raspbian system > and > by using Eric Anholt's glamour X11 driver. > > > It is *very* easy to reproduce this bug using the "regular" X11 framebuffer > driver + mesa3d software rasterizer using a Raspbian system if you disable > the bcm.vc.iv driver by moving the > /opt/vc to /opt/vc.off > > and then run the test program: > > javac -cp jogamp-fat.jar:. TestInitScreen.java > java -cp jogamp-fat.jar:. TestInitScreen Its easy to reproduce this on a raspberry pi 2 (quad core armv7) as well as using the raspberry pi 1 (singlecore armv6) when using the X11 framebuffer driver + mesa3d software rasterizer. Its near 100% reproduction rate when you move the opt/vc to /opt/vc.off 4874 12 sgothel 2015-08-05 13:46:03 +0200 jogl 4ff4f735c421ef343a8c447fa699c01444bd5e9b Bug 1183: Handle NULL return values for native RandR13 calls, which suppose to return 'int[]' Certain native RandR13 functions shall return 'int[]', but will bail out early in case of an error or lack of resources. The latter is true for getMonitorDeviceIds(..) where 'XRRScreenResources->ncrtc <= 0', causing return value NULL. This patch handles the NULL return values, however, the root cause of having 'XRRScreenResources->ncrtc <= 0' _occasionally_ lies within the Raspi X11 driver I am afraid?! 4875 13 sgothel 2015-08-05 13:50:24 +0200 (In reply to comment #12) > jogl 4ff4f735c421ef343a8c447fa699c01444bd5e9b > Bug 1183: Handle NULL return values for native RandR13 calls, > which suppose to return 'int[]' > > Certain native RandR13 functions shall return 'int[]', > but will bail out early in case of an error or lack of resources. > > The latter is true for getMonitorDeviceIds(..) > where 'XRRScreenResources->ncrtc <= 0', causing return value NULL. > > This patch handles the NULL return values, > however, the root cause of having 'XRRScreenResources->ncrtc <= 0' > _occasionally_ lies within the Raspi X11 driver I am afraid?! It should fall back to a fake entry using the virtual size within NEWT. If you can confirm this .. please set this bug to validated, thx! 4877 14 xerxes 2015-08-05 15:00:44 +0200 I can confirm that I no longer can see the exception when jogl 4ff4f735c421ef343a8c447fa699c01444bd5e9b is applied. 4882 15 xerxes 2015-08-05 23:45:26 +0200 (In reply to comment #12) > jogl 4ff4f735c421ef343a8c447fa699c01444bd5e9b > Bug 1183: Handle NULL return values for native RandR13 calls, > which suppose to return 'int[]' > > Certain native RandR13 functions shall return 'int[]', > but will bail out early in case of an error or lack of resources. > > The latter is true for getMonitorDeviceIds(..) > where 'XRRScreenResources->ncrtc <= 0', causing return value NULL. > > This patch handles the NULL return values, > however, the root cause of having 'XRRScreenResources->ncrtc <= 0' > _occasionally_ lies within the Raspi X11 driver I am afraid?! I found this upstream xorg bug, that includes a possible workaround! It is a possibility that this bug only trigger when using RandR in combination with an xorg driver that are not yet fully randr1.2 compatible. https://bugs.freedesktop.org/show_bug.cgi?id=20270 - XRRGetScreenResourcesCurrent (or XRRGetScreenResources) reports empty data until XRRGetScreenSizeRange is called on non randr1.2 drivers 4883 16 716 xerxes 2015-08-05 23:59:34 +0200 Created attachment 716 commit-15a7e36-cleanup-javadoc-signature-comments.patch Spotted some javadoc and comment typos while reading RandR code related to this bug. Feel free to merge using the patch attached. Bug 1183: Cleanup x11/RandR javadoc and native/X11RandR13 signature comments. 4888 17 gottfried.haider 2015-08-06 17:02:20 +0200 Thanks Sven & Xerxes! I am still a bit confused why this only hits occasionally and not for every invocation.. might be totally unrelated, but Processing just merged a fix related to screen device parsing (https://github.com/gohai/processing/commit/844501686ce509c21b9856d1accae7f41e729060) - testing in a bit with the JOGL fix and this on top. 4891 18 gottfried.haider 2015-08-09 15:39:29 +0200 I was testing with the new Mesa driver today, and instead of the NullPointerException I am now seeing the error below. Is this indeed the same root cause - outside of JOGL's codebase - not manifesting itself like this? Thanks! FATAL ERROR in native method: Nativewindow X11 IOError: Display 0x3dc5ee0 (:0): Resource temporarily unavailable Nativewindow X11 IOError: Display 0x3dc5ee0 (:0): Resource temporarily unavailable Nativewindow X11 IOError: Display 0x3dc5ee0 (:0): Resource temporarily unavailable at jogamp.newt.driver.x11.WindowDriver.CreateWindow0(Native Method) at jogamp.newt.driver.x11.WindowDriver.CreateWindow(WindowDriver.java:445) at jogamp.newt.driver.x11.WindowDriver.createNativeImpl(WindowDriver.java:130) at jogamp.newt.WindowImpl.createNative(WindowImpl.java:460) at jogamp.newt.WindowImpl.setVisibleActionImpl(WindowImpl.java:975) at jogamp.newt.WindowImpl$VisibleAction.run(WindowImpl.java:1026) at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:150) - locked <0x65a60628> (a java.lang.Object) at jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:372) 4896 19 xerxes 2015-08-09 18:21:53 +0200 (In reply to comment #18) > I was testing with the new Mesa driver today, and instead of the > NullPointerException I am now seeing the error below. Is this indeed the > same root cause - outside of JOGL's codebase - not manifesting itself like > this? Thanks! > > FATAL ERROR in native method: Nativewindow X11 IOError: Display 0x3dc5ee0 > (:0): Resource temporarily unavailable > Nativewindow X11 IOError: Display 0x3dc5ee0 (:0): Resource temporarily > unavailable > at jogamp.newt.driver.x11.WindowDriver.CreateWindow0(Native Method) ... > at jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:372) This is a different issue i have filed a new bug 1187 https://jogamp.org/bugzilla/show_bug.cgi?id=1187 to track it. 4908 20 xerxes 2015-08-10 17:11:11 +0200 jogl 217d8b78a3d70d9be59d4537c7565118dfe1e277 Bug 1183: Cleanup x11/RandR javadoc and native/X11RandR13 signature comments 4940 21 xerxes 2015-08-16 02:31:59 +0200 (In reply to comment #15) > (In reply to comment #12) > > jogl 4ff4f735c421ef343a8c447fa699c01444bd5e9b > > Bug 1183: Handle NULL return values for native RandR13 calls, > > which suppose to return 'int[]' > > > > Certain native RandR13 functions shall return 'int[]', > > but will bail out early in case of an error or lack of resources. > > > > The latter is true for getMonitorDeviceIds(..) > > where 'XRRScreenResources->ncrtc <= 0', causing return value NULL. > > > > This patch handles the NULL return values, > > however, the root cause of having 'XRRScreenResources->ncrtc <= 0' > > _occasionally_ lies within the Raspi X11 driver I am afraid?! > > I found this upstream xorg bug, that includes a possible workaround! > It is a possibility that this bug only trigger when using RandR in > combination with an xorg driver that are not yet fully randr1.2 compatible. > > https://bugs.freedesktop.org/show_bug.cgi?id=20270 - > XRRGetScreenResourcesCurrent (or XRRGetScreenResources) reports empty data > until XRRGetScreenSizeRange is called on non randr1.2 drivers I have seen this bug trigger on a x86_64 system as well using the jogl 2.3.1 an a laptop using a intel i916 + X.Org X Server 1.15.1 thus the root cause of having 'XRRScreenResources->ncrtc <= 0' _occasionally_ lies generally within all xorg drivers this bug has made bugreport rounds in all linux distributions yet no-one have fixed xorg instead they added workarounds to all applications using xrandr such as gtk, gdm... example Frederic Crozat proposed one workaround fix for this bug to gtk https://bugzilla.gnome.org/show_bug.cgi?id=572387#c2 https://bugzilla.gnome.org/attachment.cgi?id=129071&action=diff the reason the xrandr tool always work seems to be that it always uses XRRGetScreenSizeRange before calling XRRGetScreenResourcesCurrent or XRRGetScreenResources we want to add this workaround. by having XRRScreenResources->ncrtc allways containing valid data would make jogl better. 4941 22 xerxes 2015-08-16 04:47:04 +0200 (In reply to comment #21) Branch ready to merge: https://github.com/xranby/jogl/tree/Bug1183 https://github.com/xranby/jogl/commit/a213c39fa9d741d519df56bc4d4abb86113985f4 Bug 1183 XRRGetScreenResourcesCurrent (or XRRGetScreenResources) _occasionally_ reports empty data unless XRRGetScreenSizeRange has been called once. 4952 23 sgothel 2015-08-18 03:44:57 +0200 commit a213c39fa9d741d519df56bc4d4abb86113985f4 XRRGetScreenResourcesCurrent (or XRRGetScreenResources) _occasionally_ reports empty data unless XRRGetScreenSizeRange has been called once. Hence call XRRGetScreenSizeRange first! 715 2015-08-05 10:57:04 +0200 2015-08-05 10:57:04 +0200 TestInitScreen.java TestInitScreen.java text/plain 2041 xerxes LyoqCiAqIENvcHlyaWdodCAyMDE1IEpvZ0FtcCBDb21tdW5pdHkuIEFsbCByaWdodHMgcmVzZXJ2 ZWQuCiAqCiAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9y bXMsIHdpdGggb3Igd2l0aG91dCBtb2RpZmljYXRpb24sIGFyZQogKiBwZXJtaXR0ZWQgcHJvdmlk ZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlIG1ldDoKICoKICogICAgMS4gUmVk aXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmln aHQgbm90aWNlLCB0aGlzIGxpc3Qgb2YKICogICAgICAgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxv d2luZyBkaXNjbGFpbWVyLgogKgogKiAgICAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZv cm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UsIHRoaXMgbGlzdAog KiAgICAgICBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhl IGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscwogKiAgICAgICBwcm92aWRlZCB3 aXRoIHRoZSBkaXN0cmlidXRpb24uCiAqCiAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkg Sm9nQW1wIENvbW11bml0eSBgYEFTIElTJycgQU5EIEFOWSBFWFBSRVNTIE9SIElNUExJRUQKICog V0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRSBJTVBMSUVEIFdB UlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORAogKiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM QVIgUFVSUE9TRSBBUkUgRElTQ0xBSU1FRC4gSU4gTk8gRVZFTlQgU0hBTEwgSm9nQW1wIENvbW11 bml0eSBPUgogKiBDT05UUklCVVRPUlMgQkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVD VCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUgogKiBDT05TRVFVRU5USUFMIERB TUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJT VElUVVRFIEdPT0RTIE9SCiAqIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklU UzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRCBBTkQgT04KICogQU5Z IFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJ VFksIE9SIFRPUlQgKElOQ0xVRElORwogKiBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lO RyBJTiBBTlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYKICog QURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YgU1VDSCBEQU1BR0UuCiAqCiAqIFRoZSB2aWV3 cyBhbmQgY29uY2x1c2lvbnMgY29udGFpbmVkIGluIHRoZSBzb2Z0d2FyZSBhbmQgZG9jdW1lbnRh dGlvbiBhcmUgdGhvc2Ugb2YgdGhlCiAqIGF1dGhvcnMgYW5kIHNob3VsZCBub3QgYmUgaW50ZXJw cmV0ZWQgYXMgcmVwcmVzZW50aW5nIG9mZmljaWFsIHBvbGljaWVzLCBlaXRoZXIgZXhwcmVzc2Vk CiAqIG9yIGltcGxpZWQsIG9mIEpvZ0FtcCBDb21tdW5pdHkuCiAqLwoKCgppbXBvcnQgY29tLmpv Z2FtcC5uZXd0LkRpc3BsYXk7CmltcG9ydCBjb20uam9nYW1wLm5ld3QuTmV3dEZhY3Rvcnk7Cmlt cG9ydCBjb20uam9nYW1wLm5ld3QuU2NyZWVuOwoKCnB1YmxpYyBjbGFzcyBUZXN0SW5pdFNjcmVl biB7CgogICAgcHVibGljIHN0YXRpYyB2b2lkIHRlc3RJbml0U2NyZWVuQnVnMTE4MygpewogICAg ICAgIERpc3BsYXkgZGlzcGxheSA9IE5ld3RGYWN0b3J5LmNyZWF0ZURpc3BsYXkobnVsbCk7CiAg ICAgICAgZGlzcGxheS5hZGRSZWZlcmVuY2UoKTsKICAgICAgICBTY3JlZW4gc2NyZWVuID0gTmV3 dEZhY3RvcnkuY3JlYXRlU2NyZWVuKGRpc3BsYXksIDApOwogICAgICAgIHNjcmVlbi5hZGRSZWZl cmVuY2UoKTsKICAgIH0KCiAgICBwdWJsaWMgc3RhdGljIHZvaWQgbWFpbihTdHJpbmdbXSBhcmdz KSB7CiAgICAgICAgdGVzdEluaXRTY3JlZW5CdWcxMTgzKCk7CiAgICB9Cgp9Cg== 716 2015-08-05 23:59:34 +0200 2015-08-05 23:59:34 +0200 commit-15a7e36-cleanup-javadoc-signature-comments.patch commit-15a7e36-cleanup-javadoc-signature-comments text/plain 1918 xerxes Y29tbWl0IDE1YTdlMzZiNGU5ODdlNjU4MTcyNTQ5YWZmMzdmYmExN2M4ODFkNWQKQXV0aG9yOiBY ZXJ4ZXMgUsOlbmJ5IDx4ZXJ4ZXNAZ3VkaW5uYS5jb20+CkRhdGU6ICAgV2VkIEF1ZyA1IDIzOjUx OjM1IDIwMTUgKzAyMDAKCiAgICBCdWcgMTE4MzogQ2xlYW51cCB4MTEvUmFuZFIgamF2YWRvYyBh bmQgbmF0aXZlL1gxMVJhbmRSMTMgc2lnbmF0dXJlIGNvbW1lbnRzCgpkaWZmIC0tZ2l0IGEvc3Jj L25ld3QvY2xhc3Nlcy9qb2dhbXAvbmV3dC9kcml2ZXIveDExL1JhbmRSLmphdmEgYi9zcmMvbmV3 dC9jbGFzc2VzL2pvZ2FtcC9uZXd0L2RyaXZlci94MTEvUmFuZFIuamF2YQppbmRleCBmNDU3NjIx Li5hNDIxMjg5IDEwMDY0NAotLS0gYS9zcmMvbmV3dC9jbGFzc2VzL2pvZ2FtcC9uZXd0L2RyaXZl ci94MTEvUmFuZFIuamF2YQorKysgYi9zcmMvbmV3dC9jbGFzc2VzL2pvZ2FtcC9uZXd0L2RyaXZl ci94MTEvUmFuZFIuamF2YQpAQCAtNTUsNyArNTUsNyBAQCBwdWJsaWMgaW50ZXJmYWNlIFJhbmRS IHsKICAgICAgKiAgIDxsaT57QGxpbmsgI2dldE1vbml0b3JEZXZpY2VJZHMobG9uZywgU2NyZWVu RHJpdmVyKX08L2xpPgogICAgICAqICAgPGxpPntAbGluayAjZ2V0QXZhaWxhYmxlUm90YXRpb25z KGxvbmcsIFNjcmVlbkRyaXZlciwgaW50KX08L2xpPgogICAgICAqICAgPGxpPntAbGluayAjZ2V0 TW9uaXRvck1vZGVQcm9wcyhsb25nLCBTY3JlZW5Ecml2ZXIsIGludCl9PC9saT4KLSAgICAgKiAg IDxsaT57QGxpbmsgI2dldEN1cnJlbnRNb25pdG9yTW9kZVByb3BzKGxvbmcsIFNjcmVlbkRyaXZl ciwgaW50KTwvbGk+CisgICAgICogICA8bGk+e0BsaW5rICNnZXRDdXJyZW50TW9uaXRvck1vZGVQ cm9wcyhsb25nLCBTY3JlZW5Ecml2ZXIsIGludCl9PC9saT4KICAgICAgKiAgIDxsaT57QGxpbmsg I2dldE1vbml0b3JEZXZpY2VQcm9wcyhsb25nLCBTY3JlZW5Ecml2ZXIsIExpc3QsIGludCwgTW9u aXRvck1vZGUpfTwvbGk+CiAgICAgICogPC91bD4KICAgICAgKiA8cD4KZGlmZiAtLWdpdCBhL3Ny Yy9uZXd0L25hdGl2ZS9YMTFSYW5kUjEzLmMgYi9zcmMvbmV3dC9uYXRpdmUvWDExUmFuZFIxMy5j CmluZGV4IDM3YTZlYTAuLjBkZDUzZmUgMTAwNjQ0Ci0tLSBhL3NyYy9uZXd0L25hdGl2ZS9YMTFS YW5kUjEzLmMKKysrIGIvc3JjL25ld3QvbmF0aXZlL1gxMVJhbmRSMTMuYwpAQCAtMjAyLDcgKzIw Miw3IEBAIEpOSUVYUE9SVCB2b2lkIEpOSUNBTEwgSmF2YV9qb2dhbXBfbmV3dF9kcml2ZXJfeDEx X1JhbmRSMTNfZHVtcEluZm8wCiAvKgogICogQ2xhc3M6ICAgICBqb2dhbXBfbmV3dF9kcml2ZXJf eDExX1JhbmRSMTMKICAqIE1ldGhvZDogICAgZ2V0TW9uaXRvckRldmljZUlkczAKLSAqIFNpZ25h dHVyZTogKEopSQorICogU2lnbmF0dXJlOiAoSilbSQogICovCiBKTklFWFBPUlQgamludEFycmF5 IEpOSUNBTEwgSmF2YV9qb2dhbXBfbmV3dF9kcml2ZXJfeDExX1JhbmRSMTNfZ2V0TW9uaXRvckRl dmljZUlkczAKICAgKEpOSUVudiAqZW52LCBqY2xhc3MgY2xhenosIGpsb25nIHNjcmVlblJlc291 cmNlcykKQEAgLTI1Niw3ICsyNTYsNyBAQCBKTklFWFBPUlQgdm9pZCBKTklDQUxMIEphdmFfam9n YW1wX25ld3RfZHJpdmVyX3gxMV9SYW5kUjEzX2ZyZWVNb25pdG9ySW5mb0hhbmRsZQogLyoKICAq IENsYXNzOiAgICAgam9nYW1wX25ld3RfZHJpdmVyX3gxMV9SYW5kUjEzCiAgKiBNZXRob2Q6ICAg IGdldEF2YWlsYWJsZVJvdGF0aW9uczAKLSAqIFNpZ25hdHVyZTogKEopSQorICogU2lnbmF0dXJl OiAoSilbSQogICovCiBKTklFWFBPUlQgamludEFycmF5IEpOSUNBTEwgSmF2YV9qb2dhbXBfbmV3 dF9kcml2ZXJfeDExX1JhbmRSMTNfZ2V0QXZhaWxhYmxlUm90YXRpb25zMAogICAoSk5JRW52ICpl bnYsIGpjbGFzcyBjbGF6eiwgamxvbmcgbW9uaXRvckluZm8pCg==