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)

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
Attached patch Get rid of the warnings. (deleted) — Splinter Review
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: 22 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.

Attachment

General

Creator:
Created:
Updated:
Size: