Closed Bug 1028720 Opened 11 years ago Closed 9 years ago

Thunderbird is crashing [@ OOM | small ] calling nsJSID::NewID from xpc_NewIDObject

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Version:
24 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: rocktman3, Unassigned)

References

(Blocks 1 open bug)

Details

(4 keywords)

Crash Data

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release) Build ID: 20140605174243 Steps to reproduce: I started TB, read any current emails, left TB open on my computer. Actual results: TB crashed & has been crashing repeatedly. According to the Troubleshooting Information, submitted crash reports, the crash reason is EXCEPTION_BREAKPOINT. This happening whether TB is running normally or in safe mode. I also disabled all but 1 plugin, but that also made no difference. Expected results: TB should be able to remain open indefinitely w/o crashing.
Can you post one or more crash IDs, please?
Severity: normal → critical
Keywords: crash
Crash Signature: [@ OOM | small ]
Summary: TB is crashing → TB is crashing [@ OOM | small ] calling nsJSID::NewID from xpc_NewIDObject
Thanks, I don't see anything mail/news specific in those crash reports, thus it may be a Core issue (XPCOM trying to allocate too much memory for an object). Since you seem to have plenty of main memory left, this doesn't look like just running out of memory. I don't see anything filed with this signature yet, but then, there isn't much of a hint what happened.
Crashes started with v24.3 on 2/5/14. Next one was with v24.5 on 5/18/14. Then with v24.6 on 6/14/14 & 6/17/14. I reverted back to v24.5 (crashed on 6/17)to see if it was a version issue before I looked at the troubleshooting info & found it back to v24.3. There is a crash report back in 5/2013, but it's empty of info (bp-36015a7d-20ea-44a5-87dc-1f1ab2130522 5/21/2013).
"OOM | small" means that we are helplessly out of memory and can't even do small allocations any more. There is no way to deal with the specific problem and it's completely useless to look at the specific stack. All that can be done to remedy the situation is to generally make us use less memory.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
(In reply to rocktman3 from comment #2) > bp-472e0671-d7a2-4e7a-9963-09b972140619 6/19/2014 4:18 PM Am I reading this wrong then? This doesn't look like we are running out of virtual memory: > Total Virtual Memory 4294836224 > Available Virtual Memory 3944153088 > System Memory Use Percentage 45 > Available Page File 9421746176 > Available Physical Memory 3456757760 > OOM Allocation Size 32
rocktman, you are crashing frequently enough that it would be useful to for us to better understand your memory usage. 1. check windows taskmgr, process tab, working set size periodically once an hour or two to see how it is growing 2. please post the information at help | troubleshooting | copy to clipboard into this bug (delete lines below "Important Modified Preferences") 3. please estimate your number of folders
Flags: needinfo?(rocktman3)
Flags: needinfo?(kairo)
Well, we failed to allocate 32 bytes. Something is badly wrong if we can't do that, but the actual code that tried to allocate 32 bytes is probably not to blame.
Flags: needinfo?(kairo)
It is surprising that we fail to allocate here. dmajor can you look through the minidump to see if there are memory mappings or other things that might explain this?
Flags: needinfo?(dmajor)
(In reply to Benjamin Smedberg [:bsmedberg] from comment #9) > It is surprising that we fail to allocate here. dmajor can you look through > the minidump to see if there are memory mappings or other things that might > explain this? precisely - this goes to what I think rsx11m was posing to kairo "Am I reading this wrong then? This doesn't look like we are running out of virtual memory:" (we already know "we failed to allocate 32 bytes")
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WONTFIX → ---
(In reply to Wayne Mery (:wsmwk) from comment #7) > rocktman, you are crashing frequently enough that it would be useful to for > us to better understand your memory usage. > > 1. check windows taskmgr, process tab, working set size periodically once > an hour or two to see how it is growing > 2. please post the information at help | troubleshooting | copy to clipboard > into this bug (delete lines below "Important Modified Preferences") > 3. please estimate your number of folders 1-Are you referring to folders in TB? 66 folders amongst 14 configured email accounts including the global inbox. 2-I don't see "working set size in taskmgr. 3-clipboard: Application Basics Name: Thunderbird Version: 24.5.0 User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 Profile Folder: Show Folder (Local drive) Application Build ID: 20140424091057 Enabled Plugins: about:plugins Build Configuration: about:buildconfig Crash Reports: about:crashes Memory Use: about:memory Mail and News Accounts account1: INCOMING: account1, , (none) Local Folders, plain, passwordCleartext account2: INCOMING: account2, , (pop3) pop.gmail.com:995, SSL, passwordCleartext OUTGOING: smtp.gmail.com:465, SSL, passwordCleartext, true account3: INCOMING: account3, , (pop3) pop3.live.com:995, SSL, passwordCleartext OUTGOING: smtp.live.com:587, alwaysSTARTTLS, passwordCleartext, true account4: INCOMING: account4, , (pop3) pop.gmail.com:995, SSL, passwordCleartext OUTGOING: smtp.gmail.com:465, SSL, passwordCleartext, true account5: INCOMING: account5, , (pop3) pop.gmail.com:995, SSL, passwordCleartext OUTGOING: smtp.gmail.com:465, SSL, passwordCleartext, true account6: INCOMING: account6, , (pop3) pop.gmail.com:995, SSL, passwordCleartext OUTGOING: smtp.gmail.com:465, SSL, passwordCleartext, true account9: INCOMING: account9, , (pop3) pop.gmail.com:995, SSL, passwordCleartext OUTGOING: smtp.googlemail.com:465, SSL, passwordCleartext, true account10: INCOMING: account10, , (pop3) pop.gmail.com:995, SSL, passwordCleartext OUTGOING: smtp.googlemail.com:465, SSL, passwordCleartext, true account12: INCOMING: account12, , (pop3) pop.gmx.net:995, SSL, passwordCleartext OUTGOING: smtp.googlemail.com:465, SSL, passwordCleartext, true account13: INCOMING: account13, , (pop3) pop.gmail.com:995, SSL, passwordCleartext OUTGOING: smtp.googlemail.com:465, SSL, passwordCleartext, true account14: INCOMING: account14, , (pop3) pop.gmail.com:995, SSL, passwordCleartext OUTGOING: smtp.googlemail.com:465, SSL, passwordCleartext, true account15: INCOMING: account15, , (pop3) pop.gmx.net:995, SSL, passwordCleartext OUTGOING: smtp.googlemail.com:465, SSL, passwordCleartext, true account16: INCOMING: account16, , (pop3) pop.gmx.net:995, SSL, passwordCleartext OUTGOING: smtp.googlemail.com:465, SSL, passwordCleartext, true account17: INCOMING: account17, , (pop3) pop.gmail.com:995, SSL, passwordCleartext OUTGOING: smtp.googlemail.com:465, SSL, passwordCleartext, true account18: INCOMING: account18, , (pop3) pop.gmail.com:995, SSL, passwordCleartext OUTGOING: smtp.googlemail.com:465, SSL, passwordCleartext, true Extensions Add-on Compatibility Reporter, 1.1, true, compatibility@addons.mozilla.org Classic TB2 Options, 1.3.0, true, {2A95E724-F74E-46D3-93FD-3E9850382E53} Folderpane Tools, 0.6.1, true, {b243fe83-b8a7-47de-855d-21d865243d5d} Ignore Aero (Hooks), 1.0.3.0, true, ignoreaero-x@rsjtdrjgfuzkfg.com Lightning, 2.6.6, true, {e2fda1a4-762b-4020-b5ad-a41df1933103} Mass Password Reset, 1.05, true, masspasswordreset@johnathan.nightingale Nightly Tester Tools, 3.7, true, {8620c15f-30dc-4dba-a131-7c5d20cf4a29} Provider for Google Calendar, 0.25, true, {a62ef8ec-5fdc-40c2-873c-223b8a6925cc} QuickFolders, 3.14.1, true, quickfolders@curious.be Thunderbird Message Filter Import/Export, 1.3.7.6, true, FiltersImportExport@mozilla.org (TEBE), beta(20100727_120000), false, TEBE@guid.customsoftwareconsult.com Enigmail, 1.6, false, {847b3a00-7ab1-11d4-8f02-006008948af5} Important Modified Preferences Name: Value browser.cache.disk.capacity: 0 browser.cache.disk.smart_size.enabled: false browser.cache.disk.smart_size.first_run: false extensions.checkCompatibility: false extensions.checkCompatibility.10.0: false extensions.checkCompatibility.10.0a: false extensions.checkCompatibility.11.0: false extensions.checkCompatibility.11.0a: false extensions.checkCompatibility.12.0: false extensions.checkCompatibility.12.0a: false extensions.checkCompatibility.13.0: false extensions.checkCompatibility.13.0a: false extensions.checkCompatibility.14.0: false extensions.checkCompatibility.14.0a: false extensions.checkCompatibility.15.0: false extensions.checkCompatibility.15.0a: false extensions.checkCompatibility.16.0: false extensions.checkCompatibility.16.0a: false extensions.checkCompatibility.17.0: false extensions.checkCompatibility.17.0a: false extensions.checkCompatibility.18.0: false extensions.checkCompatibility.18.0a: false extensions.checkCompatibility.19.0: false extensions.checkCompatibility.19.0a: false extensions.checkCompatibility.20.0: false extensions.checkCompatibility.20.0a: false extensions.checkCompatibility.21.0: false extensions.checkCompatibility.21.0a: false extensions.checkCompatibility.22.0: false extensions.checkCompatibility.22.0a: false extensions.checkCompatibility.24.0: false extensions.checkCompatibility.24.1: false extensions.checkCompatibility.24.2: false extensions.checkCompatibility.24.3: false extensions.checkCompatibility.24.4: false extensions.checkCompatibility.24.5: false extensions.checkCompatibility.24.6: false extensions.checkCompatibility.3.0: false extensions.checkCompatibility.3.0.previous: false extensions.checkCompatibility.3.1: false extensions.checkCompatibility.3.1.previous: false extensions.checkCompatibility.3.1a: false extensions.checkCompatibility.3.1a.previous: false extensions.checkCompatibility.3.1b: false extensions.checkCompatibility.3.1b.previous: false extensions.checkCompatibility.3.1p: false extensions.checkCompatibility.3.1p.previous: false extensions.checkCompatibility.3.1pre: false extensions.checkCompatibility.3.1pre.previous: false extensions.checkCompatibility.3.2a: false extensions.checkCompatibility.3.3: false extensions.checkCompatibility.3.3a: false extensions.checkCompatibility.3.3a.previous: false extensions.checkCompatibility.3.3b: false extensions.checkCompatibility.3.3p: false extensions.checkCompatibility.3.3pre: false extensions.checkCompatibility.5.0: false extensions.checkCompatibility.5.0a: false extensions.checkCompatibility.5.0b: false extensions.checkCompatibility.5.0p: false extensions.checkCompatibility.5.0pre: false extensions.checkCompatibility.6.0: false extensions.checkCompatibility.6.0a: false extensions.checkCompatibility.7.0: false extensions.checkCompatibility.7.0a: false extensions.checkCompatibility.7.0a.previous: false extensions.checkCompatibility.7.0b: false extensions.checkCompatibility.8.0: false extensions.checkCompatibility.8.0a: false extensions.checkCompatibility.9.0: false extensions.checkCompatibility.9.0a: false extensions.checkCompatibility.nightly: false extensions.checkCompatibility.nightly.previous: false extensions.checkCompatibility.previous: false extensions.lastAppVersion: 24.5.0 font.internaluseonly.changed: true font.name.monospace.el: Consolas font.name.monospace.tr: Consolas font.name.monospace.x-baltic: Consolas font.name.monospace.x-central-euro: Consolas font.name.monospace.x-cyrillic: Consolas font.name.monospace.x-unicode: Consolas font.name.monospace.x-western: Consolas font.name.sans-serif.el: Calibri font.name.sans-serif.tr: Calibri font.name.sans-serif.x-baltic: Calibri font.name.sans-serif.x-central-euro: Calibri font.name.sans-serif.x-cyrillic: Calibri font.name.sans-serif.x-unicode: Calibri font.name.serif.el: Cambria font.name.serif.tr: Cambria font.name.serif.x-baltic: Cambria font.name.serif.x-central-euro: Cambria font.name.serif.x-cyrillic: Cambria font.name.serif.x-unicode: Cambria font.name.serif.x-western: Cambria font.size.fixed.el: 14 font.size.fixed.tr: 14 font.size.fixed.x-baltic: 14 font.size.fixed.x-central-euro: 14 font.size.fixed.x-cyrillic: 14 font.size.fixed.x-unicode: 14 font.size.fixed.x-western: 14 font.size.variable.el: 17 font.size.variable.tr: 17 font.size.variable.x-baltic: 17 font.size.variable.x-central-euro: 17 font.size.variable.x-cyrillic: 17 font.size.variable.x-unicode: 17 font.size.variable.x-western: 17 mail.openMessageBehavior.version: 1 mail.winsearch.firstRunDone: true mailnews.database.global.datastore.id: 5891b820-aeb5-4435-9fc0-ce33551a3b5 mailnews.database.global.indexer.enabled: false network.cookie.prefsMigrated: true network.dns.disableIPv6: true places.database.lastMaintenance: 1403527209 places.history.expiration.transient_current_max_pages: 104858 places.history.expiration.transient_optimal_database_size: 167772160 plugin.importedState: true plugin.state.flash: 2 plugin.state.java: 2 plugin.state.np32dsw: 2 plugin.state.npgarmin: 2 plugin.state.nplastpass: 2 plugin.state.npoff: 2 plugin.state.npoffice: 2 plugin.state.nppdf: 2 plugin.state.nppicasa: 0 plugin.state.npvlc: 2 plugin.state.npwlpg: 0 print.print_printer: EPSON Stylus CX8400 Series print.printer_EPSON_Stylus_CX8400_Series.print_bgcolor: false print.printer_EPSON_Stylus_CX8400_Series.print_bgimages: false print.printer_EPSON_Stylus_CX8400_Series.print_colorspace: print.printer_EPSON_Stylus_CX8400_Series.print_command: print.printer_EPSON_Stylus_CX8400_Series.print_downloadfonts: false print.printer_EPSON_Stylus_CX8400_Series.print_duplex: 96640 print.printer_EPSON_Stylus_CX8400_Series.print_edge_bottom: 0 print.printer_EPSON_Stylus_CX8400_Series.print_edge_left: 0 print.printer_EPSON_Stylus_CX8400_Series.print_edge_right: 0 print.printer_EPSON_Stylus_CX8400_Series.print_edge_top: 0 print.printer_EPSON_Stylus_CX8400_Series.print_evenpages: true print.printer_EPSON_Stylus_CX8400_Series.print_footercenter: print.printer_EPSON_Stylus_CX8400_Series.print_footerleft: &PT print.printer_EPSON_Stylus_CX8400_Series.print_footerright: &D print.printer_EPSON_Stylus_CX8400_Series.print_headercenter: print.printer_EPSON_Stylus_CX8400_Series.print_headerleft: &T print.printer_EPSON_Stylus_CX8400_Series.print_headerright: &U print.printer_EPSON_Stylus_CX8400_Series.print_in_color: true print.printer_EPSON_Stylus_CX8400_Series.print_margin_bottom: 0.5 print.printer_EPSON_Stylus_CX8400_Series.print_margin_left: 0.5 print.printer_EPSON_Stylus_CX8400_Series.print_margin_right: 0.5 print.printer_EPSON_Stylus_CX8400_Series.print_margin_top: 0.5 print.printer_EPSON_Stylus_CX8400_Series.print_oddpages: true print.printer_EPSON_Stylus_CX8400_Series.print_orientation: 0 print.printer_EPSON_Stylus_CX8400_Series.print_page_delay: 50 print.printer_EPSON_Stylus_CX8400_Series.print_pagedelay: 500 print.printer_EPSON_Stylus_CX8400_Series.print_paper_data: 1 print.printer_EPSON_Stylus_CX8400_Series.print_paper_height: 11.00 print.printer_EPSON_Stylus_CX8400_Series.print_paper_name: print.printer_EPSON_Stylus_CX8400_Series.print_paper_size_type: 0 print.printer_EPSON_Stylus_CX8400_Series.print_paper_size_unit: 0 print.printer_EPSON_Stylus_CX8400_Series.print_paper_width: 8.50 print.printer_EPSON_Stylus_CX8400_Series.print_plex_name: print.printer_EPSON_Stylus_CX8400_Series.print_resolution: 115712 print.printer_EPSON_Stylus_CX8400_Series.print_resolution_name: print.printer_EPSON_Stylus_CX8400_Series.print_reversed: false print.printer_EPSON_Stylus_CX8400_Series.print_scaling: 1.00 print.printer_EPSON_Stylus_CX8400_Series.print_shrink_to_fit: true print.printer_EPSON_Stylus_CX8400_Series.print_to_file: false print.printer_EPSON_Stylus_CX8400_Series.print_unwriteable_margin_bottom: 0 print.printer_EPSON_Stylus_CX8400_Series.print_unwriteable_margin_left: 0 print.printer_EPSON_Stylus_CX8400_Series.print_unwriteable_margin_right: 0 print.printer_EPSON_Stylus_CX8400_Series.print_unwriteable_margin_top: 0 privacy.donottrackheader.enabled: true security.dialog_enable_delay: 0 security.disable_button.openCertManager: false Graphics Adapter Description: Intel(R) HD Graphics Family Vendor ID: 0x8086 Device ID: 0x0116 Adapter RAM: Unknown Adapter Drivers: igdumd64 igd10umd64 igd10umd64 igdumdx32 igd10umd32 igd10umd32 Driver Version: 8.15.10.2372 Driver Date: 4-15-2011 Direct2D Enabled: false DirectWrite Enabled: false (6.2.9200.16571) ClearType Parameters: Gamma: 2200 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 50 WebGL Renderer: false GPU Accelerated Windows: 0 AzureCanvasBackend: skia AzureFallbackCanvasBackend: cairo AzureContentBackend: none JavaScript Incremental GC: 1 Accessibility Activated: 0 Prevent Accessibility: 0 Library Versions Expected minimum version Version in use NSPR 4.10.2 4.10.2 NSS 3.15.4 Basic ECC 3.15.4 Basic ECC NSS Util 3.15.4 3.15.4 NSS SSL 3.15.4 Basic ECC 3.15.4 Basic ECC NSS S/MIME 3.15.4 Basic ECC 3.15.4 Basic ECC
This is very strange. In the minidumps I see a number of large free blocks, totaling more than 3GB free VM, with plenty of pagefile to back it. Those allocations really ought to have succeeded. Other users are seeing this too. We have a bunch of reports [1] of failed allocations with tons of free memory. Most of them are in Thunderbird, and this nsJSID variant is the most common. No correlations with the usual suspects (cpu/gfx/etc). It's suspicious that these allocations are clustered in a few signatures. If this were e.g. random corruption then I would expect more variance. Looking through crash dumps I don't see anything to explain it. Would be great if I could see this in a live debugger. Rocktman3, would you be comfortable with installing WinDbg and collecting more information if I wrote some instructions for it? [1] https://crash-stats.mozilla.com/search/?date=%3E%3D1%2F1%2F2014&signature=~mozalloc_handle_oom&available_page_file=%3E%3D1000000000&available_virtual_memory=%3E%3D1000000000&oom_allocation_size=%3C100&_facets=signature&_facets=product&_columns=date&_columns=signature&_columns=product&_columns=version
Flags: needinfo?(dmajor)
Perhaps we're failing to allocate because we corrupted the jemalloc heap?
n.b. as documented in bug 919986 comment 0 and bug 919986 comment 3, crash was rare in TB17 eg. bp-bc75ca09-1547-4c2c-b580-700cd2131227, but in TB24 crash rate immediately exploded eg. bp-0fe0911a-700f-4323-a190-cdd342131219. So, something changed between 17 and 24 to cause this massive increase. Anecdotally, I've been in contact with half dozen users with this crash. They tend to either have just a couple crashes and no more, or lots of crashes often with multiple signatures. And the later population tends to have many mail accounts - more than the range of a say 1-5 accounts.
Blocks: 919986
Component: Untriaged → General
Keywords: regression, regressionwindow-wanted
I was checking about:crashes on Nightly here and found this one: bp-a6c6661a-45e3-416e-97ce-6e56f2140623 23/06/2014 09:33 a.m. Is there a Firefox variant of this bug?
(In reply to alex_mayorga from comment #15) > I was checking about:crashes on Nightly here and found this one: > > bp-a6c6661a-45e3-416e-97ce-6e56f2140623 23/06/2014 09:33 a.m. > > Is there a Firefox variant of this bug? The above crash does not have the same stack nor allocation failure. Also, you have a boatload of crashes signatures https://crash-stats.mozilla.com/search/?email=~alex_mayorga%40yahoo.com&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform
(In reply to alex_mayorga from comment #15) > bp-a6c6661a-45e3-416e-97ce-6e56f2140623 23/06/2014 09:33 a.m. Also, this crash states "System Memory Use Percentage 90" thus may reflect an actual OOM case.
(In reply to Wayne Mery (:wsmwk) from comment #16) The price of being a Nightly tester perhaps? I'm not that seasoned on crash signatures, but if I click on bp-a6c6661a-45e3-416e-97ce-6e56f2140623 and go to "Related Bugs" I end up on bug 1028720 so here I am =)
(In reply to David Major [:dmajor] from comment #12) > This is very strange. In the minidumps I see a number of large free blocks, > totaling more than 3GB free VM, with plenty of pagefile to back it. Those > allocations really ought to have succeeded. > > Other users are seeing this too. We have a bunch of reports [1] of failed > allocations with tons of free memory. Most of them are in Thunderbird, and > this nsJSID variant is the most common. No correlations with the usual > suspects (cpu/gfx/etc). > > It's suspicious that these allocations are clustered in a few signatures. If > this were e.g. random corruption then I would expect more variance. Looking > through crash dumps I don't see anything to explain it. Would be great if I > could see this in a live debugger. > > Rocktman3, would you be comfortable with installing WinDbg and collecting > more information if I wrote some instructions for it? > > [1] > https://crash-stats.mozilla.com/search/ > ?date=%3E%3D1%2F1%2F2014&signature=~mozalloc_handle_oom&available_page_file=% > 3E%3D1000000000&available_virtual_memory=%3E%3D1000000000&oom_allocation_size > =%3C100&_facets=signature&_facets=product&_columns=date&_columns=signature&_c > olumns=product&_columns=version OK, as long as you break it, you fix it. :-) Is it something that stays resident or runs once & quits? BTW, TB hasn't crashed since 6/22.
Flags: needinfo?(rocktman3)
(In reply to David Major [:dmajor] from comment #12) > > Rocktman3, would you be comfortable with installing WinDbg and collecting > more information if I wrote some instructions for it? > I'm not Rocktman3, but I'm seeing this bug frequently (once every couple days) and willing to help out. I'm a semi-knowledgeable windbg user, but I'm not sure how to get it to automatically attach to the crashing firefox instance. The built-in crash handler always kicks in instead.
(In reply to Bill Fraser from comment #20) I'd love to have more debuggers on this, but are you sure we're talking about the same crash? The nsJSID::NewID signature occurs almost exclusively with Thunderbird rather than Firefox. (If you arrived here via the "OOM | small" link, that may have been misleading; this bug is for a particular variant of it.) Regarding the crash handler, I usually try to attach WinDbg before the crash, so that the debugger gets first crack at it.
(In reply to rocktman3 from comment #19) > OK, as long as you break it, you fix it. :-) Is it something that stays > resident or runs once & quits? BTW, TB hasn't crashed since 6/22. Thanks for the help. I'd like to ask that you run Thunderbird with WinDbg in the background. It will watch for errors but otherwise not collect or send any information other than what you paste to us. Later you can uninstall the debugger and it will be cleanly removed. You can install WinDbg or "Debugging Tools for Windows" from any source you like, here is one possible option: http://download.microsoft.com/download/A/6/A/A6AC035D-DA3F-4F0C-ADA4-37C8E5D34E3D/setup/WinSDKDebuggingTools/dbg_x86.msi Please follow these instructions and type the commands into the input box at the bottom of WinDbg. * Lines beginning with * are comments. WinDbg ignores them. * Start Thunderbird * Start WinDbg * File > Attach to a Process... * Choose thunderbird.exe from the list * Set up the debugging symbols: .symfix .sympath+ http://symbols.mozilla.org/thunderbird .reload * Turn off the debug log because it's useless and slow eb xul!sLoggingEnabled 0 * Let Thunderbird run g * Use Thunderbird like normal. Eventually, if you hit this crash, Thunderbird will freeze, and WinDbg will say something like: * mozalloc!mozalloc_abort+0x2a: * 737e119c cc int 3 * If you see that, then continue... * Clear the screen since we don't need the previous stuff .cls * Re-do the allocation with tracing enabled r @eip=mozalloc!moz_xmalloc ed @esp+4 0x20 tc wt -i ntdll -or * Paste the output into this bug. Close WinDbg (it will close the crashed Thunderbird too).
Updated to 24.6 yesterday, crashed today. bp-32573d3a-55bb-4dd0-931d-4be5e2140629 6/29/2014 7:22 AM Tried running WinDbg (after restarting TB), but it locked up TB & I couldn't get past attaching a process.
(In reply to rocktman3 from comment #23) > Updated to 24.6 yesterday, crashed today. > bp-32573d3a-55bb-4dd0-931d-4be5e2140629 6/29/2014 7:22 AM > Tried running WinDbg (after restarting TB), but it locked up TB & I couldn't > get past attaching a process. TB will be frozen when you first attach, but after you get to the "g" command, it should run again. Did that not work?
(In reply to alex_mayorga from comment #15) > I was checking about:crashes on Nightly here and found this one: > > bp-a6c6661a-45e3-416e-97ce-6e56f2140623 23/06/2014 09:33 a.m. > > Is there a Firefox variant of this bug? https://crash-stats.mozilla.com/report/index/a558f756-4a83-4e62-b76d-cab0b2140630 This Firefox is running Command and Conquer Tiberium Alliances, fairly exclusively. I'm also running a similar setup with Firefox Beta (different TA account). I didn't start to have this problem until the current release was installed. I never saw this issue in the previous beta, or even in the RC that would have been running the other account. And the beta that I'm running now hasn't crashed like this, either. Of course, the beta gets restarted with each new update. I think it happened yesterday as well, but that particular report just points to https://crash-stats.mozilla.com/about/throttling. So I'm not really sure when it happened last time, since the last prior crash that doesn't point to throttling is something different. It was no more than three days ago, I'm sure.
Comment 25 is an entirely different bug, and could easily be OOM due to VM exhaustion. Please let's not confuse things. I'm going to remove the crash signature from this bug since people with the generic signature are coming here incorrectly.
Crash Signature: [@ OOM | small ]
rocktman3, any progress? (In reply to David Major [:dmajor] from comment #24) > (In reply to rocktman3 from comment #23) > > Updated to 24.6 yesterday, crashed today. > > bp-32573d3a-55bb-4dd0-931d-4be5e2140629 6/29/2014 7:22 AM > > Tried running WinDbg (after restarting TB), but it locked up TB & I couldn't > > get past attaching a process. > > TB will be frozen when you first attach, but after you get to the "g" > command, it should run again. Did that not work?
Flags: needinfo?(rocktman3)
this user (pixelc___) has a variety of signatures. Perahps he is just on the "edge" of OOM | small ? https://crash-stats.mozilla.com/report/index/84038c3b-5b8e-4b6b-a67f-b52792140728 [@ nsCOMPtr_base::assign_with_AddRef(nsISupports*) | nsSocketTransport::SetSecurityCallbacks(nsIInterfaceRequestor*)] - Thunderbird 24.6.0 Crash Report - Report ID: 84038c3b-5b8e-4b6b-a67f-b52792140728 https://crash-stats.mozilla.com/report/index/a4e1c6f6-dcb5-414b-b98d-a7a012140729 [@ OOM | small] - Thunderbird 24.6.0 Crash Report - Report ID: a4e1c6f6-dcb5-414b-b98d-a7a012140729 https://crash-stats.mozilla.com/report/index/9207d040-5304-4b23-a919-34d972140729 [@ OOM | small] - Thunderbird 24.6.0 Crash Report - Report ID: 9207d040-5304-4b23-a919-34d972140729 https://crash-stats.mozilla.com/report/index/ee309fb3-8c04-4306-82b0-478092140729 [@ mozalloc_abort(char const* const) | NS_DebugBreak | nsDeque::Push(void*)] - Thunderbird 24.6.0 Crash Report - Report ID: ee309fb3-8c04-4306-82b0-478092140729 https://crash-stats.mozilla.com/report/index/1d8e626e-8a2d-47d0-beef-8b9382140729 [@ mozalloc_abort(char const* const) | NS_DebugBreak | nsDeque::Push(void*)] - Thunderbird 24.6.0 Crash Report - Report ID: 1d8e626e-8a2d-47d0-beef-8b9382140729 https://crash-stats.mozilla.com/report/index/54c39b1c-c1a5-40d8-9ea2-78c352140729 [@ OOM | small] - Thunderbird 24.6.0 Crash Report - Report ID: 54c39b1c-c1a5-40d8-9ea2-78c352140729 https://crash-stats.mozilla.com/report/index/42907455-b388-43ba-8f0e-a8e1a2140729 [@ mozalloc_abort(char const* const) | NS_DebugBreak | nsDeque::Push(void*)] - Thunderbird 24.6.0 Crash Report - Report ID: 42907455-b388-43ba-8f0e-a8e1a2140729
pixelc... is running out of pagefile rather than virtual memory. But yes, when you're on the "edge" it's not surprising to have different kinds of OOM signatures.
(followup to comment 28) OOM | small in version 31 is still much lower rank than version 24, so perhaps overall memory usage dropped slightly. I don't know what the situation is for Firefox. But statistially for Thunderbird should we consider increasing the threshold for OOM | small?
Flags: needinfo?(dmajor)
If OOM|small is very low then you should have a party to celebrate. :) That's a good thing! Small-versus-large is basically the distinction between whether a user is hopelessly low on memory or whether our code is asking for an unreasonably large allocation. If we shift the threshold, then there would be some previously-large allocations that we would stop investigating. I don't think that would be helpful.
Flags: needinfo?(dmajor)
Blocks: 610551
Depends on: 902158
rocktman3, the reporter, decided to stay on version 24.6.0. Even so, he has a few crashes on version 24: bp-a1780521-1691-4bb2-9b34-7d5172150308 bp-f1092fe3-a48d-46fa-90c4-f4f392150228 bp-7578037f-4fa4-40b2-b7a0-c67652150210 mozalloc_abort(char const* const) | NS_DebugBreak | nsAString_internal::Assign(nsAString_internal const&) | nsAutoCompleteItem::SetValue(nsAString_internal const&)
Flags: needinfo?(rocktman3)
I believe bug 837438 is a predecessor for a large percentage of this crash signature
Blocks: 837438
Crash Signature: [@ OOM | small ]
Keywords: topcrash-thunderbird
This is an unresolved problem since v12.0; this failure still remains unresolved in v46.0a1. https://crash-stats.mozilla.com/report/list?product=Firefox&signature=OOM+|+small#tab-reports Clients reporting failures are understandably irate. https://crash-stats.mozilla.com/report/list?product=Firefox&signature=OOM+|+small#tab-comments
(In reply to Common User Network Terminal from comment #36) > This is an unresolved problem since v12.0; this failure still remains > unresolved in v46.0a1. > > https://crash-stats.mozilla.com/report/ > list?product=Firefox&signature=OOM+|+small#tab-reports This bug is filed for Thunderbird, not Firefox. Most of the Thunderbird ones are not actuall OOM.
See Also: → 733261
(In reply to Yorgos from comment #35) > bp-34b8f50f-3da2-423b-bd2f-43b0c2150722 Yorgos do you still crash? (In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #34) > I believe bug 837438 is a predecessor for a large percentage of this crash > signature I'm no longer certain about this, now that I've determined bug 804742 should have helped.
Flags: needinfo?(condacum)
Since ff43 I have much bigger problems https://bugzilla.mozilla.org/show_bug.cgi?id=1222272 also my FF is dead, since Mozilla removed the hardware acceleration. I cannot test this bug you are asking to me.
Flags: needinfo?(condacum)
(In reply to Yorgos from comment #39) > Since ff43 I have much bigger problems > https://bugzilla.mozilla.org/show_bug.cgi?id=1222272 > also my FF is dead, since Mozilla removed the hardware acceleration. I > cannot test this bug you are asking to me. Thanks for the replyl. My bad - your crash is Firefox so this is really the wrong bug report for you, because this bug is being handled as a Thunderbird-only bug report.
Summary: TB is crashing [@ OOM | small ] calling nsJSID::NewID from xpc_NewIDObject → Thunderbird is crashing [@ OOM | small ] calling nsJSID::NewID from xpc_NewIDObject
But I had the same crash in FF ;) then I followed this new link.
I dont have Thunderbird, I had Crash Report [@ OOM | small ]
rocktman recently wrote me "I'm currently on 38.0.1 ... As my last report dated 5/20/15 indicated, I had had a last crash on 4/25/15. Why the crashes started & then stopped by themselves I haven't a clue. So it's not really correct to say that 38 solved my problems." Also, I no longer see stacks containing nsJSID. So I'm closing this bug. That said, OOM | Small is #5 crash for Thunderbird for 38.6.0. And approximately 45% have >1GB free virtual memory! (per several thousand reports on crash-stats) For example bp-52a3414b-4661-433b-a62d-b82012160305 bp-3177295a-2f00-445c-a5fc-d5b622160306 bp-26d1bae4-4eaf-4035-bcd2-3f79b2160305 So crashes "not OOM" crashes will need to be investigated - which I started to do about a year ago. (For example, back then a very high percent of users have yahoo.fr, orange.fr, wanadoo.fr, and free.fr addresses. What that might indicate I don't know - an issue related to language/internationalization?) Anyway, will file new bugs as needed.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 9 years ago
Resolution: --- → WORKSFORME
See Also: → 1256224
You need to log in before you can comment on or make changes to this bug.