After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 586626 - Clipboard::wait_for_targets() returns list pointing to free'd memory
Clipboard::wait_for_targets() returns list pointing to free'd memory
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: general
2.16.x
Other All
: Normal critical
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2009-06-22 12:02 UTC by Peter Clifton
Modified: 2009-09-16 15:23 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
Proposed patch fixing the bug (1.15 KB, patch)
2009-06-22 12:04 UTC, Peter Clifton
none Details | Review

Description Peter Clifton 2009-06-22 12:02:36 UTC
Steps to reproduce:
Noted in inkscape, under valgrind.


Stack trace:


Other information:
> It seems that the implicit creation of a Glib::StringArrayHandle upon
> return is causing the problem. The constructor which takes a container
> (our std::list of ustring targets), does not associate ownership of the
> array elements with the newly created Glib::StringArrayHandle, it just
> stores pointers.
> 
> When our "listTargets" std::list goes out of scope, its elemensts are
> free'd, thus causing the corruption / problems when our caller tries to
> use its result.
Comment 1 Peter Clifton 2009-06-22 12:04:17 UTC
Created attachment 137165 [details] [review]
Proposed patch fixing the bug
Comment 2 Murray Cumming 2009-06-22 13:35:15 UTC
Yes, the patch is probably appropriate. CCing Daniel Elstner though, because he probably has an opinion about this.
Comment 3 mail 2009-09-14 11:00:09 UTC
Confirmed! I ran into the same bug, independently from Peter, but also in Inkscape. I haven't tested his patch, but I hacked an ugly workaround into Inkscape to circumvent this memory corruption. Obviously, I would love to see this fixed in gtkmm in the end.

TIA,

Diederik
Comment 4 mail 2009-09-15 07:49:27 UTC
Forgot to mention that more details can be found here:

https://bugs.launchpad.net/inkscape/+bug/296778/comments/13

and here:

http://mail.gnome.org/archives/gtk-devel-list/2009-June/msg00062.html
Comment 5 Daniel Elstner 2009-09-15 15:04:03 UTC
Sorry for the delay, I completely missed this bug report.

Yes, the code is horribly wrong. The patch is mostly correct. Of course, the real fix would be to use ArrayHandle<> with custom Traits to define the GdkAtom -> gchar* conversion, but that's not possible at this point as it would break ABI.

I applied a modified version of the patch with a memory leak plugged and some stylistic changes. There was another similar misuse of the array handle in that source file, which I fixed, too.

commit 571dd7a71fadb3d61d698c84bc8d5f0a980c1af7
Author: Daniel Elstner <danielk@openismus.com>
Date:   Tue Sep 15 16:49:51 2009 +0200

    Correct misuse of container handle (bgo #586626)
    
    * gtk/src/clipboard.{ccg,hg} (Clipboard::wait_for_targets): Create
    an intermediate array of allocated C strings and transfer ownership
    on return, instead of trying to returned a handle to a container
    with local scope.  (Based on patch by Peter Clifton.)
    (SignalProxy_TargetsReceived_gtk_callback): Correct another misuse
    of the container handles similar to the above, except for the crash.
    (SignalProxy_RichTextReceived_gtk_callback): Simplify the code and
    plug a memory leak in the event of an exception.
Comment 6 Murray Cumming 2009-09-15 16:04:11 UTC
Thanks, Daniel. Could you backport this to gtkmm 2.16 too, please, if that makes sense.
Comment 7 Daniel Elstner 2009-09-16 15:22:18 UTC
I cherry-picked the commit onto gtkmm-2-16, it applied flawlessly.