Bug 115033

Summary: [65cat] Wrong Invalid LineBreakpoint message
Product: javaee Reporter: noot <noot>
Component: DebuggerAssignee: Martin Entlicher <mentlicher>
Status: VERIFIED FIXED QA Contact: issues <issues.netbeans.org>
Priority: P2 CC: bht, gholmer, jkovalsky, mentlicher, pcw, pjiricka, sustaining, vkraemer
Version: 6.x   
Target Milestone: 6.x   
Hardware: All   
OS: All   
Whiteboard: 67patch1-verified
Issue Type: DEFECT Exception Report:
Attachments: log file after occurence, with -D-J option on
screenshot of invalid breakpoint in editor
screenshot of invalid breakpoint in editor
another UI Gestures dump with the -J-D option on
screen dump corresponding to previous UI Gestures attachment
messages.log
invalid breakpoint - stopped anyway, incorrect highlight
screenshot: first it isn't, then it is, then it isn't, then it is...
log file
screen dump
screenshot
screenshot
thread dump
log file from userdir

Description noot 2007-09-07 15:08:39 UTC
When setting a new breakpoint the debugger console prints an Invalid LineBreakpoint error message and it prints a
message that it succeeds set the breakpoint. The first message is wrong.

User program running
Not able to submit breakpoint LineBreakpoint CommandViewManager.java : 284, reason: No executable location available at
line 284.
Invalid LineBreakpoint CommandViewManager.java : 284
LineBreakpoint CommandViewManager.java : 284 successfully submitted.
Comment 1 Martin Entlicher 2007-09-14 13:58:05 UTC
This is very strange. Can it happen that you have two classes with the same name - CommandViewManager.java ? In
different projects perhaps?
Any details on what is at line 284 in CommandViewManager.java? Could you provide some sample file which we can use to
reproduce the problem?
Comment 2 noot 2007-09-15 00:28:39 UTC
I found out that if I clear the var/cache/index directory that the problem is temporarily solved. It happens with
basically all my files and it's does not specifically has to do something with CommandViewManager.java. Because I
cleared the cache recently I will have to wait until it happens again. When the problem occurs again. Is there anything
else you need? From the cache as well perhaps?
Comment 3 noot 2007-09-26 06:53:14 UTC
IT happened again with a different java class this time, called MailManager.java.
I'm not sure if it helps but I solved the problem by removing only one file from the cache:
.netbeans/dev/var/cache/index/0.3/s67/classes/retail/core/MailManager.sig
Comment 4 Martin Entlicher 2007-10-04 10:18:40 UTC
noot, which build of NetBeans do you use? This looks like a bug in java database. It might be solved in newer builds.
Did you try NB 6.0 beta 1?
Comment 5 noot 2007-10-08 08:55:07 UTC
I'm using development built 200708300000. I will try the latest.
Comment 6 noot 2007-10-09 07:04:06 UTC
I have the same error with built 200710071200. It worked fine for a while and after a few debugging sessions it happened
again. BTW I'm debugging mainly by attaching the debugger while the application is already running.
Comment 7 noot 2007-10-11 07:25:43 UTC
I noticed that just restarting Netbeans solves it temporarily. Beside getting errors and accepting the breakpoints I
also sometime get errors and Netbeans doesn't accept the breakpoints. Then again restarting Netbeans solves it temporarily.
Comment 8 Martin Entlicher 2007-10-18 17:45:21 UTC
Can you please add -J-Dorg.netbeans.modules.debugger.jpda.level=400 option to netbeans.conf and provide the message.log
as soon as the error occurs? This option will generated some additional debugging info, which can help to identify the
problem.

It looks like this error somehow depends on projects you have opened in NetBeans. Can it happen that you have several
project containing CommandViewManager class? Can you please look into Window/Debugging/Sources and verify that the
source roots are the correct ones there?
Also, which operating system do you have?
Thanks.
Comment 9 Martin Entlicher 2007-10-18 17:55:39 UTC
*** Issue 116578 has been marked as a duplicate of this issue. ***
Comment 10 noot 2007-10-20 04:10:28 UTC
Ok, I added de debug level option.

The CommandViewManager class is only part of one project. I sometimes have more than one (open) project depending on the
project with the CommandViewManager class though.

I checked Window/Debugging/Sources and the sources listed are correct.

I'm running Netbeans on Linux
Comment 11 gholmer 2007-10-24 18:42:37 UTC
Created attachment 51606 [details]
log file after occurence, with -D-J option on
Comment 12 gholmer 2007-10-24 18:46:11 UTC
Created attachment 51607 [details]
screenshot of invalid breakpoint in editor
Comment 13 gholmer 2007-10-24 18:46:18 UTC
Created attachment 51608 [details]
screenshot of invalid breakpoint in editor
Comment 14 gholmer 2007-10-25 14:12:58 UTC
Where I am seeing this is when I debug a remote copy of Tomcat, then make a change, rebuild the war file, and redeploy.
 Even if I stop and restart the debugger, he doesn't seem to recognize breakpoints in changed code unless I restart Tomcat.
 
Comment 15 gholmer 2007-10-25 14:28:06 UTC
Created attachment 51676 [details]
another UI Gestures dump with the -J-D option on
Comment 16 gholmer 2007-10-25 14:31:53 UTC
Created attachment 51679 [details]
screen dump corresponding to previous UI Gestures attachment
Comment 17 gholmer 2007-10-25 14:42:01 UTC
Created attachment 51682 [details]
messages.log
Comment 18 gholmer 2008-01-05 23:00:02 UTC
Created attachment 54726 [details]
invalid breakpoint - stopped anyway, incorrect highlight
Comment 19 Martin Entlicher 2008-02-13 15:12:31 UTC
This does not look like a bug in debugger itself. There are not availabe the appropriate line locations in the bytecode.
Thus maybe a compiler issue? Can you attach some source file that would demonstrate this behavior?
It's very strange that it works a while and stops working later on. The association with Java cache is also strange. It
looks like a bug outside of debugger scope. Some testcase would allow us to find the root cause of the problem. Thanks.
Comment 20 gholmer 2008-03-07 13:19:05 UTC
I'm seeing this in my log, is it related?  I only seem to experience this issue when debugging a remote app server.

INFO [org.netbeans.modules.j2ee.deployment.impl.ServerInstance]: DebuggerInfo cannot be found for: GlassFish V2 (external)
INFO [org.netbeans.modules.j2ee.deployment.impl.ServerInstance]: DebuggerInfo cannot be found for: GlassFish V2 (external)
INFO [org.netbeans.modules.j2ee.deployment.impl.ServerInstance]: DebuggerInfo cannot be found for: Tomcat 6.0 (external)
INFO [org.netbeans.modules.j2ee.deployment.impl.ServerInstance]: DebuggerInfo cannot be found for: GlassFish V2 (external)
Comment 21 esorribas 2008-08-27 07:58:23 UTC
I have the same problem when compiling the class and running socket attach debugger : 

Not able to submit breakpoint LineBreakpoint Graficador.java : 53, reason: Line number information is missing in the
class file com.pruebas.Graficador.

The server is an Oracle IAS Application Server.

Other thing is the button "apply code changes", the butto is always deactivated and i don't known how to activate
Comment 22 Martin Entlicher 2008-08-27 08:44:54 UTC
esorribas, when line number information is missing in your classes, you will not be able to submit breakpoints. You need
to compile the classes with -g to enable debugging.
Comment 23 Martin Entlicher 2008-08-27 08:48:50 UTC
I do not think that the message about DebuggerInfo has any effect here, I also see these messages.
Moving to J2EE debugger for evaluation, since this issue occurs when debugging a remote app server.
Comment 24 esorribas 2008-08-27 13:23:47 UTC
This is my ide-file-targets.xml configuration:

    <target name="compile-selected-files-in-java">
        <fail unless="files">Must set property 'files'</fail>
        <!-- TODO decide on and define some value for ${build.classes.dir} -->
        <mkdir dir="hphis-war/web/WEB-INF/classes"/>
        <javac destdir="hphis-war/web/WEB-INF/classes" includes="${files}" source="1.4" srcdir="hphis-war/src/java">
            <compilerarg value="-g"/>
            <classpath
path="C:\cvs_trabajo\lib\activation.jar;C:\cvs_trabajo\lib\ant-contrib.jar;C:\cvs_trabajo\lib\ant-launcher.jar;C:\cvs_trabajo\lib\ant.jar;C:\cvs_trabajo\lib\antlr-2.7.6rc1.jar;C:\cvs_trabajo\lib\asm-attrs.jar;C:\cvs_trabajo\lib\asm.jar;C:\cvs_trabajo\lib\avalon-framework-4.1.5.jar;C:\cvs_trabajo\lib\avalon.jar;C:\cvs_trabajo\lib\axis-ant.jar;C:\cvs_trabajo\lib\axis-schema.jar;C:\cvs_trabajo\lib\axis-wsdl4j-1.2.jar;C:\cvs_trabajo\lib\axis.jar;C:\cvs_trabajo\lib\axis2-0.9.jar;C:\cvs_trabajo\lib\b64enc.jar;C:\cvs_trabajo\lib\barcode4j-demo-applet.jar;C:\cvs_trabajo\lib\barcode4j-light.jar;C:\cvs_trabajo\lib\batik.jar;C:\cvs_trabajo\lib\bonita-client.jar;C:\cvs_trabajo\lib\bsh-1.3.0.jar;C:\cvs_trabajo\lib\bsh-2.0b4.jar;C:\cvs_trabajo\lib\c3p0-0.9.0.jar;C:\cvs_trabajo\lib\cglib-2.1.3.jar;C:\cvs_trabajo\lib\cleanimports.jar;C:\cvs_trabajo\lib\comm.jar;C:\cvs_trabajo\lib\common-softvaluehashmap.jar;C:\cvs_trabajo\lib\commons-beanutils-bean-collections.jar;C:\cvs_trabajo\lib\commons-beanutils-core.jar;C:\cvs_trabajo\lib\commons-cli-1.0.jar;C:\cvs_trabajo\lib\commons-collections-3.1.jar;C:\cvs_trabajo\lib\commons-dbcp-1.2.1.jar;C:\cvs_trabajo\lib\commons-digester-1.7.jar;C:\cvs_trabajo\lib\commons-discovery-0.2.jar;C:\cvs_trabajo\lib\commons-discovery.jar;C:\cvs_trabajo\lib\commons-el.jar;C:\cvs_trabajo\lib\commons-javaflow-r306555.jar;C:\cvs_trabajo\lib\commons-lang-2.3.jar;C:\cvs_trabajo\lib\commons-logging-1.0.4.jar;C:\cvs_trabajo\lib\commons-logging-api.jar;C:\cvs_trabajo\lib\commons-logging.jar;C:\cvs_trabajo\lib\commons-net-1.4.1.jar;C:\cvs_trabajo\lib\commons-pool-1.2.jar;C:\cvs_trabajo\lib\concurrent.jar;C:\cvs_trabajo\lib\derby.jar;C:\cvs_trabajo\lib\DocAnotacion20.jar;C:\cvs_trabajo\lib\dom4j-1.6.1.jar;C:\cvs_trabajo\lib\ehcache-1.1.jar;C:\cvs_trabajo\lib\ejb.jar;C:\cvs_trabajo\lib\fop.jar;C:\cvs_trabajo\lib\gnu-regexp.jar;C:\cvs_trabajo\lib\gsbase-2.0.1.jar;C:\cvs_trabajo\lib\hapi_0.3.jar;C:\cvs_trabajo\lib\hcis-ant.jar;C:\cvs_trabajo\lib\hibernate3.jar;C:\cvs_trabajo\lib\ibatis-common-2.jar;C:\cvs_trabajo\lib\ibatis-sqlmap-2.jar;C:\cvs_trabajo\lib\ifxjdbc.jar;C:\cvs_trabajo\lib\imageLibrary.jar;C:\cvs_trabajo\lib\instantj-1.6.jar;C:\cvs_trabajo\lib\itext-1.3.1.jar;C:\cvs_trabajo\lib\j2ee.jar;C:\cvs_trabajo\lib\jasper-compiler.jar;C:\cvs_trabajo\lib\jasper-runtime.jar;C:\cvs_trabajo\lib\jasperreports-1.2.2.jar;C:\cvs_trabajo\lib\javassist.jar;C:\cvs_trabajo\lib\jaxen-core-1.0-fcs.jar;C:\cvs_trabajo\lib\jaxme2-0.5.jar;C:\cvs_trabajo\lib\jaxrpc-api.jar;C:\cvs_trabajo\lib\jaxrpc-impl.jar;C:\cvs_trabajo\lib\jaxrpc.jar;C:\cvs_trabajo\lib\jazzy-core.jar;C:\cvs_trabajo\lib\jboss-aop.jar;C:\cvs_trabajo\lib\jboss-aspect-library.jar;C:\cvs_trabajo\lib\jboss-aspect-library32.jar;C:\cvs_trabajo\lib\jboss-cache.jar;C:\cvs_trabajo\lib\jboss-common.jar;C:\cvs_trabajo\lib\jboss-j2ee.jar;C:\cvs_trabajo\lib\jboss-jmx.jar;C:\cvs_trabajo\lib\jboss-serialization.jar;C:\cvs_trabajo\lib\jboss-system.jar;C:\cvs_trabajo\lib\jbosssx.jar;C:\cvs_trabajo\lib\jcom.jar;C:\cvs_trabajo\lib\jcommon-0.7.1.jar;C:\cvs_trabajo\lib\jcommon-1.0.12.jar;C:\cvs_trabajo\lib\JCSC.jar;C:\cvs_trabajo\lib\jdbm-1.0.jar;C:\cvs_trabajo\lib\jdk14-pluggable-instrumentor.jar;C:\cvs_trabajo\lib\jdom.jar;C:\cvs_trabajo\lib\jep-2.24.jar;C:\cvs_trabajo\lib\jfreechart-0.9.4.jar;C:\cvs_trabajo\lib\jfreechart-1.0.8.jar;C:\cvs_trabajo\lib\jgroups.jar;C:\cvs_trabajo\lib\jmyspell.1.0_7.jar;C:\cvs_trabajo\lib\jRegistryKey.jar;C:\cvs_trabajo\lib\jrockit-pluggable-instrumentor.jar;C:\cvs_trabajo\lib\js.jar;C:\cvs_trabajo\lib\jsp-api.jar;C:\cvs_trabajo\lib\jstl.jar;C:\cvs_trabajo\lib\jta.jar;C:\cvs_trabajo\lib\jTidy.jar;C:\cvs_trabajo\lib\juh.jar;C:\cvs_trabajo\lib\junit-3.8.1.jar;C:\cvs_trabajo\lib\junit.jar;C:\cvs_trabajo\lib\junitperf-1.8.jar;C:\cvs_trabajo\lib\jurt.jar;C:\cvs_trabajo\lib\jut.jar;C:\cvs_trabajo\lib\jxl.jar;C:\cvs_trabajo\lib\log4j-1.2.14.jar;C:\cvs_trabajo\lib\log4j-1.2.8.jar;C:\cvs_trabajo\lib\logOrionLib.jar;C:\cvs_trabajo\lib\lucene-1.4.3.jar;C:\cvs_trabajo\lib\mail.jar;C:\cvs_trabajo\lib\naming-common.jar;C:\cvs_trabajo\lib\naming-factory.jar;C:\cvs_trabajo\lib\naming-java.jar;C:\cvs_trabajo\lib\naming-resources.jar;C:\cvs_trabajo\lib\ognl-2.6.9.jar;C:\cvs_trabajo\lib\ojdbc14.jar;C:\cvs_trabajo\lib\org.jar;C:\cvs_trabajo\lib\oscache-2.1.jar;C:\cvs_trabajo\lib\pmd-3.2.jar;C:\cvs_trabajo\lib\poi-2.5.1-final-20040804.jar;C:\cvs_trabajo\lib\proxool-0.8.3.jar;C:\cvs_trabajo\lib\qdox.jar;C:\cvs_trabajo\lib\rhapsody.jar;C:\cvs_trabajo\lib\ridl.jar;C:\cvs_trabajo\lib\saaj.jar;C:\cvs_trabajo\lib\saxpath-1.0-fcs.jar;C:\cvs_trabajo\lib\servlet-2.2.jar;C:\cvs_trabajo\lib\servlet-api.jar;C:\cvs_trabajo\lib\servlet.jar;C:\cvs_trabajo\lib\SOAP_SCF.jar;C:\cvs_trabajo\lib\spring-binding-1.0-rc2.jar;C:\cvs_trabajo\lib\spring-web.jar;C:\cvs_trabajo\lib\spring-webflow-1.0-rc2.jar;C:\cvs_trabajo\lib\spring-webmvc.jar;C:\cvs_trabajo\lib\spring.jar;C:\cvs_trabajo\lib\standard.jar;C:\cvs_trabajo\lib\stax-1.1.1-dev.jar;C:\cvs_trabajo\lib\stax-api-1.0.jar;C:\cvs_trabajo\lib\swarmcache-1.0rc2.jar;C:\cvs_trabajo\lib\template.jar;C:\cvs_trabajo\lib\tools.jar;C:\cvs_trabajo\lib\trove.jar;C:\cvs_trabajo\lib\unoil.jar;C:\cvs_trabajo\lib\urlrewrite-2.6.0.jar;C:\cvs_trabajo\lib\velocity-dep.jar;C:\cvs_trabajo\lib\weblogic.jar;C:\cvs_trabajo\lib\wsdl4j-1.5.1.jar;C:\cvs_trabajo\lib\wsdl4j.jar;C:\cvs_trabajo\lib\xalan-2.5.2.jar;C:\cvs_trabajo\lib\xalan.jar;C:\cvs_trabajo\lib\xbean-2.0.0-beta1.jar;C:\cvs_trabajo\lib\xercesImpl.jar;C:\cvs_trabajo\lib\xml-apis.jar"/>
        </javac>
    </target>


And the "apply code changes" button is deactivated most the time
Comment 25 gholmer 2008-09-30 18:27:39 UTC
Still seeing this with build 200809300201 of NetBeans 6.5.  I've attached a screenshot that was taken after a clean and
build, then a deploy (to an external copy of GlassFish).  Not an executable location, but then breakpoint successfully
submitted, then not an executable location, but then breakpoint hit anyway.  What is going on here?
Comment 26 gholmer 2008-09-30 18:30:24 UTC
Created attachment 70928 [details]
screenshot: first it isn't, then it is, then it isn't, then it is...
Comment 27 Jiri Kovalsky 2008-10-01 18:36:09 UTC
I believe that we have enough information now. Hence removing INCOMPLETE keyword. Any update on this? Please note that
this issue was selected by Glenn Holmer (reputable NetCAT participant) as a potential 6.5 FCS showstopper [1].

[1] http://www.nabble.com/-65cat---other--Early-CA-research-tc19665753.html
Comment 28 Martin Entlicher 2008-10-01 19:25:05 UTC
Glen, how many classes com.weycogroup.phoenix.storefront.CategoryBean do you have?
It looks like there are three of them loaded according to the screenshot. In the first one there was no location defined
for line 239, in the second there was, thus the breakpoint was successfully submitted. And in the third, again, no such
location was found.

Does this imply any functional problems?

Can you please provide some sample project that would demonstrate this behavior? I have never had a problem of this kind.
Comment 29 Martin Entlicher 2008-10-01 19:34:40 UTC
A sample project and steps to reproduce would be the best. But if you can not provide it, please use
-J-Dorg.netbeans.modules.debugger.jpda.level=400 option as described above and attach the message.log generated after
the described situation occurs. This can, at least, provide some hint of what's going on there. Thanks.
Comment 30 gholmer 2008-10-01 20:04:36 UTC
> Glen, how many classes com.weycogroup.phoenix.storefront.CategoryBean do you have?
Exactly one.

> please use -J-Dorg.netbeans.modules.debugger.jpda.level=400
I have turned this on again.
Comment 31 gholmer 2008-10-02 16:42:35 UTC
I'm adding another log file and screen dump.
I was debugging an enterprise app using an external copy of GlassFish (using "Attach Debugger).
I detached the debugger, made a change, did a clean and build, then a deploy.
When I started the debugger again, I saw what's in the screen dump.
I have done a "Clone Document" on CategoryBean.java after it occurred but before taking the screen dump, so you can see
both lines at the same time.
There is only one of these files in the project.
Comment 32 gholmer 2008-10-02 16:43:17 UTC
Created attachment 71059 [details]
log file
Comment 33 gholmer 2008-10-02 16:43:50 UTC
Created attachment 71060 [details]
screen dump
Comment 34 Martin Entlicher 2008-10-02 16:56:34 UTC
Aha, I see what's going on now. There are several copies of each class loaded by different class loader.
The GlassFish apparently contains all classes that were ever deployed. Therefore when breakpoints are submitted, they
are naturally trying to be submitted into all these copies. And when line number changes, it can easily happen that some
locations in some copies becomes invalid (there is no executable code). This is why you get notification that the
breakpoint is invalid and subsequently it's successfully submitted into a different copy of the same class.

IMHO this is a defect of the GlassFish, since you probably do not care about the old copies, which only take up space.
But I might be wrong. If it is desired to have multiple different copies loaded, I will try to find some solution how to
silently ignore the invalid messages.
Comment 35 noot 2008-10-03 01:40:36 UTC
I'm using Tomcat with the same problems. If it's a Glassfish problem then Tomcat is using the same class loading
mechanism. Possible.
Comment 36 Jiri Kovalsky 2008-10-03 12:02:56 UTC
This bug is considered as potential showstopper [1] by NetCAT 6.5 participant. Adding [65cat] prefix.

[1] http://www.nabble.com/-65cat---other--Early-CA-research-tp19665753p19748154.html
Comment 37 Martin Entlicher 2008-10-03 17:28:22 UTC
Easily reproducible even with the latest glassfish-v3-prelude-b27.
The classes are cumulating on the server. I'll submit a defect for that.

However, the breakpoint validity becomes useless here, since we can not know which version of the class is going to be
actually used. Therefore you could have "valid" breakpoints for empty lines which are, by chance, valid in some old copy
of the class.

I do not see a clean solution to this. It will, most likely, NOT be fixed into 6.5, sorry.
Comment 38 Martin Entlicher 2008-10-03 17:41:59 UTC
I've submitted https://glassfish.dev.java.net/issues/show_bug.cgi?id=6416
Comment 39 Martin Entlicher 2008-10-03 17:57:32 UTC
I can only think of some maybe GlassFish-specific (and perhaps Tomcat-specific) fix if we'll be able to find out which
class loader is the newest one (which will be actually used).
Comment 40 Petr Jiricka 2008-10-08 10:49:53 UTC
The GlassFish issue was just fixed, could someone please try to verify with the latest nightly build of v3 Prelude?
Cc'ing Peter W and Vince. Martin, thanks a lot for the investigation!
Comment 41 Vince Kraemer 2008-10-31 16:19:02 UTC
*** Issue 148315 has been marked as a duplicate of this issue. ***
Comment 42 bht 2008-12-23 09:46:34 UTC
I have a terrible time with this with the current version NetBeans 6.5 and glassfish-v2ur2, all updated to the latest
level. Invalid breakpoints. Now I don't know how to get the debugger to work at all.
Somehow sources from the favorites window were automatically added to the debugger sources window. Is this allowed to
happen? I wrote a program to search my drives for all duplicate classes including within jar files on my harddrive.
Deleted all, including from the netbeans cache. Re-started NetBeans multiple times. Cleaned, closed, re-opened the
project. Now the debugger does not stop on breakpoints anymore. It appears to me that there are multiple issues that are
quite toxic in combination. I have had another more obvious problem with NetBeans/glassfish when trying to re-build
projects even when they are undeployed from the server:
nbproject\build-impl.xml:398: Unable to delete file dist\gfdeploy\Member-war_war\WEB-INF\lib\wicket-extensions-1.3.5.jar
There are multiple issues and symptoms. Therefore I think that this should have a high priority.
Comment 43 bht 2008-12-23 10:46:29 UTC
Debugger worked again after I re-added the source root to the sources window. A couple of source code changes, deployed,
and all breakpoints are broken again.

I think it would be good to add a function to add the project's source root if a breakpoint is set on a project file
whose source root is not included in the sources window. But that does not solve the problem, it just demonstrates who
many issues exist in this field.
Comment 44 Martin Entlicher 2008-12-28 09:46:24 UTC
Nothing from Favourites window is added to debugger sources. Only current project and all it's dependent projects.

There is no known mechanism how a project's source root is "automatically" removed from the Sources window.

Was not the problem with not working breakpoints caused by your delete of all classes and JAR files?

GlassFish keeps multiple classes loaded for the same source code. Unless they have already fixed this (I'll check it)
this is causing breakpoints to be falsely marked as invalid. Though they should still work fine.
Comment 45 Vince Kraemer 2009-01-04 19:46:27 UTC
Please note that the GF side of this is marked as fixed for GF v3 and GF v2.1...

Are you running into this problem when you use GF v2.1 instead of GF v2 ur 2?

More info about v2.1 is available from http://wiki.glassfish.java.net/Wiki.jsp?page=PlanForGlassFishV2.1
Comment 46 Jayashri Visvanathan 2009-01-09 22:16:29 UTC
Has this been verified for Glassfish 2.1/V3 ? Can this issue be closed ?
Comment 47 noot 2009-01-10 00:30:10 UTC
This issue still exist for tomcat
Comment 48 Jayashri Visvanathan 2009-01-12 21:20:09 UTC
From the discussions so far, it doesn't look like j2ee issue. If the fix to Glassfish fixed your problem, then it must
be a bug in the server side, you would have to file an issue against Tomcat and get the issue addressed. 
Martin, do you see anything that we can do to fix this ? 
thanks
Comment 49 gholmer 2009-01-14 17:42:36 UTC
Sorry not to have responded, we've been doing a lot of R&D and very little debugging.

But one of the guys on my team got this same bug today (see attachment).  He's running build b56 of GlassFish 2.1.
Comment 50 gholmer 2009-01-14 17:43:38 UTC
Created attachment 75837 [details]
screenshot
Comment 51 Vince Kraemer 2009-01-14 20:33:22 UTC
thanks for the update.
Comment 52 gholmer 2009-01-23 20:13:45 UTC
See attached screenshot. All the messages about line 40 came from a single remote debugger attach. Using GlassFish 2.1 GA.
Comment 53 gholmer 2009-01-23 20:15:18 UTC
Created attachment 76194 [details]
screenshot
Comment 54 Vince Kraemer 2009-01-23 21:41:20 UTC
after reading through the comments in this issue it appears that many servers have a similar 'bug'.

So, we may want to examine how the debugger works against the current environment while we wait for various servers to
address the issues that we have raised.
Comment 55 Petr Jiricka 2009-02-11 15:44:25 UTC
Also, from the description it sounds like the workaround should be to restart the server, and avoid running multiple
applications that use the same classes. Does this workaround help?
Comment 56 noot 2009-02-12 01:22:35 UTC
Yes, restarting helps with Tomcat. That's how I work around it.

I'm now investigating if the problem arises when deploying with and without the debugger attached. It also seems to have
some effect.
Comment 57 Petr Jiricka 2009-02-12 13:25:36 UTC
I assume the same workaround also applies to GlassFish - changing priority to P2 for now.

Martin E, if we are not able to fix this issue properly (though we will keep trying), do you think it would be possible
to change the error message to include the hint that server restart will help? Thanks.
Comment 58 gholmer 2009-02-12 13:57:43 UTC
Naturally, restarting the server helps... but imagine the impact of that while working on a large application.  I just
ignore the error messages because I know the debugger will break on those lines anyway... but it's very untidy.
Comment 59 Petr Jiricka 2009-03-19 09:56:35 UTC
Looks like this issue will be hard to fix, especially since for NB 6.7, we will use GF v2.1, so any fix in v3 will not
help. I suggest to waive this bug for 6.7.
Comment 60 Petr Jiricka 2009-03-31 13:21:49 UTC
Waived for NB 6.7.
Comment 61 Martin Entlicher 2009-06-17 12:44:45 UTC
I'll try to resolve this somehow into 6.8.
The fact that the server holds several class types for the same class name may cause also other problems to NetBeans
debugger. For instance issue #163249 was caused by this.
Comment 62 Martin Entlicher 2009-06-19 12:18:52 UTC
In general, it's impossible to provide correct breakpoint badging when the application loads several classes with
identical names and when line numbers of these classes differ. I can easily write an application, that will load several
classes of one name with shifted line numbers and execute randomly different classes.
Then breakpoint submitted to particular line will randomly either work or not, depending on whether it happens to be on
an executable line in the given class or not. One breakpoint can be valid in some classes, while invalid in others.

It's also possible (and this happens with the Glassfish server), that initially, when debugger is being connected, all
classes of the given name that are loaded in the VM are already outdated, have old line numbers and thus breakpoints in
these classes are marked as invalid (suppose that line numbers point to empty lines in these old classes).
But then a new, updated, class is loaded into the VM with up-do-date line numbers. Then the breakpoint is marked  as
valid. But the error messages about invalid breakpoints remain in the Output window.
Such breakpoint is valid only in the newest class, not in others. Glassfish seems to use the newest class only, but not
all applications have to behave that way.
Comment 63 Martin Entlicher 2009-06-22 14:28:07 UTC
Should be fixed in changeset:   135792:0cd5a8599734
We try to recognize staled classloaders and submit breakpoints only to the classes that are loaded by active class loaders.
http://hg.netbeans.org/main/rev/0cd5a8599734
Comment 64 Quality Engineering 2009-06-23 07:42:26 UTC
Integrated into 'main-golden', will be available in build *200906230201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/0cd5a8599734
User: mentlicher@netbeans.org
Log: #115033 - When more classes of the same name are loaded in the system when a breakpoint is to be submitted, select the preferred class and mark the breakpoint validity based on the preferred class. This works fine for glassfish server, whose staled class loaders have null parent. Inform also about partially submitted breakpoints.
Comment 65 gholmer 2009-06-23 13:41:59 UTC
Any chance of this going into 6.7, even as a hotfix?
Comment 66 Jiri Kovalsky 2009-06-23 13:45:48 UTC
Glenn, can you please confirm that it works fine for you in the #200906230201 development build? Thanks!
Comment 67 Martin Entlicher 2009-06-23 13:47:37 UTC
In case it helps and if it's verified, I guess it can be added into the 67 patch.
Comment 68 gholmer 2009-06-23 14:47:49 UTC
I'm sorry to say, attaching the debugger to a running copy of GlassFish with build 20090623 locks up the IDE and is
repeatable.  See attached log file and thread dump.
Comment 69 gholmer 2009-06-23 14:48:40 UTC
Created attachment 83934 [details]
thread dump
Comment 70 gholmer 2009-06-23 14:49:53 UTC
Created attachment 83935 [details]
log file from userdir
Comment 71 Martin Entlicher 2009-06-23 14:58:30 UTC
This deadlock does not seem to be caused by this fix. It's already submitted in issue #167444 and was fixed just today.
So please try the next build, it will hopefully work fine.
Comment 72 gholmer 2009-06-24 19:02:31 UTC
I've been working with 200906240201 all morning, doing intensive remote debugging with GlassFish, and have not seen a
single invalid breakpoint badge.  As far as I can see, the debugger is always stopping where it should.

From my perspective, this is fixed.  I would love to see it go into 6.7.
Comment 73 Martin Schovanek 2009-07-02 10:42:15 UTC
v.
Comment 74 pgebauer 2009-07-03 14:26:04 UTC
The fix has been ported into the release67_fixes repository.
http://hg.netbeans.org/release67_fixes/rev/65fb554b7a48
Comment 75 bht 2009-07-09 01:29:09 UTC
The last comment reads that this is fixed in 6.7. But I see the same bug in 6.7 on a daily basis. My results are
actually worse. After a complete clean, deploy and debug sequence, the debugger stops on some breakpoints but not on others.

I read on https://glassfish.dev.java.net/issues/show_bug.cgi?id=6416 that the issue still persists.

So how can this be closed then?

I am extremely frustrated, and I would not be surprised if the hard working people at Sun, and in the NetBeans team are
frustrated, too.

So my thinking is now that we, the users need to help the Sun server developers and the NetBeans developers to escalate
this, to put it in perspective, in order not to lose users due to frustration.

If for example, I was a development team leader or development manager, then I would not even dream of recommending
NetBeans as a viable development environment for J2EE development. The first developer would shoot me down. I personally
like NetBeans and I use it, and I have not given up yet, but I think I am losing.

Well, it is the server not NetBeans you may say, and possibly rightly so. But the server comes with NetBeans out of the
box, and we would expect it to be the best choice.

There are other persisting and very frustrating issues with NetBeans: 

issue 145666 "Source root's non-class files not included on Auto deploy" and  issue 152222 "Unnecessary redeploys by
'deploy on save'". This is a toxic mix and I ask myself what is going on here, who can use NetBeans to develop server
software? It is very sad to see that while there are so many brilliant features in this software, the daily work with
NetBeans can be so utterly unproductive and frustrating.
Comment 76 Petr Jiricka 2009-07-09 09:45:24 UTC
Bernard, actually, release67_fixes is different from "NetBeans 6.7". The previous comment means that this fix will be
available in Patch 1 for NetBeans 6.7 (also known as 6.7.1). So it is not fixed in 6.7. Patch 1 will be available by the
end of July. If you want to test it now, you can also use the NetBeans 6.8 daily builds:
http://bits.netbeans.org/netbeans/trunk/nightly/

Changing back to FIXED.
Comment 77 Petr Jiricka 2009-07-09 09:46:26 UTC
... and VERIFIED.
Comment 78 Martin Entlicher 2009-07-09 09:47:28 UTC
Please note, that the "Target milestone" here is still "6.8". Therefore this issue is *not* fixed in 6.7.

The fix has been integrated into patch1 for 6.7, which is not publicly available yet, AFAIK.

Let's wait how it will work for you after you install the patch with this fix.
Comment 79 Martin Entlicher 2009-07-09 09:47:59 UTC
v.
Comment 80 Jindrich Sedek 2009-07-17 13:27:46 UTC
verified in 6.7.1 RC
NetBeans IDE 6.7.1 RC (Build 200907162301)

The fix will be available next week as 6.7.1 and also in patch for 6.7
Comment 81 Martin Entlicher 2009-07-24 22:37:49 UTC
*** Issue 168380 has been marked as a duplicate of this issue. ***
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo