Created attachment 91309 [details]
stacktrace

This exception happens when JPDADebuggerImpl.getAllThreads() returns a list with null element. This can only happen when ThreadsCache.getAllThreads() returns a list with null element. And from the messages.log file it's apparent that NPE was thrown also sooner in ThreadsCache.init() where VirtualMachine.allThreads() returned a list with null element.
This is getting outside of NetBeans, since JDWP.VirtualMachine.AllThreads.process(vm).threads had to contain a null element.

If you're able to reproduce this, please provide steps to reproduce and we'll file a defect for JDK debugger at http://bugs.sun.com/.

We can create a workaround in NetBeans, but that would only mask the original problem.

Thanks Martin!

I am using the NetBeans IDE to build a mobile app in J2ME. The application is basically an audio recorder. It requires a Player object and a Record Control object. Also i can either save the recorded file at a prederined location using RecordCOntrol.SetRecordLocation("Location Path") 

or 

I can save it to an output stream using RecordControl.SetRecordStream(OutputStream). 

The application works fine with the first option. When i try to save the recording to an OutputStream (2nd option) i face this error. Also to narrow down things even further, the exception does not occur until the player and recordcontrol objects are open at the same time. Which means that under the OUtputStream option i do not get any error if i first start the player and stop it and later start the recorder and stop it. But if i start the recorder and also start the player before stopping the recorder i get the NullPointer exception. 

I am not sure how to reproduce this problem as i dont know what exactly is causing it and i get this error every time. I am pasting a snippet of the code for your reference. 
================================================================================
   public void startApp() {
        if (midletPaused) {
            resumeMIDlet ();
        } else {
            initialize ();
            startMIDlet ();
             try {
    // Create a Player that captures live audio.
    Player p = Manager.createPlayer("capture://audio");
    p.realize();
    // Get the RecordControl, set the record stream,
    // start the Player and record for 5 seconds.
    RecordControl rc = (RecordControl)p.getControl("RecordControl");
    ByteArrayOutputStream output = new ByteArrayOutputStream();
    rc.setRecordStream(output);
    rc.startRecord();
    Thread.currentThread().sleep(5000);
    p.start();
    rc.commit();

    p.close();
 }

catch (Exception ie) {
      Form frm1=new Form("Error");
     frm1.append(ie.getMessage());
     Display.getDisplay(this).setCurrent(frm1);
 }
        }
       
    }
================================================================================
Please be kind enough to forward it to JDK Debugger forum.....

Also let me know if you need anything else from me. 

Thanks,
Saket

Btw, i also want to debug my application but my debugger is not working. 

I put the breakpoints and when i debug the output window shows something like this:

Waiting for debugger on port 2263
KVM not ready. Trying again...
nbdebug:
KVM not ready. Trying again...
KVM not ready. Trying again...
KdpDebugTask connecting to debugger 1 ..
KVM not ready. Trying again...
KVM not ready. Trying again...
Connection received.
KdpDebugTask connecting to debugger 2 ..

And i my application just does not load on the emulator. While the emulator itself is still working.

I tried looking online for some solution to this issue as well but no luck.

The debugger does not start, because there's another NPE caused by a null thread.
It looks like JDWP can return null thread for "debugger system thread" according to JDWP specification for class prepare event. That way the null thread probably gets into the listing of all threads.
Eclipse' VirtualMachineImpl removes null threads, but Sun's JDI implementation does not. Therefore I'll file a defect for JDI.

not on our side - verified

BTW: Martin would be nice to add JDK bug number into reports once it's a root cause - just to connect them as well as give a chance to final users to have a look (or/and comment, check the status) at it.