Re: glib memory allocation problems

[Miklos Szeredi <miklos szeredi hu>]

> > On Fri, 11 May 2007 13:55:25 +0200 (CEST)
> > Tim Janik <timj gtk org> wrote:
> >> 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).
> >
> > Hello,
> >
> > I reproduced the crash using G_SLICE=debug-blocks, this time using
> > a different usage scenario (the one described at
> > http://sourceforge.net/mailarchive/message.php?msg_name=E1Hjvl8-0006OR-00%40dorka.pomaz.szeredi.hu
> > ). Unfortunately the program didn't output any debugging text like
> > the one you describe in your blog. So I got another backtrace and
> > kept that coredump too so that I can run any command you tell me.
> >
> > So does the attached backtrace means anything to you?
> 
> seems you managed to crash around the slice debugger doing realloc().
> more interesting than the backtrace should actually be the
> program output.
> if you saw something like:
>    GSlice: MemChecker: attempt to release block with invalid size...
> then you actually have something to fix.
> if not, i suspect you have a bad memory corruption somewhere, e.g.
> where you're writing into already released memory regoins.
> that can cause crashes pretty much everywhere.

OK, found the problem: g_thread_init() wasn't called by sshfs, and
hence the thread private data used by gslice wasn't actually thread
private.

Now I see that the mandatory use of g_thread_init() is documented, but
it's very non-obvious without reading the docs.  And there are no
apparent problems if it's not called.  Sshfs got away with it for a
long time even though people do stress it pretty heavily.

So the question is, should glib not make some sanity checking for code
that is not actually thread related (like gslice).

Dimitrios, there's a patch attached that should fix the crashes.

Thanks,
Miklos

Index: configure.ac
===================================================================
RCS file: /cvsroot/fuse/sshfs/configure.ac,v
retrieving revision 1.17
diff -u -r1.17 configure.ac
--- configure.ac	19 Feb 2007 16:04:03 -0000	1.17
+++ configure.ac	15 May 2007 14:11:10 -0000
@@ -20,7 +20,7 @@
 AM_CONDITIONAL(SSH_NODELAY_SO, test "$enable_sshnodelay" != "no")
 
 export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH
-PKG_CHECK_MODULES(SSHFS, [fuse >= 2.2 glib-2.0])
+PKG_CHECK_MODULES(SSHFS, [fuse >= 2.2 glib-2.0 gthread-2.0])
 have_fuse_opt_parse=no
 AC_CHECK_FUNC([fuse_opt_parse], [have_fuse_opt_parse=yes])
 if test "$have_fuse_opt_parse" = no; then
Index: sshfs.c
===================================================================
RCS file: /cvsroot/fuse/sshfs/sshfs.c,v
retrieving revision 1.83
diff -u -r1.83 sshfs.c
--- sshfs.c	18 Apr 2007 09:44:08 -0000	1.83
+++ sshfs.c	15 May 2007 14:11:12 -0000
@@ -2605,6 +2608,8 @@
     char *base_path;
     const char *sftp_server;
 
+    g_thread_init(NULL);
+
     sshfs.blksize = 4096;
     sshfs.max_read = 65536;
     sshfs.nodelay_workaround = 1;