Crash while opening web page

[michaelsnyder]

As the page was loading, 24.8.1 beta 3 crashed. Page had a video embedded in it. Trap file is at https://www.dropbox.com/s/o2fwu03m3itlzw5/01A2_01.TRP?dl=0

[michaelsnyder]

Another trap loading a similar page. https://www.dropbox.com/s/lpzwwujcu9zkxwm/0733_01.TRP?dl=0

[SilvanScherrer]

thats a flash problem. please rename/remove flash from the plugins directory. Flash is known to crash the browser. We might work on flash a bit later this year.

[SilvanScherrer]

did you ever disable flash and retest?

[SilvanScherrer]

did you test with latest firefox 45

[michaelsnyder]

On 06/06/17 at 03:31 AM, Silvan Scherrer notifications@github.com said:

did you test with latest firefox 45

Didn't know that you'd released it until I got your email. Yes. I installed / updated all of the libraries and installed it. People are likely to copy your YUM commands directly from the readme, so if you have a carriage return line feed in the middle of the command, it will not run properly. Sometimes it takes more than one try to notice that everything after the cr/lf has generated an error message. Maybe you could write out the line and let the user's program wrap the line or not?

The program still crashed a few times, but it's far more stable than the last version. Unfortunately, it did not generate a .trp file any time it crashed.

--

---

"Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong remedies. - Groucho Marx Progressivism is Lysenkoism

Mike Snyder msnyder1@cfl.rr.com

[SilvanScherrer]

did you disable flash? is yes it has to generate a trp file.

[michaelsnyder]

On 06/07/17 at 12:02 AM, Silvan Scherrer notifications@github.com said:

did you disable flash? is yes it has to generate a trp file.

The only plugin is the one that is installed by default. I know that it's strange, but Firefox quit a couple of times yesterday without generating a .trp file that I could find. They're supposed to be in the directory that firefox.exe is in, aren't they?

-- Mike Snyder msnyder1@cfl.rr.com

[dmik]

.TRP files are generated in what is set as current dir in the process. Normally this is where firefox.exe resides, yes. Note that with FF45, .TRP files should be always created, as the trap handler is installed from a LIBC extension library, beyond user code control. So the only reason that comes to my mind is that it traps for you in some old plugin DLL (as already mentioned by Silvan). You may simply ,try to search for .TRP files on all your drives. And also make sure you removed all plugins from MOZ_PLUGIN_PATH and created a new FF profile — for the sake of testing.

[dmik]

Also, giving the exact URL where it crashes for you would help. There is one known crash in FF related to painting some web content, see #212.

[michaelsnyder]

On 06/07/17 at 04:59 AM, Dmitriy Kuminov notifications@github.com said:

.TRP files are generated in what is set as current dir in the process. Normally this is where firefox.exe resides, yes. Note that with FF45, .TRP files should be always created, as the trap handler is installed from a LIBC extension library, beyond user code control. So the only reason that comes to my mind is that it traps for you in some old plugin DLL (as already mentioned by Silvan). You may simply ,try to search for .TRP files on all your drives. And also make sure you removed all plugins from MOZ_PLUGIN_PATH and created a new FF profile for the sake of testing.

The plugins directory is empty. The OpenH264 plugin is the only one installed. The program often asks whether I want to create a new profile when I start it, even when I started it for the first time after the latest installation. I let it do that, so everything is as you have specified. I'll send a .trp file when it generates one.

--

---

Mike Snyder msnyder1@cfl.rr.com

[michaelsnyder]

Hi there,

Michael Snyder (msnyder1@cfl.rr.com) invited you to view the file " 00E7_01.TRP " on Dropbox.

View file1

Enjoy! The Dropbox team

[michaelsnyder]

The trap file above was generated by this page: http://www.theamericanmirror.com/twitter-verifies-bill-clinton-son-bubba/

I scrolled the page as it was still loading some stuff. This was with the 45.5.0 and all updates called for by the readme as of yesterday.

[michaelsnyder]

Hi there,

In case you missed it, Michael Snyder (msnyder1@cfl.rr.com) shared "00E7_01.TRP" with you on Dropbox.

View on Dropbox1

Thanks!

• The Dropbox Team

---

Want to stop getting invites from Dropbox? Unsubscribe2 Dropbox, Inc., PO Box 77767, San Francisco, CA 94107

[StevenLevine]

This looks like an uncaught out of memory condition. The trap is at:

15DAAEE4 >MOV EAX, [EBX] (8b03)

and EBX is a small number, probably an offset into a structure.

Have you marked XUL.DLL to load its data segment in high memory?

FWIW, with github, it's more efficient to use gist to upload .trp files that are too large to upload here directly.

[dmik]

I can't reproduce your crash, all works on that page here, including the video. And can't see the .TRP file either as I have no access — you better rename it to .TRP.txt and upload here directly or use gist as Steven suggests.

[michaelsnyder]

file:///D:/firefox_45_5_0/00E7_01.txt I don't know how to mark xul.dll to load into high memory. Please explain.

[dmik]

Reattaching the trap file here, for reference: 00E7_01.TRP.txt

Also please answer if you load XUL DLLs high and which is your VIRTUALADDRESSLIMIT in config.sys, how much memory you have and if it happens when you run something else in parallel or just a sole FF after a fresh reboot.

[michaelsnyder]

I don't know how to load xul.dll into high memory. Config.sys has virtualaddresslimit=3072. I don't remember why I set it to that, but if you have a suggestion, I'll try it. I believe that the computer has 4 Gb of memory. I almost always have MR/2 ICE running, as well as lbmix, upsmonitor, ftpserver, cron/2, and Relish. Sometimes Firefox runs for a while before crashing. :-)

[dmik]

Ok, so it's most likely an out of memory issue. Not much we can do here. At least not easily. Try to lower VAL to e.g. 2560 to see if it makes any difference.

[dspiatkowski]

On Tue, 13 Jun 2017 04:22:59 -0700, Dmitriy Kuminov wrote:

Ok, so it's most likely an out of memory issue. Not much we can do here. At least not easily. Try to lower VAL to e.g. 2560 to see if it makes any difference.

You could try using a memory usage monitor...I have 'PU Monitor' app installed on my machine...FF (38.x currently in use, can not run 45.x due to the un-responsiveness issue I reported earlier, see ticket #208 from about a month ago) will usually work fine until I see about 1Gig of memory left, at which point in time it will routinely die...I suspect this all has to do with how much shared vs private memory is left.

The short time that I tried using 45.x it seemed like the app was better "behaved" in terms of memory usage, but unfortunately I really could not get enough consisten long-term use (my machine is up 24x7 with things like FF running all the time).

In the case of this particular ticket though, if FF dies while openning the page and FF itself was just recently started one would not expect the total memory consumption to be a root cause, correct? The implication is that there isn't enough runtime yet for the available memory to have been exhausted...

[dmik]

Yes, FF45 should behave much better in terms of memory usage by JS (upstream improvements).

[michaelsnyder]

Changed VAL to 2560. I found a reverence to using highmem.exe to mark xul.dll for loading into high memory, so I'll try that for a while. Daruisz is correct that it would usually crash shortly after being opened and while it was trying to load a page. This version does seem to be much more stable than the previous ones. There seems to be a lot of video that will not show with 45.5.0, though. :-(

[dmik]

Playing h264 videos is already fixed in FF 45.9.0 (which is to be released soon). WebM videos already work as they did in ESR 38.

[SilvanScherrer]

it might be worth trying also standard setting of VAL like ArcaOS has it. Which is 1536

[michaelsnyder]

If I still experience crashes like the previous ones, I'll try that. Thanks.

[StevenLevine]

A couple of comments on memory usage. The only memory monitor that is even remotely useful in analyzing these kinds of issues is Theseus. See

http://home.earthlink.net/~steve53//os2diags/theseus-how-to.txt

for a getting started guide. The linear memory map display can be a bit cumbersome to use, but it will tell you two important things. It will tell you if a process is making good use of upper memory address space and it can tell you how close you are to running out of lower memory address space. Unless you run out of address space, the heap allocation will always succeed.

If an app like Firefox does not make good use of upper memory, it is doomed to trap sooner, rather than later. There will never be enough lower memory address space for an app like Firefox.

In a perfect world, these kinds of traps would not occur. The code would check for an allocation failure and fail the operation rather than trap. However, unless the trap has occurred on a tier 1 platform, the allocation failure detect code may not exist.

[michaelsnyder]

Thanks.

[SilvanScherrer]

how are the results so far?

[michaelsnyder]

On 06/21/17 at 02:43 AM, Silvan Scherrer notifications@github.com said:

how are the results so far?

Much better than previous versions, but it still crashes. I sent one .trp file. I have two more that look similar to my untutored eye. Steven and Dimitry seem to think that the problem is that my machine runs out of low memory. I am now loading xul.dll high and have refrained from starting one of my usual programs to see whether that helps.

--

---

"Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong remedies. - Groucho Marx Progressivism is Lysenkoism

Mike Snyder msnyder1@cfl.rr.com