This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 148490 - Debugging session won't start after early cancellation
Summary: Debugging session won't start after early cancellation
Status: RESOLVED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Java (show other bugs)
Version: 6.x
Hardware: PC Windows Vista
: P2 blocker (vote)
Assignee: Daniel Prusa
URL:
Keywords:
: 146549 160938 167355 169257 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-09-26 14:06 UTC by Petr Cyhelsky
Modified: 2009-08-10 19:04 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Screenshot - see the stuck session in sessions view (195.21 KB, image/jpeg)
2008-09-30 18:01 UTC, Petr Cyhelsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Cyhelsky 2008-09-26 14:06:47 UTC
Product Version: NetBeans IDE Dev (Build 200809251401)
Java: 1.6.0_10-rc; Java HotSpot(TM) Client VM 11.0-b14
System: Windows Vista version 6.0 running on x86; Cp1250; cs_CZ (nb)

Steps to reproduce: Start netbeans -> open some java project -> start debugging by some means and immediately cancel the
session via the process bar(before it is fully started) -> no dbg session can be started after that

After canceling debug session through process bar while it is still starting no other debugging session can be started
via any means. NB must be restarted to allow debugging again. When it happens the following shows in output:

debug:
Listening failed with arguments: {timeout=timeout=, name=name=}
java.io.IOException: shmemBase_listen failed: Cannot create a file when that file already exists

        at org.netbeans.modules.debugger.jpda.ant.JPDAStart.execute(JPDAStart.java:239)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:357)
        at org.apache.tools.ant.Target.performTasks(Target.java:385)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
        at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:273)
        at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:499)
        at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:151)
Caused by: java.io.IOException: shmemBase_listen failed: Cannot create a file when that file already exists

        at com.sun.tools.jdi.SharedMemoryTransportService.startListening0(Native Method)
        at com.sun.tools.jdi.SharedMemoryTransportService.startListening(SharedMemoryTransportService.java:100)
        at com.sun.tools.jdi.GenericListeningConnector.startListening(GenericListeningConnector.java:96)
        at com.sun.tools.jdi.SharedMemoryListeningConnector.startListening(SharedMemoryListeningConnector.java:56)
        at org.netbeans.modules.debugger.jpda.ant.JPDAStart.run(JPDAStart.java:279)
        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:572)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:997)
--- Nested Exception ---
java.io.IOException: shmemBase_listen failed: Cannot create a file when that file already exists

        at com.sun.tools.jdi.SharedMemoryTransportService.startListening0(Native Method)
        at com.sun.tools.jdi.SharedMemoryTransportService.startListening(SharedMemoryTransportService.java:100)
        at com.sun.tools.jdi.GenericListeningConnector.startListening(GenericListeningConnector.java:96)
        at com.sun.tools.jdi.SharedMemoryListeningConnector.startListening(SharedMemoryListeningConnector.java:56)
        at org.netbeans.modules.debugger.jpda.ant.JPDAStart.run(JPDAStart.java:279)
        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:572)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:997)
java.io.IOException: shmemBase_listen failed: Cannot create a file when that file already exists
        at com.sun.tools.jdi.SharedMemoryTransportService.startListening0(Native Method)
        at com.sun.tools.jdi.SharedMemoryTransportService.startListening(SharedMemoryTransportService.java:100)
        at com.sun.tools.jdi.GenericListeningConnector.startListening(GenericListeningConnector.java:96)
        at com.sun.tools.jdi.SharedMemoryListeningConnector.startListening(SharedMemoryListeningConnector.java:56)
        at org.netbeans.modules.debugger.jpda.ant.JPDAStart.run(JPDAStart.java:279)
        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:572)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:997)
BUILD FAILED (total time: 0 seconds)
Comment 1 Petr Cyhelsky 2008-09-30 18:01:50 UTC
Created attachment 70922 [details]
Screenshot - see the stuck session in sessions view
Comment 2 Daniel Prusa 2008-10-03 13:13:21 UTC
Not easily reproducible for me. I have made several attempts, but the IOException has never been thrown. However, I have
encountered once a situation when the debug process bar got stuck after trying to cancel the process. The related
session was in "Starting" state as well, but it was possible to start another session.
Additional investigation of the problem is needed.
Comment 3 baffyofdaffy 2009-02-11 21:11:12 UTC
I am able to recreate.

Workaround is to restart NetBeans.

I do Ctrl+F5 on a Java Application project and it takes awhile because there are a few java files unsaved and a few not
compiled (compile on save is enabled)

Then I click the red square stop button to the left of the output of debug (not the debugger console). That square
button is the one under the re-run button and over the ant config button.

Then after awhile the "Debugger console" comes up along with all the debugging windows and tool bars.

Then I am unable to 'Cancel the debugging' because I already did so the only way to get rid of those windows/toolbars is
one at a time. Then when I want to restart the debug, I get the same messages from the "ant" "debug" output

"Cannot create a file when that file already exists"

I am windows xp with the same release of NetBeans which is 6.5.
Comment 4 baffyofdaffy 2009-02-11 21:12:27 UTC
*** Issue 146549 has been marked as a duplicate of this issue. ***
Comment 5 Martin Entlicher 2009-06-19 11:20:30 UTC
*** Issue 167355 has been marked as a duplicate of this issue. ***
Comment 6 Martin Entlicher 2009-06-19 11:27:30 UTC
*** Issue 160938 has been marked as a duplicate of this issue. ***
Comment 7 Martin Entlicher 2009-06-19 11:38:06 UTC
FYI: I've found: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4905551
which is a duplicate of http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4368399
From that it looks like it's possible that the kill of the VM does not release the shared memory.
There does not seem to be any plans to fix this in JDK, therefore we should try to create some workaround for this.

Upgrading to P2 due to the number of duplicates and bad user experience - inability to debug for no apparent reason.
Comment 8 Martin Entlicher 2009-06-19 11:42:56 UTC
I've found that SocketTransportService generates a new port number on every invocation, therefore if there's some staled
VM waiting on that port, a new one is generated on the next debugger start.

But this is not like that with SharedMemoryTransportService, which is used on Windows. It uses "javadebug" shared memory
name by default and does not care if it's already used or not. Therefore the workaround might be to try a different name
if the default fails.
Comment 9 ulfzibis 2009-06-19 11:54:15 UTC
Until workaround is not provided, user should get better message for short cut.
See my comments: Issue 167355
Comment 10 Daniel Prusa 2009-07-23 15:45:14 UTC
Workaround implemented. When the default shared memory address name fails, more attempts follow with randomly generated
names.
http://hg.netbeans.org/main/rev/857ce0391c9d
Comment 11 Quality Engineering 2009-07-24 05:42:01 UTC
Integrated into 'main-golden', will be available in build *200907240201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/857ce0391c9d
User: Daniel Prusa <dprusa@netbeans.org>
Log: #148490: Debugging session won't start after early cancellation
Comment 12 Martin Entlicher 2009-08-10 16:43:41 UTC
*** Issue 169257 has been marked as a duplicate of this issue. ***
Comment 13 swpalmer 2009-08-10 19:04:59 UTC
"Workaround implemented. When the default shared memory address name fails, more attempts follow with randomly 
generated names."

What about the issue of leaving the previous debug session in an odd state?  This can be caused without the user 
immediately cancelling the debug session.  There are times when NB should know that it has left the debugger in a 
messed up state and perhaps it can clean up after itself better. See issue #169257