[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#63131: Dino explodes memory, CPU usage
From: |
J. Sims |
Subject: |
bug#63131: Dino explodes memory, CPU usage |
Date: |
Thu, 27 Apr 2023 21:19:58 +0000 |
Hey,
------- Original Message -------
On Thursday, April 27th, 2023 at 16:26, Josselin Poiret <dev@jpoiret.xyz> wrote:
> Hi,
>
> I cannot reproduce on my end with a bare `guix shell dino -- dino`.
> What windowing system are you using? Does dino have logs? Have you
> tried launching it in a terminal to see if it outputs anything?
If dino has logs, I do not know where to find them; when launching from the
terminal, a newline is emitted and absolutely nothing else before entering the
described state. I am using GNOME.
Interestingly, your comment made me curious, so I ran a `guix shell --pure dino
-- dino` to see what would happen. It launched fine, so I ran an update of the
home profile (where I have it installed) and tried launching dino again - only
to reproduce the same problem. I tried your command of `guix shell dino --
dino` - and got the same issue again. However, `guix shell --pure dino -- dino`
still works fine. This leads me to believe the issues is another package in my
home profile... but which?
I tested all of the packages in my home profile with dino in a pure shell, and
it launched fine.
Okay, not packages. Environment variables? I changed some of those recently;
let's try reverting them.
Nope, works fine.
The logical next consideration is services, but I'm not sure how to test those
without... removing them, reconfiguring home, logging out, logging in... each
and every time. It would be nice if you could pass eg `--preserve='^DISPLAY$'`
to `guix home container`. Ah well. I'll do the hard thing anyway.
But before I go off to do that, I wanted to send this message with previous
debug steps. Especially this interesting tidbit:
Firstly, I misspoke; Dino doesn't consume an entire thread and all the system's
memory. It turns out gst-plugin-scanner consumes all the system's memory; the
CPU seems to remain unabused.
With this information, I ran `dino --gst-debug-level=6` and found this
interesting, repeating pattern:
```
0:00:27.310610920 31838 0x11d8520 LOG GST_PLUGIN_LOADING
gstpluginloader.c:1150:exchange_packets: Poll res = 0. 0 bytes pending for write
0:00:27.310655655 31838 0x11d8520 DEBUG GST_POLL
gstpoll.c:1241:gst_poll_fd_has_error: 0x13e81e0: fd (fd:25, idx:2) 0
0:00:27.310661435 31838 0x11d8520 DEBUG GST_POLL
gstpoll.c:1266:gst_poll_fd_can_read_unlocked: 0x13e81e0: fd (fd:25, idx:2) 0
0:00:27.310667858 31838 0x11d8520 DEBUG GST_POLL
gstpoll.c:1195:gst_poll_fd_has_closed: 0x13e81e0: fd (fd:25, idx:2) 0
0:00:27.310675101 31838 0x11d8520 DEBUG GST_POLL
gstpoll.c:1414:gst_poll_wait: 0x13e81e0: timeout :0:00:01.000000000
```
This appears to be the action upon which it locks up.
As I said, I'll go test if one of my home services is causing this issue;
perhaps this information will be useful in the meantime.
Thanks,
Juli