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.
Summary: | [mixeddev] java.util.MissingResourceException: No such bundle org.netbeans.modules.cnd.mixeddev.debugger.Bundle | ||
---|---|---|---|
Product: | cnd | Reporter: | Chiana |
Component: | Mixed Development | Assignee: | Vladimir Kvashin <vkvashin> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | anebuzelsky, soldatov |
Priority: | P1 | Keywords: | 81_HR_FIX |
Version: | 8.1 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | 220596 |
Attachments: | stacktrace |
Description
Chiana
2015-10-17 11:51:39 UTC
Created attachment 156766 [details]
stacktrace
Also this makes IDE occationally to hang completley and must be killed with taskmanager. Easy to reproduce. In CndSessionChanger.java:88 there is a call to NbBundle.getMessage(this.getClass(),...) but there is no resource bundle in the package. So the fix should be quite primitive and safe. Exactly this exception should be fixed. If user installed full IDE and code contains Thread.sleep(200), then MissingResourceException appears. Kent, thank you very much for filing this! As to IDE hangup: can you reproduce this? Could you do this and get full thread dump? (To do this, you can use jps command to get java process pid and jsctack command to get full thread dump). If you succeed, could you please file a separate bug and attach thread dump to it? Thank you! Vladimir (In reply to soldatov from comment #3) > Easy to reproduce. I have some doubts that it happens when stepping *over*. My understanding is that it happens when trying to step *into*. (The filer could just make a mistake and, e.g. probably pressed F7 while intended to press F8). This bug should be fixed in any case, but if CndSessionChanger is called for each stepping *over* a native call and invoke a ps each time - this is dangerous and can slow down debugging very much. So in this case we should file a separate bug and fix it. I checked this (although in trunk, not release81) on my Ubuntu and in debugger and I see that we don't get into CndSessionChanger when stepping *over*. But who nows, probably in other circumstances (Windows?) we can? Please check this. (In reply to Vladimir Kvashin from comment #6) > Kent, thank you very much for filing this! > > As to IDE hangup: can you reproduce this? > Could you do this and get full thread dump? (To do this, you can use jps > command to get java process pid and jsctack command to get full thread > dump). If you succeed, could you please file a separate bug and attach > thread dump to it? > > Thank you! > Vladimir You are most welcome. The hangs seems to be intermittent and the entire jvm seems to be hanging and I tried to make a dump but it did not work. My guess is that there is a bug in the jvm itself that causes the hang because only a "taskkill /F <pid>" seems able to terminate it. (In reply to Vladimir Kvashin from comment #7) > (In reply to soldatov from comment #3) > > Easy to reproduce. > I have some doubts that it happens when stepping *over*. > My understanding is that it happens when trying to step *into*. > (The filer could just make a mistake and, e.g. probably pressed F7 while > intended to press F8). > > This bug should be fixed in any case, but if CndSessionChanger is called for > each stepping *over* a native call and invoke a ps each time - this is > dangerous and can slow down debugging very much. So in this case we should > file a separate bug and fix it. > > I checked this (although in trunk, not release81) on my Ubuntu and in > debugger and I see that we don't get into CndSessionChanger when stepping > *over*. But who nows, probably in other circumstances (Windows?) we can? > > Please check this. You are correct, it was "step into" (F7) Sorry for that mistake! fixed in cnd-main: http://hg.netbeans.org/cnd-main/rev/d9aa4b6adda8 (In reply to Chiana from comment #8) > ... <skipped> ... > The hangs seems to be intermittent and the entire jvm seems to be hanging > and I tried to make a dump but it did not work. My guess is that there is a > bug in the jvm itself that causes the hang because only a "taskkill /F > <pid>" seems able to terminate it. That's just for your information. Stepping into a native method works as follows: - NB finds java process PID (initial report concerned exactly the situation when PID wasn't found, so NB tried to report this and couldn't find message bundle) - NB attaches to this process with native debugger; at this moment the process is stopped - NB sets a breakpoint in appropriate method - NB releases the java process So there is a period when the java process is stopped. (But sure only in the case PID is found). So in general, stepping into a native method can stop java process, in which case you won't be able to get a thread dump. (In reply to Vladimir Kvashin from comment #11) > (In reply to Chiana from comment #8) > > ... <skipped> ... > > The hangs seems to be intermittent and the entire jvm seems to be hanging > > and I tried to make a dump but it did not work. My guess is that there is a > > bug in the jvm itself that causes the hang because only a "taskkill /F > > <pid>" seems able to terminate it. > > That's just for your information. > > Stepping into a native method works as follows: > - NB finds java process PID (initial report concerned exactly the situation > when PID wasn't found, so NB tried to report this and couldn't find message > bundle) > - NB attaches to this process with native debugger; > at this moment the process is stopped > - NB sets a breakpoint in appropriate method > - NB releases the java process > > So there is a period when the java process is stopped. > (But sure only in the case PID is found). > > So in general, stepping into a native method can stop java process, in which > case you won't be able to get a thread dump. Hmmm... To my knowledge I do not have a native debugger installed unless there is one in NB that I don't know about. This particular application that I am working on uses a lot of native calls (mostly JNI). Integrated into 'main-silver', will be available in build *201510200002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/d9aa4b6adda8 User: Vladimir Kvashin <vkvashin@netbeans.org> Log: fixed #255983 - [mixeddev] java.util.MissingResourceException: No such bundle org.netbeans.modules.cnd.mixeddev.debugger.Bundle Looks a little better now, a nice box saying it can't find the native process, a little unbalanced thou... Some cosmetic mockup later perhaps... This needs to be backported to release81 today and marked as 81_HR_FIX. Transplanted to releases~release81: hg.netbeans.org/releases/rev/e171e7046bd3 - [fixed #255983 - [mixeddev] java.util.MissingResourceException: No such bundle org.netbeans.modules.cnd.mixeddev.debugger.Bundle] |