[Compcomm] [beryl-dev] [Fwd: beryl and memory leaks]

[Kristian Lyngstøl]

On 4/24/07, Nigel Cunningham <nigelc at beryl-project.org> wrote:
> Hi guys.
>
> Here's a patch I just received.

> -------- Forwarded Message --------
> From: Jens Gustedt <Jens.Gustedt at loria.fr>
> Reply-To: Jens.Gustedt at loria.fr
> To: Nigel Cunningham <nigel at suspend2.net>
> Subject: beryl and memory leaks
> Date: Tue, 24 Apr 2007 13:27:05 +0200
>
> I am using beryl with an NVIDIA card, so -copy is imperative, and I
> still observe some (rare) segfault and I also have to dump beryl
> before suspending. All that is sufficiently stable in my everyday
> experience, but I noted that over the time the machine has more memory
> problems than usual. Over time here means sometimes weeks and a lot of
> suspend cycles.
>
> But coincidence I recently did `ipcs' and saw that part of the problem
> might come from the ipc segments that are attached by beryl. In
> particular display.c allocates such a segment (seemingly in the size
> of the video card memory) but never detaches from it, even when it
> crashes, or when beryl is restarted when I change some settings. So I
> had a lot such segments with zero users hanging around.
>
> Looking into it, I found the handling of these segments by beryl
> quite, hm say amateurish: the access rights that are used are scaring
> (anybody could read my video memory), no clean up is done
> when a display is closed (so they persist without having a user) and
> the signal handlers don't clean it up either.

Nice catch, unfortunantly it's a bit futile at the moment, as this is
part of the copy rendering that compiz doesn't have, and that will
have to be rewritten as a plugin during/after the merge between Compiz
and Beryl...

This brings up an interesting question, however. I feel this patch is
fairly clean, and I would suggest we include it in Beryl 0.2, as a
process of maintaining it. It doesn't make any sense to use it on the
0.3.x/trunk version, obviously, since it's discontinued.

The patch fixes a rather ugly problem, is small and imo; well written.

We need to form a plan on what to do with Beryl 0.2, I belive I'm not
the only one in favor of maintaining it for another 6 months... I
think it makes sense to officially support it under the new project
(with important bug fixes like this, not further development), even if
the actual task would fall upon the original Beryl team.

Quinn? Anyone?

-- 
Regards,
Kristian