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).
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.)
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.)

Back to Bug 1809492 Comment 15