Memory Hog

There be dragons at this goal:
https://www.beeminder.com/phi/spiht

First a screenshot of what I am looking at right now:

I restarted Safari to no avail.
I am now getting the beachball of death.
The dashboard itself is working fine and so are other goals. All that I have tried.
It’s just my spiht goal that leaves the page partially blank and gets my CPU fans spinning.
I opened it to check if the datapoint got logged after Beemios / BeeSwift crashed when I tapped Add Datapoint in the stopwatch.
What a coincidence :roll_eyes:

Jeez look at the memory footprint! Again, i just restarted Safari.


You really like to put these memory hogs in there, don’t you :wink: Something something Visual Road Editor…

It does work in Chrome if that’s any help.

4 Likes

I tried to investigate this, and it’s weird: I think you’re hitting a bug in the svg renderer??? I must surely be wrong here.

Try just loading this: https://bmndr.s3.amazonaws.com/uploads/31603da8-31e0-4348-9187-cfa4e8853a6a.svg

It completely freaking kills my firefox even if I close the tab! As you noted, it works fine in chrome.

3 Likes

A bug in the SVG renderer haha! :joy: This is great.
Following your link on mobile Safari I get this:

And after a while of retrying it eventually gives up

1 Like

It looks like the current version of the graph is loading fine. The svg file that @eugeniobruno linked to has been killed and replaced. Did you change any settings with the goal that affected the graph rendering (e.g. maybe t-min or something?) If there were something about the svg itself that’s causing the browser to fall on its face, that’s definitely something we want to flag and try to figure out!

2 Likes

Interesting, I hope somebody saved a copy of that svg file :grimacing:

If memory serves I have logged one single datapoint on it after I reported the bug – but in any case that was before I last tried to access the linked SVG file (and took the iOS screenshot). A good while before. I wanna say hours.
And I think before @eugeniobruno poked it.
I remember that when I last tapped „Add Datapoint“ in the stopwatch screen of Beemios that a spinner showed up and it took an unusually long time for the spinner to disappear. Not that I actively remember ever having seen a spinner there but that might just be my memory playing tricks on me.

In any case: I have definitely not changed any settings of the goal (or graph or anything really).

1 Like

This is the SVG file that crashed. Interestingly, while it crashed firefox on windows, it seems to render fine on firefox on linux.

https://pastebin.com/raw/WFdc8zWj

The SVG file seems (to my layman eyes) deeply changed. The crashing version had some huge numbers in a path, while the non-crashing version does not:

Crashing:

Non crashing:

2 Likes

In the non-crashing svg, numbers are generally floats, and seem to all be under 17 bits anyway.

In the crashing svg, numbers are all around 54 to 55 bits, but more interestingly, they are mostly integers:

Could this be a 32bit overflow of some kind?

2 Likes

I think I’ve mostly figure it out, and the problems are those big numbers, but it’s not an integer overflow. Turning them into floats doesn’t work, making them smaller does:

# if the token appears to be a big integer, make it smaller
def xform(tok):
    try:
        if int(tok) > 2 ** 50:
            return str(int(tok) / (2 ** 50))
    except:
        pass

    return tok

crashing = open("crash.svg").read()
crashing_toks = crashing.split(" ")

maybe_not_crashing_toks = [xform(tok) for tok in crashing_toks]
open("uncrashed.svg", "w").write(" ".join(maybe_not_crashing_toks))

To confirm, you could check (closing and reopening the browser between checks) these test files. I can reproduce on win10 with FF.

The original SVG kills it: https://github.com/Eugenio-Bruno/svg_crashing_ff/blob/master/original.svg
Just turning ints to floats still kills it: https://github.com/Eugenio-Bruno/svg_crashing_ff/blob/master/int_to_float.svg
Making the numbers smaller fixes it: https://github.com/Eugenio-Bruno/svg_crashing_ff/blob/master/smaller_nums.svg

3 Likes

/me adds a streak to the “bitten by stringly typed data” list

2 Likes

Thank you all for the debugging help. My current guess is that in certain cases, the polynomial fit that we do for generating the aura fails and generates very large y coordinates. I will try to identify specific goal and datapoint examples that lead to this to fix it in the jsbrain code. These very large numbers should never have been there in the first place. Nevertheless, I will also put in place filter that clip the numbers written in the svg as above.

6 Likes

Fixed!

2 Likes