434839 - Out of memory running outparam analysis on nsURLParsers.cpp

Status: VERIFIED FIXED

(Developer Infrastructure :: Source Code Analysis, defect)

Description

[Benjamin Smedberg]

GCC 4.3.0 with latest patches and dehydra, mozilla-central:

When compiling netwerk/base/src/nsURLParsers.cpp:
../../../../src/netwerk/base/src/nsURLParsers.cpp: In member function ‘virtual n
sresult nsAuthURLParser::ParseAuthority(const char*, PRInt32, PRUint32*, PRInt32
*, PRUint32*, PRInt32*, PRUint32*, PRInt32*, PRInt32*)’:
../../../../src/netwerk/base/src/nsURLParsers.cpp:688: warning: outparam not wri
tten on NS_SUCCEEDED(return value): port
    Outparam declared at: ../../../../src/netwerk/base/src/nsURLParsers.cpp:479
    Return at: ../../../../src/netwerk/base/src/nsURLParsers.cpp:521
[and many more here...]
/builds/gcc-dehydra/dehydra/libs/map.js:212: : out of memory
gmake[1]: *** [nsURLParsers.o] Error 1

Comment 1

[David Mandelin [:dmandelin]]

Attachment: Fix + 2 minor fixes

Turns out it wasn't ilooping, but the state was blowing up. There were 8 outparams plus the return value, giving a total of 512 possible states, enough of which were getting explored to cause a problem. It actually terminated on dm-oink01, but ran really slowly.

As a fix, I changed it to run a separate analysis for each outparam. This should cause no loss of accuracy. It potentially slows things down when there is no state blowup, as you do the loop and analysis overhead for each variable. But it speeds things up when there is a blowup, about 25x for the function that you were getting OOM on. Overall it seems to be about the same as before.

We could try trickier things, like run everything together, but watch for state blowup and restart with separate runs, but I figured I'd do the simplest thing until something else became necessary.

I added in 2 other fixes for small bugs found by 'make check'. They seem to be regressions from the update for void and PRBool. I'm not sure how they snuck in, I thought maybe it was because of recent updates to Treehydra, but that appears not to be the case. Anyway, let me know if you want separate bugs for them, but that seems like unnecessary overhead.