Closed
Bug 489914
Opened 16 years ago
Closed 6 years ago
warn on null callers, warn on no null checks
Categories
(Developer Infrastructure :: Source Code Analysis, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: dietrich, Unassigned)
References
Details
in bug 489872, we had a bunch of public entry points not doing null checks, causing crashes b/c of bad callers. asked taras about using static analysis tools to attack these problems - maybe detecting lack of checks, detecting and warning about potentially bad callers, etc.
Reporter | ||
Updated•16 years ago
|
Component: Places → Rewriting and Analysis
Product: Toolkit → Core
QA Contact: places → rewriting-and-analysis
Comment 2•16 years ago
|
||
(In reply to comment #1) > maybe dupe of bug 488941? not dupe. That bug deals with explicit not-null changes. This one deals with everything else
Blocks: static_analyses
Reporter | ||
Comment 3•16 years ago
|
||
#2 and #3 are from this problem: http://crash-stats.mozilla.com/query/query?query_type=startswith&query=nsNavHistory::&do_query=1
Comment 4•16 years ago
|
||
It's closely related to bug 488941, right? Hopefully it will be mostly the same code.
Comment 5•16 years ago
|
||
(In reply to comment #4) > It's closely related to bug 488941, right? Hopefully it will be mostly the same > code. i'm not so sure. The js one has more flexibility in terms of rewriting the api and limited places need null checking. We can't really guarantee nonnullness on public interfaces.
Comment 6•16 years ago
|
||
Is the idea here that we should detect API misuse eagerly, using explicit checks, even in release builds, even though that has a performance cost? This would not buy us much in the JSAPI, because the most common ways to crash JS do not involve unexpectedly-null arguments. They involve things like forgetting to root a pointer, which our API could not possibly detect.
If by "public entry point" you mean a function called from code dlsym()ed or dynamically linked against, then there's no possible way to statically guarantee that the argument to the "public entry point" is nonnull. (Well, more precisely, it's not easy.) OTOH, if you want to guarantee that all Mozilla code satisfies this invariant at the compile time of all Mozilla code, then the machinery in bug 488941 can probably do this for you. Please let us know if it's insufficient. (Rewriting existing function parameters to understand non-nullability should be easy; talk to taras or cjones on #static if this is a bottleneck for you.)
Updated•7 years ago
|
Product: Core → Firefox Build System
Comment 8•6 years ago
|
||
Coverity and clang have that.
Status: NEW → RESOLVED
Closed: 6 years ago
Priority: -- → P3
Resolution: --- → FIXED
Updated•2 years ago
|
Product: Firefox Build System → Developer Infrastructure
You need to log in
before you can comment on or make changes to this bug.
Description
•