Section 4/5 - shows the bugs on 2-3 pages Challenges / Performance results

The FMS contains the real code, although it's unfinished and needs collaborators.

"Thanks for filing the issue!

@Reporter: Could you please give us a detail about the exact steps which reproduces the problem, it is clear from your comment#0 that you are facing an issue while running a process. It would be highly helpful if provided with a sample test file(if there are any), along with the clear repro steps from TE end which helps us to triage the issue in a better way."

If you have just a little time, look at the docs section 4 / 5, which is 2-3 pages, and you can understand my exact problem, and what i would have liked to solve. You haven't read my bug report thoroughly. The stuff are very well documented.

Everything has been shared under GPLv3, you can have a very good testing tool, it might need some digging, but it's a very useful tool to test shit out of the chrome.

You can download the code from https://github.com/fssrepository/fms.

It's a simple ionic/angular app, you can run with "ionic serve", there is two menus on it, click on the map one and you can read logs / debug in dev tool.

I admit it's a bug report, but take your time on that 2-3 pages and look at the code. The task, what i would have liked to achieve is like creating decoder in javascript.

Thank you for providing more feedback. Adding requester "vamshi.kommuri@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

You need a open street map pbf file from http://download.geofabrik.de/,
as my stuff is a file converter.

I'm sorry but in general making browsers hardened to fail out-of-memory conditions in a graceful way is extremely difficult (eg. all of chromium would have to be hardened to ensure there is no security hole for each and every memory allocation which could fail).  I did a couple tests and found that for truly huge sizes we will fail array creation with an exception.  But for cases like new Array(100*1024*1024) we don't know if we'll have the memory until things start being inserted into the array.

If you have a minimal test case that shows Firefox behaving better than Chrome in some scenario, we can look into what the difference is.  But in general the exact OOM behavior is going to be someone non-deterministic (depends which allocation really pushes things over the limit) so it's not surprising if some browsers "get a little further" than others, etc.

Thanks for your answer.

Do we need graceful way here, or you can throw the exception to a screen in
a more readable way?

Other thing is (stupid question) if the OOM is undeterministic, why i was
experiencing the same failure at the same running time.

I might have a clue, that Firefox limit might be higher than Chrome.

Chrome limit is probably 256MB,but because my converter supposed to eat up
a 40GB file, it's quite quickly hits the 512MB limit.

The only critisim here that i need to create a complete javascript
transaction and memory allocation manager in javascript, what my document
suggest.

My other problem, that my stuff kept logging into the console, but when
this exception happenning i practically loose all my logs from the console.
It would be better if the inspector just stays as it is not clearing the
last result from my screen, just freeze it for further investigation.

not inspector, dev-tool - sorry