java-segfault-redux: fix analysis of modern SmartDashboard

2 files changed, 13 insertions, 3 deletions

diff --git a/public/java-segfault-redux.html b/public/java-segfault-redux.html
index 55529c2..2f25f4d 100644
--- a/public/java-segfault-redux.html
+++ b/public/java-segfault-redux.html
@@ -75,7 +75,9 @@ public BufferedImage getBufferedImage() {
 <p>TheLoneWolfling on Hacker News noted that they'd be worried about the JVM optimizing out the call to <code>getWidth()</code>. I'm not, because <code>WPIImage.getWidth()</code> calls <code>IplImage.width()</code>, which is declared as <code>native</code>; the JVM must run it because it might have side effects. On the other hand, looking back, I think I just shrunk the window for things to go wrong: it may be possible for the garbage collection to trigger in the time between <code>getWidth()</code> being dispatched and <code>width()</code> running. Perhaps there was something in the C/C++ code that made it safe, I don't recall, and don't care quite enough to dig into OpenCV internals again. Or perhaps I'm mis-remembering the fix (which I don't actually have a file of), and I called some other method that <em>could</em> get optimized out (though I <em>do</em> believe that it was either <code>getWidth()</code> or <code>getHeight()</code>).</p>
 <h2 id="wpis-fix">WPI's fix</h2>
 <p>Four years later, the SmartDashboard is still being used! But it no longer has this bug, and it's not using my workaround. So, how did the WPILib developers fix it?</p>
-<p>Well, the code now lives <a href="https://usfirst.collab.net/gerrit/#/admin/projects/">in git at collab.net</a>, so I decided to take a look. They put a mutex around all accesses to <code>image</code>, which should have been the obvious solution to me.</p>
+<p>Well, the code now lives <a href="https://usfirst.collab.net/gerrit/#/admin/projects/">in git at collab.net</a>, so I decided to take a look.</p>
+<p>The stripped out WPIJavaCV from the main video feed widget, and now use a purely Java implementation of MPJPEG streaming.</p>
+<p>However, the old video feed widget is still available as an extension (so that you can still do cool things with <code>processImage</code>), and it also no longer has this bug. Their fix was to put a mutex around all accesses to <code>image</code>, which should have been the obvious solution to me.</p>
 
 </article>
 <footer>
diff --git a/public/java-segfault-redux.md b/public/java-segfault-redux.md
index 85e92eb..e05e9d8 100644
--- a/public/java-segfault-redux.md
+++ b/public/java-segfault-redux.md
@@ -216,8 +216,16 @@ longer has this bug, and it's not using my workaround.  So, how did
 the WPILib developers fix it?
 
 Well, the code now lives [in git at collab.net][git], so I decided to
-take a look.  They put a mutex around all accesses to `image`, which
-should have been the obvious solution to me.
+take a look.
+
+The stripped out WPIJavaCV from the main video feed widget, and now
+use a purely Java implementation of MPJPEG streaming.
+
+However, the old video feed widget is still available as an extension
+(so that you can still do cool things with `processImage`), and it
+also no longer has this bug.  Their fix was to put a mutex around all
+accesses to `image`, which should have been the obvious solution to
+me.
 
 [original]: ./java-segfault.html
 [HN]: https://news.ycombinator.com/item?id=9283571