Open Bug 1328545 Opened 4 years ago Updated 2 years ago
Crash [@ OOM | small ] with Fragment
Or Element .cpp involved
Found via bughunter and reproduced with latest tinderbox opt windows builds on beta and trunk Steps to reproduce: -> Load http://results.jukola.com/tulokset/results_j2016_ju.xml ---> Crash in opt builds after 10 -> 30 seconds affects trunk to beta builds Crash ID: https://crash-stats.mozilla.com/report/index/4bdddf42-cd3f-48f2-8adb-d8d962170104
[Tracking Requested - why for this release]: Tobias is this something for you ? Or do you know who could take a look, thanks!
I can go ahead and track this for 51 and up, if we come up with a patch we can certainly consider uplifting since improving the OOM crash rate would be a good thing. Andrew can you help find someone to investigate? Thanks!
That crash-stat is showing us crashing deep inside DOM when doing a tiny allocation. Making that particular case fallible wouldn't be reasonable. /me wonders how Tomcat managed to find that page. Results in a massive xml file from a small-ish Finnish sport happening :)
FWIW, the page crashes the child process on Chrome too.
I'm not sure how important XML issues are (and thus need to be tracked). Are these crashes frequent?
Flags: needinfo?(overholt) → needinfo?(cbook)
(In reply to Andrew Overholt [:overholt] from comment #5) > I'm not sure how important XML issues are (and thus need to be tracked). Are > these crashes frequent? well i have also no idea how important just found this as real-world-website example for this crash.
Dropping this for 53 since it does not seem actionable. Is this anything you want to dig deeper into or shall we leave it alone?
It is trivial to crash any browser (child process) by just creating more and more elements, so I don't see there anything we can do.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.