Closed
Bug 1382939
Opened 7 years ago
Closed 7 years ago
Crash related to IndexedDB
Categories
(Core :: Storage: IndexedDB, defect, P5)
Tracking
()
RESOLVED
INVALID
People
(Reporter: keean, Unassigned)
Details
(Keywords: crash)
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20151014143721
Steps to reproduce:
Running some intensive IndexedDB queries that read and store data on Firefox 42.0.1 I get the following crash:
Actual results:
Here is the crash report
AbortMessage: [Parent 2336] ###!!! ABORT: IPDL error [PBackgroundIDBRequestChild]: "Error deserializing 'fileInfos' (intptr_t[]) member of 'SerializedStructuredCloneReadInfo'". abort()ing as a result.: file c:/builds/moz2_slave/rel-m-rel-w32_bld-000000000000/build/ipc/glue/ProtocolUtils.cpp, line 334
AdapterDeviceID: 0xbeef
AdapterDriverVersion: 5.0.32.0
AdapterSubsysID: 00000000
AdapterVendorID: 0x80ee
Add-ons: %7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D:41.0.2,jid1-fRvgLzKONCsPew%40jetpack:0.2.7
AvailablePageFile: 477343744
AvailablePhysicalMemory: 239636480
AvailableVirtualMemory: 479379456
BIOS_Manufacturer: innotek GmbH
BlockedDllList:
BreakpadReserveAddress: 32833536
BreakpadReserveSize: 67108864
BuildID: 20151014143721
CrashTime: 1500616312
EMCheckCompatibility: true
Email:
FramePoisonBase: 00000000f0de0000
FramePoisonSize: 65536
InstallTime: 1493993117
Notes: AdapterVendorID: 0x80ee, AdapterDeviceID: 0xbeef, AdapterSubsysID: 00000000, AdapterDriverVersion: 5.0.32.0
D3D11 Layers- xpcom_runtime_abort([Parent 2336] ###!!! ABORT: IPDL error [PBackgroundIDBRequestChild]: "Error deserializing 'fileInfos' (intptr_t[]) member of 'SerializedStructuredCloneReadInfo'". abort()ing as a result.: file c:/builds/moz2_slave/rel-m-rel-w32_bld-000000000000/build/ipc/glue/ProtocolUtils.cpp, line 334)
ProductID: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
ProductName: Firefox
ReleaseChannel: release
SafeMode: 0
SecondsSinceLastCrash: 790
StartupTime: 1500615589
SystemMemoryUsePercentage: 77
TelemetryEnvironment: {"build":{"applicationId":"{ec8030f7-c20a-464f-9b0e-13a3a9e97384}","applicationName":"Firefox","architecture":"x86","buildId":"20151014143721","version":"41.0.2","vendor":"Mozilla","platformVersion":"41.0.2","xpcomAbi":"x86-msvc","hotfixVersion":null},"partner":{"distributionId":null,"distributionVersion":null,"partnerId":null,"distributor":null,"distributorChannel":null,"partnerNames":[]},"system":{"memoryMB":1024,"isWow64":false,"cpu":{"count":1,"vendor":null,"family":null,"model":null,"stepping":null,"extensions":["hasMMX","hasSSE","hasSSE2","hasSSE3","hasSSSE3","hasSSE4_1","hasSSE4_2"]},"os":{"name":"Windows_NT","version":"6.1","servicePackMajor":1,"servicePackMinor":0,"installYear":2013,"locale":"en-US"},"hdd":{"profile":{"model":"VBOX HARDDISK","revision":"1.0"},"binary":{"model":"VBOX HARDDISK","revision":"1.0"},"system":{"model":"VBOX HARDDISK","revision":"1.0"}},"gfx":{"D2DEnabled":false,"DWriteEnabled":false,"adapters":[{"description":"VirtualBox Graphics Adapter","vendorID":"0x80ee","deviceID":"0xbeef","subsysID":"00000000","RAM":null,"driver":"VBoxDisp","driverVersion":"5.0.32.0","driverDate":"1-16-2017","GPUActive":true}],"monitors":[{"screenWidth":2560,"screenHeight":1332,"refreshRate":60,"pseudoDisplay":false}]}},"settings":{"addonCompatibilityCheckEnabled":true,"blocklistEnabled":true,"isDefaultBrowser":true,"e10sEnabled":false,"telemetryEnabled":false,"isInOptoutSample":false,"locale":"en-GB","update":{"channel":"release","enabled":false,"autoDownload":false},"userPrefs":{"app.update.auto":false,"app.update.enabled":false,"app.update.service.enabled":false,"browser.cache.disk.capacity":358400,"browser.newtabpage.enhanced":true}},"profile":{"creationDate":17291},"addons":{"activeAddons":{"jid1-fRvgLzKONCsPew@jetpack":{"blocklisted":false,"description":"Tab Memory Usage displays the amount of memory is used by each tab","name":"Tab Memory Usage","userDisabled":false,"appDisabled":false,"version":"0.2.7","scope":1,"type":"extension","foreignInstall":false,"hasBinaryComponents":false,"installDay":17351,"updateDay":17351,"signedState":2}},"theme":{"id":"{972ce4c6-7e08-4474-a285-3208198ce6fd}","blocklisted":false,"description":"The default theme.","name":"Default","userDisabled":false,"appDisabled":false,"version":"41.0.2","scope":4,"foreignInstall":false,"hasBinaryComponents":false,"installDay":17291,"updateDay":17291},"activePlugins":[],"activeGMPlugins":{"gmp-gmpopenh264":{"version":"1.5.3","userDisabled":false,"applyBackgroundUpdates":1},"gmp-eme-adobe":{"version":"15","userDisabled":false,"applyBackgroundUpdates":1}},"activeExperiment":{},"persona":null}}
Theme: classic/1.0
Throttleable: 1
TotalPageFile: 2172182528
TotalPhysicalMemory: 1073274880
TotalVirtualMemory: 2147352576
URL: http://10.186.136.100/html5/
Vendor: Mozilla
Version: 41.0.2
Winsock_LSP: MSAFD Tcpip [TCP/IP] : 2 : 1 : %SystemRoot%\system32\mswsock.dll
MSAFD Tcpip [UDP/IP] : 2 : 2 :
MSAFD Tcpip [RAW/IP] : 2 : 3 : %SystemRoot%\system32\mswsock.dll
MSAFD Tcpip [TCP/IPv6] : 2 : 1 :
MSAFD Tcpip [UDP/IPv6] : 2 : 2 : %SystemRoot%\system32\mswsock.dll
MSAFD Tcpip [RAW/IPv6] : 2 : 3 :
RSVP TCPv6 Service Provider : 2 : 1 : %SystemRoot%\system32\mswsock.dll
RSVP TCP Service Provider : 2 : 1 :
RSVP UDPv6 Service Provider : 2 : 2 : %SystemRoot%\system32\mswsock.dll
RSVP UDP Service Provider : 2 : 2 :
MSAFD NetBIOS [\Device\NetBT_Tcpip_{A2692622-D935-45DD-BC6A-0FEA4F88524C}] SEQPACKET 3 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip_{A2692622-D935-45DD-BC6A-0FEA4F88524C}] DATAGRAM 3 : 2 : 2 :
MSAFD NetBIOS [\Device\NetBT_Tcpip_{F5715A0B-5A70-451A-BFDD-1D39494152A1}] SEQPACKET 1 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip_{F5715A0B-5A70-451A-BFDD-1D39494152A1}] DATAGRAM 1 : 2 : 2 :
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{066F8867-DFB0-441A-82D4-1A68DC59CB04}] SEQPACKET 6 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{066F8867-DFB0-441A-82D4-1A68DC59CB04}] DATAGRAM 6 : 2 : 2 :
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{E0BF89A4-3186-4298-920B-231C75AE911E}] SEQPACKET 5 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{E0BF89A4-3186-4298-920B-231C75AE911E}] DATAGRAM 5 : 2 : 2 :
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{A2692622-D935-45DD-BC6A-0FEA4F88524C}] SEQPACKET 4 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{A2692622-D935-45DD-BC6A-0FEA4F88524C}] DATAGRAM 4 : 2 : 2 :
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{8287407F-E4D9-4618-A04B-846F9D6E7608}] SEQPACKET 0 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{8287407F-E4D9-4618-A04B-846F9D6E7608}] DATAGRAM 0 : 2 : 2 :
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{F5715A0B-5A70-451A-BFDD-1D39494152A1}] SEQPACKET 2 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{F5715A0B-5A70-451A-BFDD-1D39494152A1}] DATAGRAM 2 : 2 : 2 :
useragent_locale: en-GB
This report also contains technical information about the state of the application when it crashed.
Expected results:
It should not crash :-)
Actually I am restricted to the released version of Firefox 42.0.1 (because I am using xulrunner), so I am not looking for a bug-fix (it is probably fixed already), I am looking to understand what caused the crash, so I can find a work-around in JavaScript to avoid the crash in the first place.
|
||
Updated•7 years ago
|
|
||
Comment 1•7 years ago
|
||
According to that this issue is on a very old version firefox 42, this is a very very low priority for us. I am looping some IDB folks in and see if they have thoughts to share.
Priority: -- → P5
I appreciate it is a low priority, however version 42 is still the current release of xulrunner.
|
||
Comment 3•7 years ago
|
||
(In reply to keean from comment #2) > I appreciate it is a low priority, however version 42 is still the current > release of xulrunner. I believe you can still use any release of Firefox like it's xulrunner. "firefox -app application.ini" Note, however, that this doesn't make it any more officially supported, it just means you can use more recent versions of Firefox. This particular problem looks like it's case of insufficient memory or memory address space (possibly due to fragmentation, but it could also just be insufficient memory). The crash report seems to indicate the system only has 1GiB of physical memory, 2GiB of page-file, and 2GiB of address space accessible to Firefox in total. You should probably be able to bring up "about:memory" in xulrunner or in a modern version of Firefox using "-app" which may help shed some light on what's using up memory and/or address space. You may be also able to trigger devtools, although I'm not sure. In general, I think the best advice I can give is: - Retrieve less at a time from IndexedDB. For example, use cursors or use smaller limits if using mozGetAll, things like that. - Consider triggering (full) garbage collections more frequently via https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMWindowUtils#garbageCollect() or https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Language_Bindings/Components.utils.forceGC or other methods. - Favor use of Blobs over typed arrays/array buffers if you won't always need access to large hunks of data when retrieving them. Make sure that once you store a blob into IndexedDB you read it back and forget the original blob you put in so your memory-backed blob can be freed. - Try running on a machine with more memory. We now have 64-bit builds of Firefox for windows, plus 32-bit builds of Firefox are happier on 64-bits of windows, so it's possible to reduce/eliminate issues. This may not be possible for a variety of reasons, This is definitely something that's not actionable from an IndexedDB perspective, so I'm going to mark this invalid. I'm honestly not too sure where the developer community for xulrunner-type things hangs out, but I'd suggest if you experience additional issues, to check out: - The add-ons discourse (although I presume there are active efforts to move discussion to just being about webextensions): https://discourse.mozilla-community.org/c/add-ons/development - Maybe something listed at https://www.mozilla.org/en-US/about/forums/? I was thinking we used to have newsgroups active in this area, but maybe I'm wrong.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
|
|
||
Comment 4•7 years ago
|
||
(In reply to Andrew Sutherland [:asuth] from comment #3) > This may not be possible for a variety of reasons, Whoops, didn't finish my thought. Mainly, I know extra resources may not be available or the specific goal may be to use existing resources, but this specific crash is an indication of a case where throwing resources at the problem is a quick and easy fix.
Thanks for the response, I have done some profiling. I am retrieving 16meg chunks from indexeddb processing and writing again. The memory problem appears due to memory pressure, as there is no way to wait for the writes to complete it slowly runs out of buffer space. This is a time critical operation, so I don't want to do smaller chunks as it would be even slower. Ideally I want to do larger chunks. Blobs are worse because they do not commit to disk immediately either, and just make the whole memory pressure problem worse, as you force commit and you cannot wait until they have written. Experimentally Blobs make the application even more memory unstable. The target system for this application is 32bit with 1GB of RAM, and as it is reading 16meg chunks this is plenty. What I am writing is a single page app, but it needs to run in a specific version of Firefox, at least for now that is fixed at v42, however v51 may be supported eventually. I think the issue is to do with the API and therefore is not fixed in newer versions, although they do seem to behave a bit better. What really needs to happen is that VM and write buffers need to be in a unified buffer cache (like the linux kernel does for example), so that memory allocation can be aware of space in write buffers, and can force a flush and wait for the buffer space to be free. Memory allocation should only fail if the free RAM plus pending write buffer space is smaller than the requested memory size.
(In reply to Andrew Sutherland [:asuth] from comment #4) > (In reply to Andrew Sutherland [:asuth] from comment #3) > > This may not be possible for a variety of reasons, > > Whoops, didn't finish my thought. Mainly, I know extra resources may not be > available or the specific goal may be to use existing resources, but this > specific crash is an indication of a case where throwing resources at the > problem is a quick and easy fix Forgot to use reply, so my response is just a normal comment.
|
|
||
Comment 7•7 years ago
|
||
If you're retrieving data from IndexedDB and writing it back to IndexedDB without applying a transformation, then Blobs will be beneficial. They're stored separately from the structured clone data as reference-counted files on disk. This avoids unnecessary reads, writes, and IPC traffic. (Especially since I'm assuming you're necessarily running single process, and same-process blobs don't have to be serialized.) Also note that Blobs are, for all intents and purposes, written to disk at the same time their content would have been written if they were arraybuffers. And because of the reference counting, they're only written to disk the first time they are used in a transaction. They also may exhibit superior I/O characteristics since they're written as append-only new files and aren't subject to SQLite's WAL or page-centric storage (which can result in fragmentation if the pages aren't being added to the end of the database). Note that Firefox 52 has a major improvement here with bug 964561 where large structured clones (>=1MiB) get stored outside the database like they were blobs. It's likely upgrading to 52+ would result in a major I/O win for that reason. That said, if every byte of data from a record you retrieve will need to be processed, blobs will potentially be a net loss over using arraybuffers since the act of creating the blob currently will duplicate the contents of its source arraybuffer and then you're more dependent on GC than you'd otherwise be. However, this can again be mitigated by ensuring you've dropped references to the source arraybuffer and the blob and forcing a GC. Re: "as there is no way to wait for the writes to complete", I'm a little confused. You can absolutely wait for the IDBRequest.onsuccess event to know when the data has hit disk in a speculative SQLite transaction, thereby knowing when the memory from the write request has been freed (for non-blobs). And you can also wait for the IDBTransaction.oncomplete event to know when that transaction has been durably committed (which also implies all of the requests have fired their success events already). This should provide for adequate flow control and largely saturate device I/O, but you can reduce chunk sizes and have more requests/transactions in flight at a given time if necessary. re: fancier buffering strategies, it's possible SharedArrayBuffers may eventually provide affordances along these lines, but we're not there yet.
This is apparently from the docs somewhere:
> Note that as of Firefox 40, IndexedDB transactions have relaxed durability guarantees to increase performance (see bug 1112702.) Previously in a readwrite transaction IDBTransaction.oncomplete was fired only when all data was guaranteed to have been flushed to disk. In Firefox 40+ the complete event is fired after the OS has been told to write the data but potentially before that data has actually been flushed to disk.
I am processing every byte at one point (from ciphertext to plaintext using webcrypto), but I also shuffle the data at other points (XMLHttpRequest fetch to indexeddb as 16meg chunks. Then read 16meg chunk decrypt and write back, finally data is uncompressed by streaming a the 16 meg chunks and split into separate resources written back to indexeddb.
Either I have an elusive memory leak, or the delay in releasing the write buffers is causing eventual memory starvation. I am careful about setting arraybuffers and blobs to null after writing to indexeddb.This is the latest crash report:
AdapterDeviceID: 0xbeef
AdapterDriverVersion: 5.0.32.0
AdapterSubsysID: 00000000
AdapterVendorID: 0x80ee
Add-ons: %7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D:41.0.2,jid1-fRvgLzKONCsPew%40jetpack:0.2.7
AvailablePageFile: 840359936
AvailablePhysicalMemory: 238616576
AvailableVirtualMemory: 691482624
BIOS_Manufacturer: innotek GmbH
BlockedDllList:
BreakpadReserveAddress: 30015488
BreakpadReserveSize: 67108864
BuildID: 20151014143721
CrashTime: 1500704975
EMCheckCompatibility: true
Email:
EventLoopNestingLevel: 1
FramePoisonBase: 00000000f0de0000
FramePoisonSize: 65536
InstallTime: 1493993117
Notes: AdapterVendorID: 0x80ee, AdapterDeviceID: 0xbeef, AdapterSubsysID: 00000000, AdapterDriverVersion: 5.0.32.0
D3D11 Layers-
OOMAllocationSize: 16777276
ProductID: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
ProductName: Firefox
ReleaseChannel: release
SafeMode: 0
SecondsSinceLastCrash: 41836
StartupTime: 1500672944
SystemMemoryUsePercentage: 77
TelemetryEnvironment: {"build":{"applicationId":"{ec8030f7-c20a-464f-9b0e-13a3a9e97384}","applicationName":"Firefox","architecture":"x86","buildId":"20151014143721","version":"41.0.2","vendor":"Mozilla","platformVersion":"41.0.2","xpcomAbi":"x86-msvc","hotfixVersion":null},"partner":{"distributionId":null,"distributionVersion":null,"partnerId":null,"distributor":null,"distributorChannel":null,"partnerNames":[]},"system":{"memoryMB":1024,"isWow64":false,"cpu":{"count":1,"vendor":null,"family":null,"model":null,"stepping":null,"extensions":["hasMMX","hasSSE","hasSSE2","hasSSE3","hasSSSE3","hasSSE4_1","hasSSE4_2"]},"os":{"name":"Windows_NT","version":"6.1","servicePackMajor":1,"servicePackMinor":0,"installYear":2013,"locale":"en-US"},"hdd":{"profile":{"model":"VBOX HARDDISK","revision":"1.0"},"binary":{"model":"VBOX HARDDISK","revision":"1.0"},"system":{"model":"VBOX HARDDISK","revision":"1.0"}},"gfx":{"D2DEnabled":false,"DWriteEnabled":false,"adapters":[{"description":"VirtualBox Graphics Adapter","vendorID":"0x80ee","deviceID":"0xbeef","subsysID":"00000000","RAM":null,"driver":"VBoxDisp","driverVersion":"5.0.32.0","driverDate":"1-16-2017","GPUActive":true}],"monitors":[{"screenWidth":2560,"screenHeight":1332,"refreshRate":60,"pseudoDisplay":false}]}},"settings":{"addonCompatibilityCheckEnabled":true,"blocklistEnabled":true,"isDefaultBrowser":true,"e10sEnabled":false,"telemetryEnabled":false,"isInOptoutSample":false,"locale":"en-GB","update":{"channel":"release","enabled":false,"autoDownload":false},"userPrefs":{"app.update.auto":false,"app.update.enabled":false,"app.update.service.enabled":false,"browser.cache.disk.capacity":358400,"browser.newtabpage.enhanced":true}},"profile":{"creationDate":17291},"addons":{"activeAddons":{"jid1-fRvgLzKONCsPew@jetpack":{"blocklisted":false,"description":"Tab Memory Usage displays the amount of memory is used by each tab","name":"Tab Memory Usage","userDisabled":false,"appDisabled":false,"version":"0.2.7","scope":1,"type":"extension","foreignInstall":false,"hasBinaryComponents":false,"installDay":17351,"updateDay":17351,"signedState":2}},"theme":{"id":"{972ce4c6-7e08-4474-a285-3208198ce6fd}","blocklisted":false,"description":"The default theme.","name":"Default","userDisabled":false,"appDisabled":false,"version":"41.0.2","scope":4,"foreignInstall":false,"hasBinaryComponents":false,"installDay":17291,"updateDay":17291},"activePlugins":[],"activeGMPlugins":{"gmp-gmpopenh264":{"version":"1.5.3","userDisabled":false,"applyBackgroundUpdates":1},"gmp-eme-adobe":{"version":"15","userDisabled":false,"applyBackgroundUpdates":1}},"activeExperiment":{},"persona":null}}
Theme: classic/1.0
Throttleable: 1
TotalPageFile: 2172182528
TotalPhysicalMemory: 1073274880
TotalVirtualMemory: 2147352576
URL: http://10.186.136.100/html5/
Vendor: Mozilla
Version: 41.0.2
Winsock_LSP: MSAFD Tcpip [TCP/IP] : 2 : 1 : %SystemRoot%\system32\mswsock.dll
MSAFD Tcpip [UDP/IP] : 2 : 2 :
MSAFD Tcpip [RAW/IP] : 2 : 3 : %SystemRoot%\system32\mswsock.dll
MSAFD Tcpip [TCP/IPv6] : 2 : 1 :
MSAFD Tcpip [UDP/IPv6] : 2 : 2 : %SystemRoot%\system32\mswsock.dll
MSAFD Tcpip [RAW/IPv6] : 2 : 3 :
RSVP TCPv6 Service Provider : 2 : 1 : %SystemRoot%\system32\mswsock.dll
RSVP TCP Service Provider : 2 : 1 :
RSVP UDPv6 Service Provider : 2 : 2 : %SystemRoot%\system32\mswsock.dll
RSVP UDP Service Provider : 2 : 2 :
MSAFD NetBIOS [\Device\NetBT_Tcpip_{A2692622-D935-45DD-BC6A-0FEA4F88524C}] SEQPACKET 3 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip_{A2692622-D935-45DD-BC6A-0FEA4F88524C}] DATAGRAM 3 : 2 : 2 :
MSAFD NetBIOS [\Device\NetBT_Tcpip_{F5715A0B-5A70-451A-BFDD-1D39494152A1}] SEQPACKET 1 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip_{F5715A0B-5A70-451A-BFDD-1D39494152A1}] DATAGRAM 1 : 2 : 2 :
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{066F8867-DFB0-441A-82D4-1A68DC59CB04}] SEQPACKET 6 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{066F8867-DFB0-441A-82D4-1A68DC59CB04}] DATAGRAM 6 : 2 : 2 :
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{E0BF89A4-3186-4298-920B-231C75AE911E}] SEQPACKET 5 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{E0BF89A4-3186-4298-920B-231C75AE911E}] DATAGRAM 5 : 2 : 2 :
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{A2692622-D935-45DD-BC6A-0FEA4F88524C}] SEQPACKET 4 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{A2692622-D935-45DD-BC6A-0FEA4F88524C}] DATAGRAM 4 : 2 : 2 :
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{8287407F-E4D9-4618-A04B-846F9D6E7608}] SEQPACKET 0 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{8287407F-E4D9-4618-A04B-846F9D6E7608}] DATAGRAM 0 : 2 : 2 :
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{F5715A0B-5A70-451A-BFDD-1D39494152A1}] SEQPACKET 2 : 2 : 5 : %SystemRoot%\system32\mswsock.dll
MSAFD NetBIOS [\Device\NetBT_Tcpip6_{F5715A0B-5A70-451A-BFDD-1D39494152A1}] DATAGRAM 2 : 2 : 2 :
useragent_locale: en-GB
This report also contains technical information about the state of the application when it crashed.
I wonder if it is memory fragmentation?
|
Reporter | |
Comment 10•7 years ago
|
||
(In reply to Andrew Sutherland [:asuth] from comment #7) > If you're retrieving data from IndexedDB and writing it back to IndexedDB ... It's very odd, if I pause the operations in the middle and look at free memory, the code is using 8.7 Meg, yet it still runs out of memory in the process. It really looks like it cannot reclaim the used memory fast enough, and I don't think I can force a GC from normal JavaScript inside Firefox.
|
|
||
Comment 11•7 years ago
|
||
If you're a XULRunner app, that means you have a top-level XUL window somewhere. The JavaScript in that window runs with the system ("chrome") principal, has the Components magic global available, and can do anything. You only lose this principal once you nest content inside a XUL iframe with type=content/content-primary/content-targetable. See https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/iframe#a-browser.type and the links I provided previously on triggering GC's. You should be able to find specific uses of them in varying contexts by using https://searchfox.org./
You need to log in
before you can comment on or make changes to this bug.
Description
•