Closed Bug 59657 Opened 19 years ago Closed 17 years ago

Occurences of uninitialized variables being used before being set in nsTraceMalloc

Categories

(Core :: XPCOM, defect, P3)

defect

Tracking

()

RESOLVED WONTFIX
mozilla1.3beta

People

(Reporter: rich.burridge, Assigned: brendan)

References

Details

Attachments

(1 file)

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
----
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
----
Another (and hopefully the last) one:

xptiZipLoader.cpp:87: warning: `PRBool result' might be used uninitialized in
this function
----
Blocks: 59652
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
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
Keywords: mozilla1.1, patch, review
Can somebody review this patch, please? Thanks!
Attachment #83825 - Flags: review+
re-assigning to XPCOM owner
Assignee: scc → dougt
QA Contact: kandrot → scc
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?
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
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'
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
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.
nsTraceMalloc is brendan's baby.
Assignee: dougt → brendan
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?
Summary: Occurances of uninitialized variables being used before being set in xpcom → Occurences of uninitialized variables being used before being set in xpcom
Fixing TM.

/be
Target Milestone: --- → mozilla1.3beta
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: 17 years ago
Resolution: --- → WONTFIX
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
Filed bug 188124 on remaining (directory/xpcom) warnings.
Attachment #83825 - Flags: superreview?
You need to log in before you can comment on or make changes to this bug.