Re: gEDA-user: gschem segmentation fault

[Steve Brown <sbrown@xxxxxxxx>]

Ales Hvezda wrote:
> Hi,
>
>   
> > Thank you Steve, that did the trick! I should have known that it was
> > an environment variable... Still, it's quite a stange thing to happen,
> > and if it's not gschem but glibc, shouldn't a lot more programs suffer
> > the same problem?
> >
> > Anyway gschem is a lot more usable for me now, maybe this is something
> > to add to the FAQ?
> >
> >     
>
> 	I've been reading this thread with quite some interest.  
> Some questions:
>
> * What version of guile is being used?
> * Was this version of guile installed by the distribution or a custom build?
> * Which operating system (brand/distribution)?
> * How was the software installed (distribution package/install CD)?
>
> I haven't seen a failure like this in quite a while.  Could you please post
> a schematic and the exact keystrokes necessary to reproduce this seg fault?
>
> Thanks,
> -Ales
>   
More, from:  
http://mail.gnome.org/archives/gtk-list/2002-October/msg00147.html

g_free() frees the memory allocated by g_malloc() function, like
free() frees the memory allocated by malloc() in stdlib.

g_object_unref() is completely different. Its the piece of glib object
system. Each object derived from GObject has a special field:
reference counter. g_object_unref() decrements counter, when counter
becomes 0 - object will be destroyed.

=========

After more googling, it appears that up until the current glib version these calls were basically equivalent, but aren't now.

This also seems to explain that G_SLICE=always-malloc makes the problem go away by making the calls equivalent again. 

Not sure I understand all this,

Steve

<http://mail.gnome.org/archives/gtk-list/2002-October/msg00147.html>