Re: Window destroy = program crash?
- From: "David J. Topper" <topper virginia edu>
- To: Owen Taylor <otaylor redhat com>
- Cc: gtk-list gnome org
- Subject: Re: Window destroy = program crash?
- Date: Thu, 05 Jul 2001 22:02:28 -0400
Owen Taylor wrote:
> When set, GNU libc writes some extra information around memory blocks and
> checks it on free() so that it can detect double frees and some other forms of
> memory corruption.
>
> Now, this might be coincidental memory corruption elsewhere in
> your app (in which case you might want to look into ElectricFence),
> but I guess there is a 70%-80% chance that somewhere in your
> app you wrote:
>
> gchar *text = gtk_entry_get_text (entry);
> [...]
> g_free (text);
I was freeing some float arrays, but I've taken out all my free() calls. I still
get the same problem. The MALLOC_CHECK_ does catch it right away. But still,
I'm at a loss.
I'm curious if something else might be happening, but I didn't think it was
wrong. Here's what I'm doing to "grab" values.
1. Set up a window with a bunch of text entry boxes.
2. Link each box to a cb_func which reads in the text string, converts it to a
float, then sets another float to the new value (grabbed from the text entry).
3. I then use those floats to create new objects based on what the user entered
in #1 and #2 above. IE., I pass an array of floats to another function, called
when the user clicks "ok"
4. Clicking "ok" also deletes the parent window of all the text entries (in #1
above).
But the only way the float is linked to the array is via the signal_connect call
and respective callback function. This doesn't seem like it should crash my app,
does it?
It doesn't normally of course. Only every 5 or 10 instances of the above. But
something sure ain't right someplace.
DT
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]