643412 - Memory Grow when popping with particular proxy settings

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking, defect)

Description

[patches]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.2.15) Gecko/20110308 Fedora/3.6.15-1.fc14 Firefox/3.6.15
Build Identifier: 3.1.6

TB is configured as described : 
* POP account
* Internet proxy configured with Option 5 (URL for proxy pac)

When popping, TB memory grows continously (20 Mo per minute), until crash.

The bug seems to be linked to the Option 5 (the others options dont have the issue).

Important Note : The used URL in Option 5 provide a Http Status = 301 (Moved Permanently), which forward to a valid URL.
The issue seems to be linked to this "forwarding" mechanism.


Reproducible: Always

Comment 1

[patches]

When putting TB in debug, i can count a huge number of http connections : 32269

#grep nsHttpChannel::AsyncOpen thunderbird_20101217\ _1609.log | wc -l
32269

Comment 2

[Wayne Mery (:wsmwk)]

does it crash also in safe mode? 
 https://support.mozillamessaging.com/en-US/kb/Safe+Mode
please attach file to bug with stacktrace
 https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report#Linux

Comment 3

[Wayne Mery (:wsmwk)]

https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=anywordssubstr&field0-0-0=short_desc&bug_severity=critical&bug_severity=major&bug_severity=normal&type0-0-1=anywordssubstr&field0-0-1=keywords&resolution=---&query_format=advanced&value1-0-0=AsyncOpen%20proxy&value0-0-1=crash%20hang%20perf&type0-0-0=anywordssubstr&value0-0-0=crash%20segfault&field1-0-0=short_desc

Comment 4

[Wayne Mery (:wsmwk)]

eddy, does this sound familiar?

Comment 5

[patches]

Attachment: CrashReports Folder

Here is the CrashReports folder, TB used 1Go RAM

Comment 6

[Wayne Mery (:wsmwk)]

unfortunately your crash report wasn't submitted and there's nothing in the .dmp file. (which can happen with OOM)   again, do you crash in safe mode?

Comment 7

[patches]

We tried several times to generate in safe mode crash reports but the .dmp files are always empty :-(
Each try is quite long (TB growing until 1Go), so i doubt i can give you more informations.

Comment 8

[Ludovic Hirlimann [:Usul]]

Can you follow these instructions https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report#Linux and capture a stack trace for us ?

Comment 9

[patches]

Attachment: Stacktrace

I've attached a stack trace captured using WinDBg as described here :

https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg

I hope it can be exploited as I couldn't get symbols resolved by WinDBg :( 

I'd like also to update the bug description :

This issue occurs when Option 3 is selected on proxy preferences (use system proxy settings) and not Option 5 (Automatic proxy configuration URL). The proxy autoconfiguration URL is providen into Intenet Settings

Comment 10

[Ludovic Hirlimann [:Usul]]

Did you replace firefox by thunderbird when you've setup the paths in windbg ?

Comment 11

[patches]

Yes, I used the following commands to setup paths in windbg :

 .sympath SRV*c:\symbols*http://symbols.mozilla.org/thunderbird;SRV*f:\symbols*http://msdl.microsoft.com/download/symbols
 .symfix+ c:\symbols
 .reload /

Comment 12

[patches]

Between the different proxy settings, the pac files arent accessed in the same way.

My proxy configuration is like this : 
* There is one index.php file that redirects to the pac file (with 301 HTTP return code)
* There is one proxy.pac file that contents the proxy configuration.

Inside TB, when i specify Option 5 with the URL of my index.php, my webserver receive 2 requests as expected : 
"GET /~xxx/index.php HTTP/1.1" 301 - "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6"
"GET /~xxx/proxy.pac HTTP/1.1" 200 625502 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6"


Inside TB, when i used the Option 3 (use proxy system) and my proxy system is set to use the URL of my index.php, my webserver received tons of requests but only for index.php and never for proxy.pac

That fact confirmed that 301 HTTP redirection is not taken in account when TB is configured to use system proxy, and all theses requests seems to be the origin of the memory leak.

Do this different behaviour between option 3 and option 5, means something interesting for this bug analysis ?

Comment 13

[Wayne Mery (:wsmwk)]

patches, does it also crash for version 5?

Comment 14

[Wayne Mery (:wsmwk)]

someone might check firefox / core proxy bug reports. I think I read something about memory increase related to using proxy.

Comment 15

[patches]

(In reply to Wayne Mery (:wsmwk) from comment #13)
> patches, does it also crash for version 5?

I didnt test it with TB 5.
I will try to get some feedback about it.

Comment 16

[patches]

Good news : It seems to be OK with TB 6.

That means, it was fixed between TB 3.1.6 and 6.
Any idea of related bug ?

Comment 17

[Wayne Mery (:wsmwk)]

(In reply to patches from comment #16)
> Good news : It seems to be OK with TB 6.
> 
> That means, it was fixed between TB 3.1.6 and 6.
> Any idea of related bug ?

no idea. maybe ludo does

Comment 18

[Ludovic Hirlimann [:Usul]]

No I don't either.

Comment 19

[patches]

The last feedback is that it's also fixed with TB 5.

Do you know where i can find a list of all fixes between 3.1.6 and 5.0 ?

Comment 20

[Wayne Mery (:wsmwk)]

(In reply to patches from comment #19)
> The last feedback is that it's also fixed with TB 5.
> 
> Do you know where i can find a list of all fixes between 3.1.6 and 5.0 ?

the release notes and blog announcements are a good place to start