208579 - regression: new MSVC 6 debugger problems with NSS libs

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect, P2)

Description

[Nelson Bolyard (seldom reads bugmail)]

Sometime in the last 90 days, a new problem arose when trying to use the source 
debugger in MSVC 6 with debug versions of NSS libraries.  The problem is that
some (many) breakpoints can no longer be disabled or removed through the GUI.

After seeing a breakpoint, a black dot appears next to the line on which it was
set.  Thereafter, it should be possible to disable or remove that breakpoint 
by merely setting the cursor on that line and clicking the UI button to remove
or disable the breakpoint, or by right clicking on that dot or line and
selecting remove or disable in the pop-up menu.  

For years, that worked just fine.  Now when you do those steps, often it 
has no effect.  The breakpoint is neither removed nor disabled.  This makes
debugging MUCH more inefficient.  The work around is to find the line number
in the file where the brakpoint it set, then bring up the UI list of
breakpoints, and disable or remove the breakpoint from that list.  This is 
very slow, compared to just a couple clicks.  

I suspect that this regression was caused by one of two changes that were 
made to how NSS is built for Windows with MSVC.  Those two changes were
the fixes for bug 202058 and for bug 95138.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

P2 for 3.9, if not sooner

Comment 2

[Julien Pierre]

Nelson,

Do you have a test application that shows this problem ?
What source file and DLL were you trying to put breakpoints in ?
Some DLLs are loaded on-demand (softokn3, nssckbi) so the debugger behavior may
be different.

Comment 3

[Julien Pierre]

Nelson,

I could not reproduce the problem on my machine. The debugger works as expected
when setting/unsetting breakpoints in the source.

Comment 4

[Julien Pierre]

Talked to Nelson.
I'm able to add or remove breakpoints, however disabling the breakpoint using
the icon or context menu doesn't work.
I have verified this is a regression since NSS 3.7 . I will investigate which of
the two bug fixes may have caused this regression.

Comment 5

[Julien Pierre]

It is the patch for 202058 that makes the difference.
However, I think this is a bug in MS Dev studio, and I'm not sure what I can do
about it. 

I have verified that reverting to the relative pathname, which can be done in a
one line patch - simply hardcoding the $abspath function in coreconf/rules.mk to
$(1) - fixes the problem.

I noticed that the PATHs were being specified with forward slashes rather than
backslashes, so I tried changing that as well, but it had no impact. The only
thing I could do that allowed me to disable breakpoints from the context menu
was to remove the absolute paths.

That said, the breakpoints CAN be disabled, you just have to go to
edit/breakpoints to do it, and can't do it from within the source.
You do indeed have to check the filename and line number before doing it, as
Nelson says.

This is arguably a problem. The problem that the patch solved by using absolute
paths was also serious. It seems we can't have everything with VC6's debugger.

The only good news I can offer is that when I build and debug with VC7 and its
debugger, this bug does not show up.
I would suggest it's time to move to a new compiler anyway - VC6 is very old.
Even the VC7 I used is from 2001 . Microsoft has a new compiler for 2003 also.

Comment 6

[Julien Pierre]

This issue is caused by two things :
1) a bug in the MSVC 6 debugger
2) a patch to NSS which put the MSVC bug in evidence

I can't fix the first issue . But MSVC7 will work.
I could resolve the second issue, but that will break bugs 202058 and 95138.

I'm of the opinion that having to open all the files by hand is a more serious
problem than having to go to the breakpoints window to disable breakpoints, so
I'm marking this WONTFIX.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

It was not necessary to open all the source files by hand.  
It was only necessary to open the first file in each directory by hand.
After doing so, MSVC found all the other sources in the same directory.

But for now, I'm OK with leaving the resolution as is.