Closed Bug 870652 Opened 8 years ago Closed 8 years ago

crash in mozilla::net::NetAddrToString

Categories

(Core :: Networking: DNS, defect)

20 Branch
All
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla24

People

(Reporter: mats, Assigned: sworkman)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

OS: Windows NT → Windows 7
Crash Signature: [@ mozilla::net::NetAddrToString(mozilla::net::NetAddr const*, char*, unsigned int)] → [@ mozilla::net::NetAddrToString(mozilla::net::NetAddr const*, char*, unsigned int) ]
I see several comments relating to the host machine either going to sleep or coming out of sleep. Suggest to me it could be the addr_info changing. However, the boolean condition (mIterGenCnt == mHostRecord->addr_info_gencnt) should detect that.

Patrick, does this sound reasonable? Any ideas why addr_info_gencnt wouldn't be updated?

A simple null check for mIter in nsDNSRecord::ReportUnusable and/or for aAddress in nsHostRecord::ReportUnusable should avoid the crash. But it would be better to know why this is happening.
I think this is a regression from 807678.. if you look at the changes to ReportUnusable() made in that patch..

there clearly are cases in getnextaddr() where mIter could be nullptr with a valid (and unchanging) gencnt.

I'm not 100% sure but I think the nullptr check is probably the right thing in this case.
Blocks: 807678
Keywords: regression
Version: Trunk → 20 Branch
Crash comments don't yield great STR, so just did regression testing using network xpcshell tests locally. All passing (except test_protocolproxyservice, but that fails without the patch too).
Assignee: nobody → sworkman
Status: NEW → ASSIGNED
Attachment #749345 - Flags: review?(mcmanus)
Attachment #749345 - Flags: review?(mcmanus) → review+
https://hg.mozilla.org/mozilla-central/rev/1be2d9024641
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.