User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:22.214.171.124) 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
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
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
Severity: normal → critical
eddy, does this sound familiar?
Created attachment 526723 [details] CrashReports Folder Here is the CrashReports folder, TB used 1Go RAM
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?
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.
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 ?
Created attachment 529126 [details] 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
Did you replace firefox by thunderbird when you've setup the paths in windbg ?
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 /
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:126.96.36.199) 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:188.8.131.52) 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 ?
Component: General → Networking
Product: Thunderbird → MailNews Core
QA Contact: general → networking
Version: 3.1 → 1.9.2 Branch
patches, does it also crash for version 5?
someone might check firefox / core proxy bug reports. I think I read something about memory increase related to using proxy.
Whiteboard: [closeme 2011-08-27]
(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.
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 ?
(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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2011-08-27]
No I don't either.
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 ?
(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
You need to log in before you can comment on or make changes to this bug.