![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 17/12/2018 07.42, ken wrote:
On 12/16/18 9:09 AM, Carlos E. R. wrote:
Well, no more crashes so far. Go figure. I will watch it, though.
Since yesterday night, the machine is running Thunderbird, Firefox, Chrome, and Kodi, no issues. Perfectly responsive with that large load.
Sorry for being late to the thread. I've had quite similar problems several times in the past, found them to be due to specific web pages, probably running bad javascript. When I close the offending webpage, the problem goes away.
For a long time I've been using a Firefox add-in called NoScript. It allows me to turn on/off specific URLs from which scripts are delivered. It's a nice app, but would be much better if it had some intelligence to detect when a script was devouring RAM and at least flash a notice of the (potential) problem. As it is, that task is left to the user... and it's no trivial exercise. The best that "top" provides is one of the "Web Content" processes, but not which window or tab or site. The PID numbering might, in more orderly scenarios, offer a plausible guess as to the offending process. But I haven't yet tried simply killing it... don't know what further hell that might unleash upon an important session. Javascript coders should test their stuff better before they loose it on the public, as should web developers. As it is, we all become the beta testers.
That's a possibility, and in my tests I had Firefox opened at the same pages. The suspicious one belongs to my own router. But you see, the laptop can be fine for an hour or ten hours, and then suddenly it goes caput. The issue is not high memory load, but that a lot of that memory tries to be active instead of in swap. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)