Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

ITextEditor.getText() deadlock

Nadeem | Last updated: Jun 26, 2015 08:11PM UTC

Hi guys, First off, keep up the great work and I hope to meet you guys in Vegas for DC. I have a small issue with BurpSuite due to the way my plugin is making calls between the FX and Swing thread. I understand FX is not supported in Burp and I appreciate why. However, I was wondering why the model of the ITextEditor concrete class is tied to the Swing event loop. I have a situation where I've created a call chain that calls deadlock which looks like this: Swing.getMessage() -> FX.getMessage() -> Swing.getText() -> deadlock This is because each step in this chain uses a FutureTask and calls .get() to get the result synchronously. As you know, the threads go into sleep and this is why we get a deadlock. I completely understand that part of the problem exists because I am doing this weird Interop thing, but trust me, it's well worth it (I hope I can convince you guys at DEFCON:)). Is there any way we can decouple the model/bean that represents the data contained in the text editor from the swing component? That way calling things like .getText() wouldn't require code to be running in the Swing event dispatch loop? Your help and insight would be greatly appreciated! Thanks, Nadeem

PortSwigger Agent | Last updated: Jun 29, 2015 12:32PM UTC

Burp curently only uses Swing for its UI. It's possible at some future point we will switch to using FX, but until that occurs you may run into issues trying to get Swing and FX to play well together. It ought to be possible to write your extension code in such a way that it isn't necessary to switch back and forth between the Swing and FX threads in this way. This might involve spawning a new thread to perform actions off the Swing thread, or conversely running your code on the Swing thread via invokeLater(), depending on exactly how the deadlock is arising.

Burp User | Last updated: Jun 29, 2015 08:30PM UTC

Dafydd, Will you be attending DEF CON this year? I'd love to grab a cup of coffee or a beer with you and the team!

PortSwigger Agent | Last updated: Jun 30, 2015 08:09AM UTC