Closed
Bug 576680
Opened 14 years ago
Closed 14 years ago
"Conditional jump or move depends on uninitialised value(s) / nsPrefBranch::GetIntPref(char const*, int*) (nsPrefBranch.cpp:247)"
Categories
(Core :: IPC, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: cjones, Assigned: cjones)
Details
(Keywords: valgrind)
Attachments
(1 file)
Got this several times valgrind'ing test-ipc.xul. Not sure if fennectrolysis has the same bug, will see what's up. ==11476== Conditional jump or move depends on uninitialised value(s) ==11476== at 0x5C6200E: nsPrefBranch::GetIntPref(char const*, int*) (nsPrefBranch.cpp:247) ==11476== by 0x6D00F08: nsNavHistory::LoadPrefs() (nsNavHistory.cpp:2115) ==11476== by 0x6CF3E9F: nsNavHistory::Init() (nsNavHistory.cpp:428) ==11476== by 0x6CF2B12: nsNavHistory::GetSingleton() (nsNavHistory.cpp:376) ==11476== by 0x6D63ED3: nsNavHistoryConstructor(nsISupports*, nsID const&, void**) (nsPlacesModule.cpp:15) ==11476== by 0x70C24D6: mozilla::GenericFactory::CreateInstance(nsISupports*, nsID const&, void**) (GenericFactory.cpp:48) ==11476== by 0x7126EFB: nsComponentManagerImpl::CreateInstanceByContractID(char const*, nsISupports*, nsID const&, void**) (nsComponentManager.cpp:1148) ==11476== by 0x7127C63: nsComponentManagerImpl::GetServiceByContractID(char const*, nsID const&, void**) (nsComponentManager.cpp:1510) ==11476== by 0x70B0E80: CallGetService(char const*, nsID const&, void**) (nsComponentManagerUtils.cpp:94) ==11476== by 0x70B13C1: nsGetServiceByContractID::operator()(nsID const&, void**) const (nsComponentManagerUtils.cpp:278) ==11476== by 0x6B2FA00: nsCOMPtr<nsINavHistoryService>::assign_from_gs_contractid(nsGetServiceByContractID, nsID const&) (nsCOMPtr.h:1252) ==11476== by 0x6B2F0C0: nsCOMPtr<nsINavHistoryService>::nsCOMPtr(nsGetServiceByContractID) (nsCOMPtr.h:627) ==11476==
Assignee | ||
Comment 1•14 years ago
|
||
This is caused by nsresult rv; PRInt32 retval; cpc->SendGetIntPref(nsDependentCString(getPrefName(aPrefName)), &retval, &rv); if (NS_SUCCEEDED(rv)) *_retval = retval; return rv; where apparently the |cpc->SendGetIntPref()| is failing because of a closed channel. Not a huge deal since the content process would be _exit()ing soon thereafter, but I think it's worth initializing rv with NS_ERROR_NOT_AVAILABLE here (and nearby) if only to shut valgrind up.
Assignee | ||
Comment 2•14 years ago
|
||
Assignee: nobody → jones.chris.g
Attachment #455805 -
Flags: review?(dwitte)
Comment 3•14 years ago
|
||
Comment on attachment 455805 [details] [diff] [review] Initialize |rv| so that valgrind doesn't complain (though it's technically unnecessary) and add a helper function to cut some LoC > #ifdef MOZ_IPC >- if (XRE_GetProcessType() == GeckoProcessType_Content) { >- mozilla::dom::ContentProcessChild *cpc = >- mozilla::dom::ContentProcessChild::GetSingleton(); >- NS_ASSERTION(cpc, "Content Protocol is NULL!"); >- >+ if (ContentProcessChild* cpc = GetContentProcessChild()) { > nsAutoString prefValue; > cpc->SendGetPrefLocalizedString(nsDependentCString(getPrefName(aPrefName)), > &prefValue, &rv); > if (NS_FAILED(rv)) return rv; We should init 'rv' here too, right? It'll be set to NS_OK from the prior call. Should we be checking the return value of the Send* methods instead? I initially thought they aborted on failure but I guess they just return false in the closed channel case :/ r=dwitte either way.
Attachment #455805 -
Flags: review?(dwitte) → review+
Assignee | ||
Comment 4•14 years ago
|
||
(In reply to comment #3) > (From update of attachment 455805 [details] [diff] [review]) > > #ifdef MOZ_IPC > >- if (XRE_GetProcessType() == GeckoProcessType_Content) { > >- mozilla::dom::ContentProcessChild *cpc = > >- mozilla::dom::ContentProcessChild::GetSingleton(); > >- NS_ASSERTION(cpc, "Content Protocol is NULL!"); > >- > >+ if (ContentProcessChild* cpc = GetContentProcessChild()) { > > nsAutoString prefValue; > > cpc->SendGetPrefLocalizedString(nsDependentCString(getPrefName(aPrefName)), > > &prefValue, &rv); > > if (NS_FAILED(rv)) return rv; > > We should init 'rv' here too, right? It'll be set to NS_OK from the prior call. > Good call. > Should we be checking the return value of the Send* methods instead? I > initially thought they aborted on failure but I guess they just return false in > the closed channel case :/ > Yeah, they currently return false until we process the channel-error notification (and then are supposed to _exit()). The contract for subprocess code is that return values from Send*() don't need to be checked; your code is perfectly fine. We might change the disconnect implementation, but that's not something to worry about.
Assignee | ||
Comment 5•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/4f8b85f53eba
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•