I have one theory about how-to-repro here... I haven't repro'd the actual crash, but I've managed to trigger something odd that could conceivably crash. My STR: 1. Copy a giant `places.sqlite` into a fresh profile (so as not to corrupt your regular profile). 2. Start Firefox using that fresh profile. 3. History | Show All HIstory 4. Click "Older than 6 months" 5. Select-all in the right window. For me, this shows "27000 results" or so. 6. Now **press-and-hold your delete key on your keyboard** (or alternately: press it rapidly & repeatedly). Keep doing this, for tens of seconds. Watch how Firefox performs, watch its memory-usage in "top". 7. If your selection gets lost (I think it occasionally did), then repeat steps 5-6. ACTUAL RESULTS: * The reported number of selected history-items holds steady (i.e. nothing obviously being deleted) for an unusual amount of time. Or it might go down a bit but then stop going down. * Memory usage steadily increases -- Firefox consumes another ~1% of my system memory (64GB) every couple seconds. * Firefox is often unresponsive; e.g. I can open tabs but sites won't load. I'm guessing we're queuing up and servicing history-deletion-handlers for each "del" keypress, so if you hold "Del" down, we queue up a zillion handlers, consuming memory & resources with redundant handlers. The handlers also probably run into each other (maybe getting handles on the same history items?) as they're serviced; and my parent process is pegged with these handlers and can't perform other actions on behalf of child processes. I wouldn't be surprised if the crash reports are just cases where users are doing something like this^ and running into some sort of limit (e.g. addreffing a handle into oblivion as we accumulate tasks, or something along those lines? Or running out of memory; though at first glance it doesn't look like this was an OOM.)
Bug 1809492 Comment 15 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I have one theory about how-to-repro here... I haven't repro'd the actual crash, but I've managed to trigger something odd that could conceivably crash. My STR: 1. Copy a giant `places.sqlite` into a fresh profile (so as not to corrupt your regular profile). I'm using my regular browsing profile's `places.squlite` file. 2. Start Firefox using that fresh profile. 3. History | Show All HIstory 4. Click "Older than 6 months" 5. Select-all in the right window. For me, this shows "27000 results" or so. 6. Now **press-and-hold your delete key on your keyboard** (or alternately: press it rapidly & repeatedly). Keep doing this, for tens of seconds. Watch how Firefox performs, watch its memory-usage in "top". 7. If your selection gets lost (I think it occasionally did), then repeat steps 5-6. ACTUAL RESULTS: * The reported number of selected history-items holds steady (i.e. nothing obviously being deleted) for an unusual amount of time. Or it might go down a bit but then stop going down. * Memory usage steadily increases -- Firefox consumes another ~1% of my system memory (64GB) every couple seconds. * Firefox is often unresponsive; e.g. I can open tabs but sites won't load. I'm guessing we're queuing up and servicing history-deletion-handlers for each "del" keypress, so if you hold "Del" down, we queue up a zillion handlers, consuming memory & resources with redundant handlers. The handlers also probably run into each other (maybe getting handles on the same history items?) as they're serviced; and my parent process is pegged with these handlers and can't perform other actions on behalf of child processes. I wouldn't be surprised if the crash reports are just cases where users are doing something like this^ and running into some sort of limit (e.g. addreffing a handle into oblivion as we accumulate tasks, or something along those lines? Or running out of memory; though at first glance it doesn't look like this was an OOM.)