Re: gtk+-1.2.10 has memory leak?
On Fri, 30 Jan 2004, qn wang wrote: > Daniel, John Cupitt and havardk ... > Thank you all for your answer. Now I know it's no need to free a static > string. > But how about this one showed blow? It's from gdk.c. > The argv_orig will not be freed if this function exit with false.(see > ////) > Will this lead to a memory leak? OK I was wrong the last time (I didn't spot the static declaration), so whatever I say sould be taken with a grain of salt here. It looks, however, as if this function indeed could allocate memory without freeing it, but I think it is only used in a context where the application quits anyway because no display could be opened. This is fine because in this case the memory is automatically freed by the operating system. It still is unclean programming in my book; I always try to free everything. The really problematic leaks are of course those that occur within functions that are called many times in a running application. I don't think there's a way around using a memory debugging tool (which of course would find this particular, harmless leak). --Daniel ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk+-1.2.10 has memory leak?
> 1) We must use this version of gtk and I can't decide this. I know this > is stupid but I have no choice. OK then. > 2) In fact I haven't met any memory leak and I'm a beginner at gtk. My > manager asked me to do this work. So if I can find any material to prove > that it's no need to fix gtk+-1.2.10, I'll be saved from that work. Can > you give me some thing to prove this? No, but gtk (any stable version) has a reputation of being leak-free, so I'm suspecting faulty programming. What you need to do first is to write a small program that demonstrates the existence of the leak. If there is a leak, you can go about fixing it. The most important question is how your manager arrived at the conclusion that gtk leaks memory. What are the symptoms? What tools are being used? BTW I wrote a small gtk-1.2 program a while ago and leak-tested it with ccmalloc. I found no leaks, but of course your application might work differently. --Daniel ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk+-1.2.10 has memory leak?
> I was assigned to do a work to fix the bugs of gtk+-1.2.10. They say it > has a problem of memory leak. If some functions(such as gtk_type_class_init) > is called by me, it will occupy memory and don't free them and the > memory can be used will become less and less. Will this really happen? > Must I do this fix work? Two things 1) I think gtk+-1.2.x is way outdated and not supported any more. If that's the case I wouldn't waste any time trying to fix it. 2) How was the alleged memory leak detected? --Daniel ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: API for iterating the g_hash_table
On 14 Jan 2004, Sven Neumann wrote:
> Hi,
>
> [EMAIL PROTECTED] writes:
>
> > It is rather trivial to construct a GList of hash table keys (or
> > values) using g_hash_table_foreach. Of course it's only useful on
> > a table whose contents change never or seldom because the list
> > has to be updated on each change. Anyway, here's what I use. I
> > was too lazy to make Append_key() the right type.
> >
> > void append_key(void *k, void *v, GList **keys)
> > {
> > }
> >
> > GList *get_hash_keys(GHashTable *hash)
> > {
> > GList *keys = NULL;
> >
> > g_hash_table_foreach(hash, append_key, &keys);
> > return keys;
> > }
>
> Let's hope your implementation of append_key() uses g_list_prepend()
> or this code will be horribly inefficient for large hash tables.
Indeed I use append_key (somehow the function body of append_key
went missing):
*keys = g_list_append(*keys, k);
Of course you're right, thanks for pointing it out.
--Daniel
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: API for iterating the g_hash_table
> I only see the the g_hash_table_foreach() here. But sometimes people may
> like to iterate through a hash table and stop the iteration when certain
> conditions are met.
It is rather trivial to construct a GList of hash table keys (or
values) using g_hash_table_foreach. Of course it's only useful on
a table whose contents change never or seldom because the list
has to be updated on each change. Anyway, here's what I use. I
was too lazy to make Append_key() the right type.
void append_key(void *k, void *v, GList **keys)
{
}
GList *get_hash_keys(GHashTable *hash)
{
GList *keys = NULL;
g_hash_table_foreach(hash, append_key, &keys);
return keys;
}
--Daniel
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (GObject) What are "properties"?
> Does your object "some_gtk_widget" have a property named "foo" that > takes a string value? If not, it is not surprising that the call > fails. It's a bit surprising that it crashes; I'd have expected a > warning. Ah. No, of course it doesn't have that property, which explains why my experiment didn't work (and I re-checked; indeed I did get a warning, and the crash was a follow-up error caused by my program). > Mathieu is doing a nice job on GObject documentaion. See > http://www.le-hacker.org/papers/gobject/index.html I know; I read it (and also now understood that a property first must be "installed" before it can be used to assign values to it). I guess I haven't quite wrapped my head around properties, but am I right in assuming that their main advantages (as opposed to, say, ordinary class members) are: 1) they are installable at runtime 2) they can emit signals when changed Am I also right in assuming that each and every GObject carries around with it two hash tables; one for properties and one for the get/set_data() functions? Thanks, --Daniel ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
(GObject) What are "properties"?
Hi all, what are the "properties" of GObjects, how are they used, and how are they different from the things that can be stored/retrieved via g_object_set/get_data() ? I've once tried, just for giggles, g_object_set(G_OBJECT(some_gtk_widget), "foo", "bar", NULL); and got a segfault. Little wonder, considering that the documentation in the API reference reads thus: void g_object_set(gpointer object, const gchar *first_property_name, ...); object : first_property_name : ... : Which brings me to the point, is anybody working on the documentation of GObject at all? Of course I know this is all open source stuff, written and maintained by volunteers, so I'm far from complaining about lack of documentation. Just curious. --Daniel ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
