Burp Suite User Forum

Create new post

Burp could not obtain file lock of project file

Michael | Last updated: Apr 18, 2016 01:58PM UTC

Hi there, I'm using the 1.7 beta and burp crashed at some point. When I try to open the project burp just says "Could not obtain lock on file : [...] 12345.burp". What can I at this point?

PortSwigger Agent | Last updated: Apr 18, 2016 02:16PM UTC

Burp obtains an exclusive lock on project files when using them. It's possible that the Burp/Java process that holds the original lock is still running. Look for it in your process list and kill it. Alternatively, a system reboot will release any locks.

Burp User | Last updated: Apr 20, 2016 04:49PM UTC

I have the same problem and I've rebooted several times; thereby releasing any locks. I've even copied the file to a new location but still I get "Could not obtain lock on file: <file path>". If I choose the option of "Load from configuration file" or "Use options saved with project" it get "Failed to create Burp project: NullPointerException"

PortSwigger Agent | Last updated: Apr 21, 2016 07:58AM UTC

If you have rebooted or copied a new file and you are still getting an error relating to obtaining a lock, then this indicates that the filesystem isn't suitable for obtaining a lock Is the file located on a shared drive, rather than a local disk?

Burp User | Last updated: Apr 21, 2016 09:12AM UTC

Same problem here - working on a file since last week, machine rebooted for updates, and now the file won't open. First time I try I get "NullPointerException". Next time round I get "Could not obtain lock on file". File system is local NTFS drive. File is just shy of 10GB.

PortSwigger Agent | Last updated: Apr 21, 2016 09:56AM UTC

We'll look into these issues, thanks. If you have performance feedback enabled, and can email us your debug ID (user options / misc / performance feedback), that will help us diagnose what might be going wrong.

PortSwigger Agent | Last updated: May 12, 2016 02:40PM UTC

Benjamin - this native JVM crash is probably due to a bug in OpenJDK. We discuss workaround in our blog here: http://blog.portswigger.net/2016/05/using-disk-based-projects-with-openjdk.html

Burp User | Last updated: Jun 17, 2016 09:10AM UTC

Same problem here: $ ls -l /tmp/bla* ls: Zugriff auf /tmp/bla* nicht möglich: Datei oder Verzeichnis nicht gefunden $ java -jar burpsuite_pro_v1.7.03.jar --project-file=/tmp/bla # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fac9b374fbb, pid=11124, tid=140379400005376 # # JRE version: OpenJDK Runtime Environment (7.0_101) (build 1.7.0_101-b00) # Java VM: OpenJDK 64-Bit Server VM (24.95-b01 mixed mode linux-amd64 compressed oops) # Derivative: IcedTea 2.6.6 # Distribution: Debian GNU/Linux 8.4 (jessie), package 7u101-2.6.6-2~deb8u1 # Problematic frame: # C [libjava.so+0x18fbb] Java_java_nio_Bits_copyToShortArray+0x1fb # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /tmp/hs_err_pid11124.log # # If you would like to submit a bug report, please include # instructions on how to reproduce the bug and visit: # http://icedtea.classpath.org/bugzilla # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # Aborted $ ls -l /tmp/bla* -rw-r--r-- 1 ben ben 65536 Jun 17 11:00 /tmp/bla.burp Stack trace from the hs_err.log Stack: [0x00007fe8fc8f7000,0x00007fe8fc9f8000], sp=0x00007fe8fc9f5ab0, free space=1018k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libjava.so+0x18fbb] Java_java_nio_Bits_copyToShortArray+0x1fb j java.nio.Bits.copyToShortArray(JLjava/lang/Object;JJ)V+0 j java.nio.Bits.copyToCharArray(JLjava/lang/Object;JJ)V+5 j java.nio.DirectCharBufferS.get([CII)Ljava/nio/CharBuffer;+108 j java.nio.HeapCharBuffer.put(Ljava/nio/CharBuffer;)Ljava/nio/CharBuffer;+141 j java.nio.DirectCharBufferS.toString(II)Ljava/lang/String;+61 j java.nio.CharBuffer.toString()Ljava/lang/String;+9 j burp.k3c.toString()Ljava/lang/String;+4 j burp.w3c.toString()Ljava/lang/String;+6 j burp.zre.a(Lburp/mke;Lburp/xwd;)Ljava/lang/String;+19 j burp.d4c.e()Ljava/lang/String;+8 j burp.chg.b(Ljava/lang/String;IZ)Lburp/yv;+41 j burp.chg.a(Ljava/lang/String;IZ)Lburp/yv;+22 j burp.ayd.<init>(Lburp/grf;Lburp/chg;Lburp/jqg;)V+28 j burp.jqg.f()Lburp/ayd;+13 j burp.s0c.<init>(Lburp/euf;Lburp/h8g;Lburp/prg;Lburp/gm;Lburp/mzc;Lburp/mnh;Lburp/jqg;)V+74 j burp.d8.m()V+179 j burp.tef.a(Lburp/dve;)V+1 j burp.tef.a(Ljava/lang/Object;)V+5 j burp.grf.a(Lburp/ckc;)V+29 j burp.grf.d()V+13 j burp.zcf.a(Lburp/clh;Lburp/v2c;Lburp/jjf;)Lburp/euf;+1524 j burp.r0c.a()Lburp/euf;+56 j burp.r0c.doInBackground()Ljava/lang/Object;+1 j javax.swing.SwingWorker$1.call()Ljava/lang/Object;+14 j java.util.concurrent.FutureTask.run()V+42 j javax.swing.SwingWorker.run()V+4 j java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+95 j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub V [libjvm.so+0x601d54] V [libjvm.so+0x600a7e] V [libjvm.so+0x63e6ef] V [libjvm.so+0x9342e8] V [libjvm.so+0x934571] V [libjvm.so+0x7f8202] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j java.nio.Bits.copyToShortArray(JLjava/lang/Object;JJ)V+0 j java.nio.Bits.copyToCharArray(JLjava/lang/Object;JJ)V+5 j java.nio.DirectCharBufferS.get([CII)Ljava/nio/CharBuffer;+108 j java.nio.HeapCharBuffer.put(Ljava/nio/CharBuffer;)Ljava/nio/CharBuffer;+141 j java.nio.DirectCharBufferS.toString(II)Ljava/lang/String;+61 j java.nio.CharBuffer.toString()Ljava/lang/String;+9 j burp.k3c.toString()Ljava/lang/String;+4 j burp.w3c.toString()Ljava/lang/String;+6 j burp.zre.a(Lburp/mke;Lburp/xwd;)Ljava/lang/String;+19 j burp.d4c.e()Ljava/lang/String;+8 j burp.chg.b(Ljava/lang/String;IZ)Lburp/yv;+41 j burp.chg.a(Ljava/lang/String;IZ)Lburp/yv;+22 j burp.ayd.<init>(Lburp/grf;Lburp/chg;Lburp/jqg;)V+28 j burp.jqg.f()Lburp/ayd;+13 j burp.s0c.<init>(Lburp/euf;Lburp/h8g;Lburp/prg;Lburp/gm;Lburp/mzc;Lburp/mnh;Lburp/jqg;)V+74 j burp.d8.m()V+179 j burp.tef.a(Lburp/dve;)V+1 j burp.tef.a(Ljava/lang/Object;)V+5 j burp.grf.a(Lburp/ckc;)V+29 j burp.grf.d()V+13 j burp.zcf.a(Lburp/clh;Lburp/v2c;Lburp/jjf;)Lburp/euf;+1524 j burp.r0c.a()Lburp/euf;+56 j burp.r0c.doInBackground()Ljava/lang/Object;+1 j javax.swing.SwingWorker$1.call()Ljava/lang/Object;+14 j java.util.concurrent.FutureTask.run()V+42 j javax.swing.SwingWorker.run()V+4 j java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+95 j java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub

Burp User | Last updated: Sep 22, 2016 09:27AM UTC

Same error....!!!!! When I choose "Use Burp Defaults" in free version of burp.... Failed to create burp project: NullPointerException Please fix this soon....!!!!

PortSwigger Agent | Last updated: Sep 22, 2016 09:31AM UTC

Mukthi - are you using the latest release of Burp Suite free edition (1.7.06)?

Burp User | Last updated: Oct 12, 2016 08:20PM UTC

Same error while using "Use Burp Defaults" and using latest release (1.7.06) This is while attempting to start a jython console using: $ java -jar python-standalone-2.7.0.jar run.py -B burpsuite_free_v1.7.06 jar -i -d -v Incidentally, I am a Pro license holder but am using this free version for testing automation. Thanks very much for your assistance.

PortSwigger Agent | Last updated: Oct 13, 2016 08:10AM UTC

People have weighed into this thread referring to completely different errors (failure to obtain file locks. JVM crashes, and NullPointerException). To avoid confusion I'm closing this thread. Please can anyone with remaining issues post a new thread with full details of the specific problem? Thanks.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.