Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

Sometimes a complete freeze may happen when editing and issuing a request in the repeater

Manuel Bua Aug 25, 2019 04:11PM UTC

I'm not sure what is causing this, but sometimes when editing a request in the repeater and possibly removing the last CRLF characters by keeping pressed the CANC key, after issuing the request all the windows will freeze and CPU usage is fixed at 10/15%.

I'm attaching a `jstack -l` dump, i'm not sure how to reproduce it consistently, but usually modifying the ending characters of a request and issuing it will possibly make it hangs.

Dump: https://pastebin.com/mCvYqfnv


Kali Linux
java.runtime.name Java(TM) SE Runtime Environment
java.runtime.version 1.8.0_191-b12
java.specification.vendor Oracle Corporation
java.version 1.8.0_191
java.vm.info mixed mode
java.vm.name Java HotSpot(TM) 64-Bit Server VM
java.vm.specification.name Java Virtual Machine Specification
java.vm.specification.vendor Oracle Corporation
java.vm.specification.version 1.8
java.vm.vendor Oracle Corporation
java.vm.version 25.191-b12
jdk.tls.allowUnsafeServerCertChange true
jdk.tls.server.protocols TLSv1,TLSv1.1,TLSv1.2
os.arch amd64
os.name Linux
os.version 5.2.0-kali2-amd64



Mike Eaton Aug 28, 2019 12:13PM UTC Support Center agent

Hi Manuel,

Those characters are needed for HTTP requests as defined in the protocol documentation: https://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2

HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body

I have a few questions I would like to ask;
1. Do you need to remove these characters, or is this something that you have noticed while testing? as removing/modifying them would cause issues.
2. Does the application hang indefinitely, or does it eventually come back with a result?
3. Do you have performance feedback enabled (User options > Misc > Performance feedback)? If so, could you provide us with your DebugID and diagnostics (Help > Diagnostics)?


Manuel Bua Aug 28, 2019 05:51PM UTC
Hi Mike, yes sure my explanation was missing that part, but I meant:

1) fiddling with the ending bytes of the request and also removing the final CRLF, for example, sending to the repeater a request with a long body, then selecting all the body bytes there and CANC it away, then manually building the body and ensuring the final CRLF is there.

2) Issuing these requests has higher chances to freeze the whole application and any open window if any, to close it I can only kill -9 on it.

3) Yes, debug id is g7ff9i0clf0dulct6w1z:m6xe
Diagnostics: https://pastebin.com/qFtcZz1W


Mike Eaton Aug 30, 2019 07:43AM UTC Support Center agent

Hi Manuel,

Thank you for supplying your diagnostic information.

Looking through the information that your Burp has passed back to us, I can see some exceptions being passed through that could be related to your issue, can you remember roughly what date & time you were having these issues?

Also, can you provide an example of the request you are trying to send in the repeater?


Manuel Bua Aug 30, 2019 02:37PM UTC
I can't remember date and times sorry, but I can do better and provide solid instructions for replication as well as a video that demonstrate the problem.

I mapped the Repeater's "Send" request to CTRL+R because I'm much more comfortable when issuing multiple requests fast.

I'm not sure this is a feature, but while clicking the "Send" button actually grays it out until a response is received or an event occurs, the shortcut will actually "enqueue" my requests; so i often use this to actually see the response panel refresh multiple times, one after another, in order to spot simple differences in the headers and then stop it and go back to history to actually see the occurrence.

The problem lies when multiple requests get enqueued AND you modify the request in between: so, while a request has been issued and the response has yet to arrive, modifying the request at the end of the text and enqueuing it as well via CTRL+R will make the caret disappear from the panel.

If you click on the panel around the caret will eventually come back, but if you enqueue just another request this way you'll have the freeze.

I've prepared a video PoC for you, can you tell me where to send it?

Manuel Bua Aug 30, 2019 02:42PM UTC
Forgot to mention: as you will notice in the video, the modified request will not persist; in the video the content "abca" is reverted back to "abc" as soon as the first response arrives, then the cursor will disappear.

Mike Eaton Sep 02, 2019 08:16AM UTC Support Center agent

Thank you for the steps to reproduce, I will attempt to reproduce your issue and come back to you with more information.

In regards to the video, if you could email it to support@portswigger.net that would be great.

Could you also confirm the version of Burp Suite you are using?


Manuel Bua Sep 02, 2019 04:31PM UTC
Hi, i'm using version 2.1.03 Pro: sending in the video now.

Colin Sep 28, 2019 01:32AM UTC
Hi Mike,

I also am experiencing this where in repeater if I by mistake delete something in the request body and it freezes completely on every window and doesn't come back. I think I also clicked the back button in repeater to go back to the previous request but not entirely sure.

Here's something from the jre debug.log:

[0927/200717.448334:WARNING:x11_util.cc(1422)] X error received: serial 603, error_c ode 170 (GLXBadWindow), request_code 152, minor_code 32 (X_GLXDestroyWindow)
[0927/200717.448753:WARNING:x11_util.cc(1422)] X error received: serial 607, error_code 3 (BadWindow (invalid Window parameter)), request_code 4, minor_code 0 (X_DestroyWindow)

Not sure if that is useful but I wanted to throw my two cents in and confirm that this bug does exist and this never happened in the past. I only started noticing it recently in the past couple releases.

Mike Eaton Sep 30, 2019 02:21PM UTC Support Center agent

Hi Colin, this might be due to an invalid request causing the server to be unable to return a valid response. We have validated that the behavior reported by Manuel is a bug due to being able to edit requests while making a request. So I’m not sure if they are related.


Post Your public answer

Your name
Your email address
Answer