Closed Bug 35424 Opened 25 years ago Closed 25 years ago

Null pointer dereference

Categories

(Core :: XPCOM, defect, P3)

x86
All
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sarnold, Assigned: dp)

Details

(Keywords: crash)

Hello there. Using a cvs build made April 10th, I got the following error. I was resizing my mozilla window while viewing the "fixed positioning" debug test. Thanks. ###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0', file ../../../../dist/include/nsCOMPtr.h, line 621 ###!!! Break: at file ../../../../dist/include/nsCOMPtr.h, line 621 .//run-mozilla.sh: line 29: 28117 Segmentation fault $prog ${1+"$@"}
I saw this again; again it happened while horizontally resizing mozilla to be smaller. Also, it beeped. A single beep. It happened the previous time as well, but I thought that was my email. :) It wasn't, it was mozilla screaming for help on the way out. :) ###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0', file ../../../../dist/include/nsCOMPtr.h, line 621 ###!!! Break: at file ../../../../dist/include/nsCOMPtr.h, line 621 .//run-mozilla.sh: line 29: 28148 Segmentation fault $prog ${1+"$@"}
hey, that sucked. happened to me too win32 build 041409 under NT. I have absolutely no idea who to send this to. let me look/ask around some and see if we can't get this moved out of browser general wasteland. Updating OS to All, adding crash keyword, updating severity to critical.
Severity: normal → critical
Keywords: crash
OS: Linux → All
Asa, you may also wish to change the bug from unconfirmed to 'new'. :)
Change it yourself ;)
OK, sending this to XPCOM because that's where nsCOMPtr lives and I don't have any other clue on this one.
Assignee: asadotzler → dp
Status: UNCONFIRMED → NEW
Component: Browser-General → XPCOM
Ever confirmed: true
QA Contact: jelwell → leger
We need a stack. This is a problem with someone using COMPtr rather than in COMPtr. Anyone has the ability to get a stack trace when this happens.
Status: NEW → ASSIGNED
Target Milestone: --- → M16
If you folks dont have a debug build to get a stack trace, let me know. I will try to ask around if anyone else is seeing this.
I cant do much with this data here.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
dp, sorry for not responding to your earlier question -- I was rebuilding a computer, and got behind on quite a bit of email. I don't currently have a debug build (and I have been having trouble getting any builds, for that matter... I keep getting "Internal Compiler Error" messages from gcc, maybe I have overclocked too far.. :) but I would like to make one if it would help track the problem down. However, I don't know that closing the bug is the right thing to do -- unless you get penalized for open bugs against your components, or it looks bad at review time, etc etc. However, the problem has happened for several people, myself included, at seemingly random times, and unless someone has consciously noticed something incorrect in their code, it likely hasn't been fixed. If nothing else, I suggest leaving the bug open with a reminder set to be sent before Netscape wishes to release a second beta, *especially* before Netscape wishes to release mozilla as a product; at that time, everyone could be put into code review mode, and asked to check over each other's source, in an attempt to track down this bug, and other bugs still open at that point. But, unless you personally have some consequences for open bugs, I think this bug should be reopened. Thanks dp. :)
Well, I am ok even if there is a personal element to this. The key is a bug should be open only if there is something useful that can be done to it. Otherwise, it will just "bit rot". Since I hear you are willing to try get a stack trace, I am glad. Bug reopens.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Target Milestone: M16 → M17
Status: REOPENED → ASSIGNED
Target Milestone: M17 → M16
sarnold@willamette.edu: Bug 35643 "[crash] on browser resize" has been fixed in 4/25 builds. I can't tell if this bug is about the same problem, but in case you can't reproduce it any more, this might be the cause...
Marking fixed per alecf's comment. Testing folks will try verifying this.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Per last comments, age of bug, and no reopen - Marking Verified/Fixed. Please reopen if still a problem.
You need to log in before you can comment on or make changes to this bug.