Sometimes a complete freeze may happen when editing and issuing a request in the repeater
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.
java.runtime.name Java(TM) SE Runtime Environment
java.specification.vendor Oracle Corporation
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.vendor Oracle Corporation
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)?
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
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?
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?
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 firstname.lastname@example.org that would be great.
Could you also confirm the version of Burp Suite you are using?
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.
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.