[cvsnt] bug in cvs(nt)?
pgarceau at comcast.net
Thu Jun 10 20:02:44 BST 2004
Not sure what the policy is re: attachments, etc.
I have already been interfacing with the WinCVS folks, and they tell me that this looks to be a cvs.exe bug.
I am using NT4.
What is necessary to do in order to confirm that this performance is a bug?
This "possible bug" occurs when "cvs info" is called from WinCVS.
Here is a brief recap:
> I received an error. Understand, the module I am attempting to checkout, in
> this case, already exists on my box.
> (I captured the screen image, and I am not sure if it is ok to attach the
> .jpg images to this reply or not. They are approximately 98kb and 48kb.)
(Generated after "cvs info" was sent by WinCVS to CVSNT)
"Something bad happened to CVSNT, and it crashed. Unfortunately DBGHLP.DLL is missing so we can't
produce a crash dump."
Typing "cvs info" at the command line for WinCVS produced an identical result.
ext ext 2.0.41a
fork fork 2.0.41a
ntserver ntserver 2.0.41a
pserver pserver 2.0.41a
server server 2.0.41a
sserver sserver 2.0.41a
ssh ssh 2.0.41a
> After I acknowledged the first error, cvs.exe threw this exception (from
> cvs.exe application error):
> "The exception unknown software exception (0xc06d007e) ocurred in the
> application at location 0x77f1d642."
I have a JIT debugger (DrMingw) if that would be helpful. The one time I did catch the information generated from
the JIT debugger, "get_protocol"... was referenced.
Next is what occurred on the WinCVS (client) side. Not necessarily applicable to cvsnt.
[> After acknowledging that particular error, I was given a similar CVSROOT
> dialog box to what you, Oliver, were referencing in the link above
(See link for example: CVSROOT)
> The first thing I noticed then was that there were no values assigned to
> any of the CVSROOT descriptions.
Last bit indicates that CVSNT did not return the appropriate values to WinCVS.
I hope this is helpful.
More information about the cvsnt