Closed Bug 21317 Opened 25 years ago Closed 25 years ago

UMR: nsCAutoString::=(nsCAutoString const&)

Categories

(Core :: XPCOM, defect, P3)

x86
Windows NT
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: kinmoz, Assigned: kinmoz)

References

Details

While running purify on WinNt, I see over a hundred occurrences of the following UMR in nsCAutoString::=(): [W] UMR: Uninitialized memory read in nsCAutoString::=(nsCAutoString const&) {40 occurrences} Reading 1 byte from 0x0013eb50 (1 byte at 0x0013eb50 uninitialized) Address 0x0013eb50 points into a thread's stack Address 0x0013eb50 is 48 bytes past the start of local variable 'chromeFile' in nsChromeRegistry::InitializeDataSource(nsString&,nsString&,nsIRDFDataSource * *,int) Thread ID: 0x125 Error location nsCAutoString::=(nsCAutoString const&) [xpcom.dll] nsChromeRegistry::InitializeDataSource(nsString&,nsString&,nsIRDFDataSource * *,int) [nsChromeRegistry.cpp:745] nsChromeRegistry::ConvertChromeURL(nsIURI *) [nsChromeRegistry.cpp:527] nsChromeProtocolHandler::NewChannel(char const*,nsIURI *,nsILoadGroup *,nsIInterfaceRequestor *,UINT,nsIURI *,UINT,UINT,nsIChannel * *) [nsChromeProtocolHandler.cpp:371] nsIOService::NewChannelFromURI(char const*,nsIURI *,nsILoadGroup *,nsIInterfaceRequestor *,UINT,nsIURI *,UINT,UINT,nsIChannel * *) [nsIOService.cpp:250] nsDocumentOpenInfo::Open(nsIURI *,int,char const*,nsISupports *,nsIURI *,nsIInputStream *,nsISupports *,nsISupports * *) [nsURILoader.cpp:168] nsURILoader::OpenURIWithPostDataVia(nsIURI *,int,char const*,nsISupports *,nsIURI *,nsIInputStream *,nsISupports *,nsISupports * *,UINT) [nsURILoader.cpp:418] nsURILoader::OpenURIVia(nsIURI *,int,char const*,nsISupports *,nsIURI *,nsISupports *,nsISupports * *,UINT) [nsURILoader.cpp:375] nsURILoader::OpenURI(nsIURI *,int,char const*,nsISupports *,nsIURI *,nsISupports *,nsISupports * *) [nsURILoader.cpp:361] nsDocLoaderImpl::LoadDocument(nsIURI *,char const*,nsISupports *,nsIInputStream *,nsISupports *,UINT,UINT,WORD const*) [nsDocLoader.cpp:609] The problem seems to be in the VC++ 6.0 compiler code that calls operator= when you have code that looks something like: nsCAutoString chromeFile, overlayFile; chromeFile = "chrome/"; overlayFile = chromeFile; //<------ Here's where the UMR occurs! We can get rid of the UMR by defining an operator= that takes an nsCAutoString& reference as an arg. If someone code reviews this patch, I can check it in: Index: nsString.h =================================================================== RCS file: /cvsroot/mozilla/xpcom/ds/nsString.h,v retrieving revision 3.53 diff -r3.53 nsString.h 723a724 > nsCAutoString& operator=(const nsCAutoString& aString) {nsCString::Assign(aString); return *this;}
Ugghh 5.0 munged the summary. This is what the sample code that generates the UMR should look like: nsCAutoString chromeFile, overlayFile; chromeFile = "chrome/"; overlayFile = chromeFile; //<------ Here's where the UMR occurs!
Status: NEW → ASSIGNED
Target Milestone: M13
Accepting bug. Marking M13. Should this go in for M12?
In my haste, I failed to define an operator= for nsCAutoString. Feel free to add it and check it in. I can't say why this would lead to a UMR though, because it ultimately forwards the assignment to nsCString::Assign(). Hmm. Rick
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Target Milestone: M13 → M12
Fix checked in: mozilla/xpcom/ds/nsString.h revision 3.54 r=rickg@netscape.com a=chofmann@netscape.com
*** Bug 20949 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.