1904174 - [macOS] 26GB of memory being used in the main process under gfx. GPU-process is not present.

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect, P1)

Description

[mojofawad]

Attachment: memory-report.json.gz

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:127.0) Gecko/20100101 Firefox/127.0

Steps to reproduce:

I was just using dbdiagram.io to create a small db model

Actual results:

my OS (mac) told me I waas out of application memory and firefox was 26.10GB of that.

I don't know how "application memory" works, but I've only got 8GB of RAM haha

Expected results:

not this? I wish I could be more helpful.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Mayank Bansal]

Few observations :

1. All the memory is under the main process
2. There is no gpu-process
3. All the memory inder main process in in gfx.

@mojofawad :

1. Can you type about:support in your browser, and paste its contents on this bug?
2. I played around on the website but didnt see any memory increase. If possible, can you also share the db model you were working on? I can try to export it on the website and see if that leads to any memory increase.
3. If you can consistently reproduce this bug, does it still reproduce if you set "gfx.canvas.accelerated = False" adn restart the browser?

Comment 3

[mojofawad]

(In reply to Mayank Bansal from comment #2)

Few observations :

1. All the memory is under the main process
2. There is no gpu-process
3. All the memory inder main process in in gfx.

@mojofawad :

1. Can you type about:support in your browser, and paste its contents on this bug?
2. I played around on the website but didnt see any memory increase. If possible, can you also share the db model you were working on? I can try to export it on the website and see if that leads to any memory increase.
3. If you can consistently reproduce this bug, does it still reproduce if you set "gfx.canvas.accelerated = False" adn restart the browser?

1. I’ll get you number 1 if I can.

2. It was 4 tables max with 2 columns per table. While I’m unable to reproduce the bug, I can explain what I was doing at the time:

I was trying to figure out how to add references (I didn’t read the docs at first.) I kept trying to write it similar to Mermaidjs and I kept getting an error. So I would try writing it different ways.

After posting this bug and closing out the browser, the memory usage went down to ~1.5GB and I was able to use dbdiagrams again.

3. I can’t consistently reproduce it, unfortunately.

Comment 4

[mojofawad]

Attachment: about:support contents - day after bug

@Mayank Bansal

I'm not sure what you mean about pasting contents on this bug. I can copy my `about:support` contents now, but not with the bug.

Comment 5

[mojofawad]

@Mayank Bansal

I'm not sure what you mean about pasting contents on this bug. I can copy my about:support contents now, but not with the bug.

Comment 6

[mojofawad]

Update: I noticed creating new tables would cause the memory to go up.

I was able to get it up to 8GB using the following dbml:

table tablename1 {
  column1 int
}

table tablename2 {
  column1 int
  column2 int
}

table tablename3 {
  column1 int
  column2 int
  column3 int
}

table tablename4 {
  column1 int
  column2 int
  column3 int
  column4 int
}

table tablename5 {
  column1 int
  column2 int
  column3 int
  column4 int
  column5 int
}

ref {
  "tablename1"."column1" > "tablename2"."column1"
}

ref {
  tablename2.column2 > tablename3.column2
}

ref {
  tablename3.column3 > tablename4.column3
}

Steps to reproduce:

• Don't copy/paste this. Start in the default view and type each table in one by one.
• Delete the dbml that was just written, and without refreshing, enter this in the dbml, one table at a time

table a {
  a int
  b datetime
}

table b {
  b datetime
  c somevalue
}

table c {
  c bool
  d char
}

ref {
  a.b > b.b
}

ref {
  b.c > c.d
}

Behavior I noticed:

• upon deleting the original dbml, the memory usage did not go down
• memory usage increases with each new table written. this behavior isn't replicated when copying 20+ tables all at once

Comment 7

[Mayank Bansal]

Thanks, I can reproduce now. I need to type-in only till table3, and then with each new variable added in table3, memory starts increasing rapidly.

Gpu-canvas: I get ~1.5GB of memory in gpu-process when i type out the the first three tables. https://share.firefox.dev/3XTtFjd
D2d-canvs: 9.5GB used at the system level (but only 300mb in any of the Firefox processes).

Can repro on a build from Jan2021, so not a new regression.
Maybe the site is increasing the height and width of the canvas each time you type a new table+column name which leads to OOM?

Comment 8

[Mayank Bansal]

Attachment: memory report for gpu-canvas

Comment 9

[Mayank Bansal]

With gpu-canvas:
Profile with memory tracking : https://share.firefox.dev/4bdrr0R
Profile with graphics preset logging: https://share.firefox.dev/4biKSW9

Comment 10

[Erich Gubler [:ErichDonGubler] (he/him)]

Lee, do you know about how this might be happening?

Comment 11

[Jeff Muizelaar [:jrmuizel]]

I can reproduce this as well.

Comment 12

[Jeff Muizelaar [:jrmuizel]]

I think it's ok to keep this as S2 until we learn what's going on.

Comment 13

[Lee Salzman [:lsalzman]]

(In reply to Erich Gubler [:ErichDonGubler] from comment #10)

Lee, do you know about how this might be happening?

Not sure offhand. Maybe related to bug 1904048.

Comment 14

[Erich Gubler [:ErichDonGubler] (he/him)]

If it is related to bug 1904048, then maybe OP (mojofawad) can test on Nightly, since it's resolved?

Comment 15

[Bob Hood [:bhood]]

Myank, can you see if you can reproduce this based on comment 7?

Comment 16

[Mayank Bansal]

(In reply to Bob Hood [:bhood] from comment #15)

Myank, can you see if you can reproduce this based on comment 7?

I can no longer reproduce this.