You are not logged in.

#1 2023-09-28 14:59:47

seriosk
Member
Registered: 2023-09-24
Posts: 4

Major Memory Leak - Where can I file a bug report?

I'll try and be as clear as possible so people don't jump to comment without reading. If you do comment, please don't assume and read what I'm explaining here...

Latest ARCH has a major memory leak, proven with Jet Brains products, and possibly more undiscovered.
It will ramp memory up gradually, and freeze up at 100% (within 10 minutes).

Why am I sure it isn't Jet Brains?
A 6 day discussion with Jet Brains support over at You Track, providing them extensive memory snapshots and diagnostic information, plus trying a ton of fixes rendered it a native memory leak, their products also work flawlessly on any other distribution of Linux.

Steps to reproduce:
- Latest arch, run this and sort your .xinitrc
- Install and launch any Jet Brains IDE

What have I tried to resolve this?
- Different IDE versions (2 years old)
- Different kernels
- Clean install of ARCH
- Replaced my memory

Info for diagnostics
free output periodically collected: https://i.imgur.com/3n8u6Gk.png
htop 5 minutes after app launch: https://i.imgur.com/7WpUEkr.png
meminfo at 75% memory: https://pastebin.com/raw/EPJVpMMG

Last edited by seriosk (2023-09-28 15:01:03)

Offline

#2 2023-09-28 15:12:17

seth
Member
Registered: 2012-09-03
Posts: 51,325

Re: Major Memory Leak - Where can I file a bug report?

I'll try and be as clear as possible so people don't jump to comment without reading. If you do comment, please don't assume and read what I'm explaining here...

Great way to start your first post. And the point where I stopped reading caring.

I'll now lash out a bit, please don't assume and read where your post falls short of being useful.

Different IDE versions (2 years old)
Different kernels

Oh, so "different" ones. How interesting. And very informative.
But different ones. Sure it wasn't others?

A 6 day discussion with Jet Brains support over at You Track, providing them extensive memory snapshots and diagnostic information

It's really great to hear that your provided others with actual information.

plus trying a ton of fixes

Metric or Imperial?

their products also work flawlessly on any other distribution of Linux

So now it /is/ others, not different? Which is it?
Also are you sure about the "any"? I'm pretty sure I can find a 10 year old debian stable where recent-ish software fails to run. But you've actually checked that out?

run this and sort your .xinitrc

No, and also how does one, specifically *you*sort their xinitrc?

meminfo at 75% memory

This here is the only piece in your "I try to sound very professional but actually have no fucking idea what I'm talking" post that is not completely useless.
I'll try a magic trick: you've an AMD GPU?

If not, post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

so that there's some actual data to work on.

Offline

#3 2023-09-28 15:31:23

seriosk
Member
Registered: 2023-09-24
Posts: 4

Re: Major Memory Leak - Where can I file a bug report?

I'm saying it from experience, read and understand instead of being keyboard warriors like 90% of the folks at /r/archlinux (where this post was copied from).

On to business... yes but its integrated. Ryzen 9 7950x CPU.

Have this anyway: http://0x0.st/HVv4.txt

Also for the .xinitrc I'm literally just copying the default and changing the ending to just exec i3

Last edited by seriosk (2023-09-28 15:45:56)

Offline

#4 2023-09-28 15:48:19

seth
Member
Registered: 2012-09-03
Posts: 51,325

Re: Major Memory Leak - Where can I file a bug report?

instead of being keyboard warriors

So you figured that using autistim as a slur made you sound like the little dipshit you are?

yes but its integrated

And you also figured that… better late than never, I guess.

It's completely unrelated but you've NM and networkd enabled, pick one, disable the other.
Then see https://bbs.archlinux.org/viewtopic.php … 1#p2123011 and whether that returns you memory.
If so and if you can force the condition w/ jetbrains that should help a lot to isolate the problem (leaving aside amdgpu)

Don't expect me to answer to any of your further posts.

Offline

#5 2023-09-28 16:05:47

seriosk
Member
Registered: 2023-09-24
Posts: 4

Re: Major Memory Leak - Where can I file a bug report?

Thanks Seth for your help so far.

I tried your link and memory is returned afterwards, although I'm unsure how this gets me any closer to a solution.

Offline

#6 2023-09-28 16:41:57

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 19,797

Re: Major Memory Leak - Where can I file a bug report?

seriosk:  I am going to suggest you tone down the rhetoric and concentrate on providing feedback based upon facts rather than impressions.   As Seth points out, actual kernel revisions, and specific Linux distributions goes a long way toward credibility.
These forums have the luxury of being top notch in terms of technical content; we want to keep it that way.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way

Offline

#7 2023-09-28 17:41:03

seriosk
Member
Registered: 2023-09-24
Posts: 4

Re: Major Memory Leak - Where can I file a bug report?

Apologies, I'll continue.

I'm using kernel 6.5.5.
I've also tried the LTS and about 5 versios prior to 6.5.5.
I've tried but not limited to: Ubuntu and Fedora there are no memory issues on these

Could someone suggest how I debug further in response to Seth's comment here?

Last edited by seriosk (2023-09-28 17:41:46)

Offline

#8 2023-09-29 14:15:22

seth
Member
Registered: 2012-09-03
Posts: 51,325

Re: Major Memory Leak - Where can I file a bug report?

I acknowledge that you realized that the kind of insult you attempted was a bad idea.
You will now lose that instinct and refrain from such - not because of transactional reasons, because it might preclude you from getting something you need, nor because it's not politically correct or shit like that.
But because the arrogant vanity to gloat about something you didn't earn, at all, to the point where you perceive people who were maybe less lucky than you as so inferior to you, that you can weaponize them as insult is unbecoming of an intelligent being and neglecting your own nature. Fate can knock you over anytime without any reason whatsoever.

There're actually users with the condition you thought an insult on this forum.
You're not getting a third chance about this.


Next we will continue this at https://bbs.archlinux.org/viewtopic.php?id=285160
First, to concentrate the efforts and second so that a mod can kick this not-so-great entrance of yours into the dustbin.


As to how to proceed on topic:
- You can use jetbrains to force/accelerate the leak at will? And quickly?
- Since it's not in the repos and there're several AUR packages and o/c flatpaks: what is the specific version you're using?
- Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General - if you're currently using xf86-video-amdgpu, drop that and see whether the modesetting driver causes the same
- Idk whether it still applies (I know virtually nothing about jetbrains) but do you use https://wiki.archlinux.org/title/Java#B … erformance ?
- Rolling with the theory that jetbrains uses OpenGL to some extent, can you cause the leak when exporting "LIBGL_ALWAYS_SOFTWARE=1 LIBGL_DRI3_DISABLE=1 LIBGL_DRI2_DISABLE=1" to it?
- Can you cause the leak when exporting the above globally, so that it affects the X11 server? (You can inspect the environment of any process | tr '\0' '\n' < /proc/$(pidof Xorg)/environ |)

Something that looks shady and that you'll please copy over to that thread when continuing there is

Sep 28 14:38:09 monk kernel: amdgpu 0000:12:00.0: amdgpu: VRAM: 512M 0x000000F400000000 - 0x000000F41FFFFFFF (512M used)
Sep 28 14:38:09 monk kernel: amdgpu 0000:12:00.0: amdgpu: GART: 1024M 0x0000000000000000 - 0x000000003FFFFFFF
Sep 28 14:38:09 monk kernel: amdgpu 0000:12:00.0: amdgpu: AGP: 267419648M 0x000000F800000000 - 0x0000FFFFFFFFFFFF
Sep 28 14:38:09 monk kernel: [drm] amdgpu: 512M of VRAM memory ready
Sep 28 14:38:09 monk kernel: [drm] amdgpu: 31715M of GTT memory ready.

We're being very generous to ourselves w/ the GTT and the AGP value is ridiculous.

You can try to play with

modinfo amdgpu | grep -E 'vram|gtt|gart'

and if you've journals for kernels/distros that do not exhibit the problem (on the same hardware) check those to see whether those values are more sane there (or just a general bug in representing the state - I'm not sure in how far AGP is still any meaningful)


Edit: I saw your posts on reddit. I doubt that this is picom. Picom along a client that flickers windows might be prone to leaking textures, but that should abolutely not lead to the perceived consequences. You're quite possibly simply be slowing down the general problem by omitting the compositor.

Last edited by seth (2023-09-29 16:17:43)

Offline

Board footer

Powered by FluxBB