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: | RTC does not work for experiment | ||
|---|---|---|---|
| Product: | cnd | Reporter: | Thomas Preisler <thp> |
| Component: | Project | Assignee: | Thomas Preisler <thp> |
| Status: | VERIFIED FIXED | ||
| Severity: | blocker | CC: | sustaining |
| Priority: | P2 | ||
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
Fixed. Now expanding macros in MakeConfiguration.getAbsoluteOutputValue() Integrated into 'main-golden', will be available in build *200810271401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/2d26755b99ac User: Thomas Preisler <thp@netbeans.org> Log: #151208 RTC does not work for experiment can not be verified without SS build Is this issue verified or not? It is in verified state, but the last comment says that it "can not be verified without SS build"... So what is the real status of this issue? It has been verified by Ivan in a private build. Alexander, I think you can go ahead and mark it verified. verified The fix was ported into release65_fixes repository. http://hg.netbeans.org/release65_fixes/rev/a42e6f635331 verified in SSIDE with patch1 SS IDE is now based on NB 5.4 patch 1 |
From CR 6762026 Steps to reproduce: - download and untar attached test projects rtc.tar (configured for Solaris Sparc) - run IDE - open rtc_basic_1 project from .../rtc/projects/ - call Advanced->Runtime Memory Checking->Start Result: 'Starting Debugging' window appears with a message 'Connecting to Dbx' and a progress bar. When window disappears 'Runtime Memory Checking' panel contains empty tabs 'Access Errors', 'Memory Usage' and 'Memory Leaks'. RTC works fine while debugging. *** (#1 of 1): 2008-10-21 11:39:36 PDT alexander The root cause of this is that the Build.Linker.Output property of the configuration contains a string like this: dist/Debug/${PLATFORM}/rtc_basic_1 In batch mode we access this property MakeConfiguration.getAbsoluteOutputValue(). Which returns an excutable path with an embedded ${PLATFORM}. I do not believe that the contract for MC.gAOV() allows for embedded "variables". I believe this does warrant a P2 because the ${PLATFORM} is always present and will always gum things up. How come the debugger doesn't suffer from this? That is because the debugger startup code gets called from the bowels of CND project code and uses ProjectActionEvent.getExecutable() where the ${} variable has been pre-expanded by CND. Does ATD provide an analog of this? ATAction.collect() gets a Map and it looks like it contains an expanded executable path embedded in it in a strange way. See ProfilableProjectProvider.toString(). But this doesn't look official enough. At this point this seems to be a CND/ATD problem: a) What is the contract for MakeConfiguration.getAbsoluteOutputValue()? "Absolute" is a term used in file names and paths so the implication of the _name_ of this method is that it will return a pathname ... w/o embedded ${}'s. b) If CND wants to renage on this how can I get at the expanded executable name in ATD? *** (#1 of 4): 2008-10-21 13:47:41 PDT ivan A secondary prolem is that when dbx encounters this bad eecutable with an embeded ${} it posts an error but dbxgui doesn't handle this error gracefully enough. I filed a separate CR 6762119 on this. *** (#2 of 4): 2008-10-21 13:51:51 PDT ivan *** Last Edit: 2008-10-21 13:55:13 PDT ivan you can call path = configuration.expandMacros(path); to work around the problem. ATD should expand the code for you. *** (#3 of 4): 2008-10-21 14:01:27 PDT thomas I can call expandMacros() ... What happens if some macros are unexpandable? It doesn't make sense to talk about ATD pre-expanding because AFAIK there's no API for providing the executable name to begin with. However, are you willing to consider the return of MakeConfiguration.getAbsoluteOutputValue() as buggy? *** (#4 of 4): 2008-10-22 13:56:21 PDT ivan Yes, MakeConfiguration.getAbsoluteOutputValue() should probably expand the macros.