Closed
Bug 59657
Opened 24 years ago
Closed 22 years ago
Occurences of uninitialized variables being used before being set in nsTraceMalloc
Categories
(Core :: XPCOM, defect, P3)
Core
XPCOM
Tracking
()
RESOLVED
WONTFIX
mozilla1.3beta
People
(Reporter: rich.burridge, Assigned: brendan)
References
Details
Attachments
(1 file)
(deleted),
patch
|
timeless
:
review+
|
Details | Diff | Splinter Review |
For more details on this problem, see:
http://bugzilla.mozilla.org/show_bug.cgi?id=59652
This bug is just for the warnings from two lines in the XPCOM module:
/xpcom/typelib/xpidl/
xpidl_header.c:709: warning: `is_signed' might be used uninitialized in this
function
----
/xpcom/typelib/xpidl/
xpidl_typelib.c:1120: warning: `is_long' might be used uninitialized in this
function
----
Reporter | ||
Comment 1•24 years ago
|
||
One more file where this is occuring:
pldhash.c:268: warning: `size' might be used uninitialized in this function
pldhash.c:268: warning: `capacity' might be used uninitialized in this function
----
Reporter | ||
Comment 2•24 years ago
|
||
Another (and hopefully the last) one:
xptiZipLoader.cpp:87: warning: `PRBool result' might be used uninitialized in
this function
----
Comment 3•23 years ago
|
||
Currently (http://tinderbox.mozilla.org/SeaMonkey/warn1010759460.5770.html)
xpcom gives the following warnings:
xpcom/base/nsTraceMalloc.c:1522
`oldptr' might be used uninitialized in this function
xpcom/base/nsTraceMalloc.c:1523
`oldsite' might be used uninitialized in this function
xpcom/base/nsTraceMalloc.c:1524
`oldsize' might be used uninitialized in this function
xpcom/base/nsTraceMalloc.c:1526
`he' might be used uninitialized in this function
xpcom/ds/nsObserverList.cpp:105
`PRBool removed' might be used uninitialized in this function
xpcom/reflect/xptinfo/src/xptiZipLoader.cpp:112
`PRBool result' might be used uninitialized in this function
IMHO, it would be nice not to have too much warnings (some of which may be real
bugs) in Mozilla 1.0
Keywords: mozilla1.0
Comment 4•23 years ago
|
||
Current (http://tinderbox.mozilla.org/SeaMonkey/warn1013026020.23864.html - Wed,
06 Feb 2002 15:07 EST) xpcom warnings:
xpcom/base/nsTraceMalloc.c:1522
`oldptr' might be used uninitialized in this function
xpcom/base/nsTraceMalloc.c:1523
`oldsite' might be used uninitialized in this function
xpcom/base/nsTraceMalloc.c:1524
`oldsize' might be used uninitialized in this function
xpcom/base/nsTraceMalloc.c:1526
`he' might be used uninitialized in this function
Summary: Occurances of uninitialized variables being used before being set. → Occurances of uninitialized variables being used before being set in xpcom
Comment 5•22 years ago
|
||
Updated•22 years ago
|
Comment 6•22 years ago
|
||
Can somebody review this patch, please? Thanks!
Attachment #83825 -
Flags: review+
Comment 8•22 years ago
|
||
Comment on attachment 83825 [details] [diff] [review]
Get rid of the warnings.
No sure who is the right person to ask for a sr.
Attachment #83825 -
Flags: superreview?
Assignee | ||
Comment 9•22 years ago
|
||
Comment on attachment 83825 [details] [diff] [review]
Get rid of the warnings.
I object. Get a better compiler, don't foist more cycles on critical paths
(trace-malloc builds run slowly enough as it is).
/be
Comment 10•22 years ago
|
||
brendan - in this case, the initialisation branch + the test for the use of
oldPtr are guarded by a file-scope variable, so the compiler cannot know that
the result is the same, since any of the functions it calls may have modified
suppress_tracing.
However, even if I replace suppress_tracing with a local variable, gcc still
can't tell the difference - see gcc bug c/5035, and its apparently non-trivial
to solve.
I also get another warning on this file:
nsTraceMalloc.c:1338: warning: argument `skip' might be clobbered by `longjmp'
or `vfork'
Assignee | ||
Comment 11•22 years ago
|
||
bbaetz: thanks for the gcc bug reference; however hard, our brains are up to the
task of proving that suppress_tracing is balanced, and we can prove invariants
hold for its tests and induction variables. So long as the amount of code to
analyze in such a proof is small, I don't bow to spurious warnings. Let's keep
our tools serving our brains, if possible.
True, warning brainprint can be exhausted by too many spurious warnings. Do we
have too many here, for nsTraceMalloc.c? I don't think so. If only we could
selectively suppress them.
Do you know what the longjmp/vfork warning is about? Why are arguments not
saved by setjmp and restored by longjmp? No vfork usage in sight, of course.
/be
Comment 12•22 years ago
|
||
brendan: I'm wondering if skip being a parameter may have something to do with
the setjmp var. In particular, if |skip| was passed in a register, I don't think
setjmp is required to save it
C99 7.13.2.1/3 says (about longjmp): "... the values of objects of automatic
storage duration that are local to the function containing the invocation of the
corresponding setjmp macro that do not have volitile-qualified type and have
been changed between the setjmp invocation and longjmp call are indeterminate."
IOW, the |--skip| we do may or may not change the saved version of |skip|. I
can't think of a rationale for this off hand, unless its to allow the optimiser
to hoist some stuff above the setjmp call, or something along those lines.
dbaron, scc: any ideas?
Re the warning stuff, I agree with you in this case, except that if
suppress_warning was a (non inlinable) function instead of a variable, it would
be worth using a local to avoid the overhead of a function call the second time.
Comment 14•22 years ago
|
||
Current list of warnings:
directory/xpcom/base/src/nsLDAPBERValue.cpp:59
`PRUint8 * array' might be used uninitialized in this function
directory/xpcom/base/src/nsLDAPMessage.cpp:589
`nsresult rv' might be used uninitialized in this function
xpcom/base/nsTraceMalloc.c:1519
`oldptr' might be used uninitialized in this function
xpcom/base/nsTraceMalloc.c:1520
`oldsite' might be used uninitialized in this function
xpcom/base/nsTraceMalloc.c:1521
`oldsize' might be used uninitialized in this function
xpcom/base/nsTraceMalloc.c:1523
`he' might be used uninitialized in this function
P.S. Is it worth filing a separate bug on directory/xpcom?
Updated•22 years ago
|
Summary: Occurances of uninitialized variables being used before being set in xpcom → Occurences of uninitialized variables being used before being set in xpcom
Assignee | ||
Comment 16•22 years ago
|
||
I'm not planning to change nsTraceMalloc.c -- if there are other files to fix,
please file other bugs on the appropriate owners.
/be
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Comment 17•22 years ago
|
||
Well, if not fix, then may be somehow disable? See bug 179819.
Summary: Occurences of uninitialized variables being used before being set in xpcom → Occurences of uninitialized variables being used before being set in nsTraceMalloc
Comment 18•22 years ago
|
||
Filed bug 188124 on remaining (directory/xpcom) warnings.
Updated•22 years ago
|
Attachment #83825 -
Flags: superreview?
You need to log in
before you can comment on or make changes to this bug.
Description
•