Re: glib memory allocation problems

[Tim Janik <timj gtk org>]

On Thu, 10 May 2007, Dimitrios Apostolou wrote:

> Hello glib developers,
>
> I have been hitting an sshfs crash very often and according to Miklos Szeredi
> (of FUSE and sshfs fame) it is very probable that glib is responsible, and in
> particular the g_slice allocation routines when multiple threads are
> involved. Unfortunately the crashes don't always take place at the same
> place.
>
> Anyway, trying to produce some useful debugging info for you, I compiled glib
> 2.13.1 with debugging symbols. Please find attached the backtrace of a crash.
> I have kept the core file in case you need me to run specific gdb commands.
>
> FYI the crash takes some time to reproduce, it happens after about 12-24 hours
> of continuous full load operation of sshfs. However I have been running
> exactly the same test case as the attached file, with the slight difference
> of G_SLICE=always-malloc for more than 48 hours and the crash hasn't occured
> yet. Nevertheless, I think that another problem has surfaced: running sshfs
> that way shows possible memory leaks in glib. The VSZ of the process has
> surpassed 350MB and keeps growing at a constant rate, which didn't happen
> before. Is it normal for glib to allocate that much more memory when using
> G_SLICE=always-malloc?
>
> I think the next step would be to run sshfs with G_SLICE=debug-blocks. Before
> doing that and because it takes some time to reproduce, is the backtrace
> attached useful to you?

not really. both, GSlice and GHashTable (which shows up in your backtrace)
are known to be pretty stable and their allocation behavior is supposedly
bug-free. as described in my blog:
  http://blogs.gnome.org/view/timj/2007/01/02/0
it's likely that some code portions erroneously use GSlice and thus screw
up the memory handling at some point. G_SLICE=debug-blocks is really the
recommended way to find those errors and much faster than trying
valgrind (and definitely more accurate about slices).

> Thanks in advance,
> Dimitris

---
ciaoTJ