[Xcb] Memory leak?

[Julien Danjou]

At 1239637641 time_t, Florian Faber wrote:
> I found one return with a missing free(buf), but I assume the main
> reason would be not freeing buf after it is inserted in the list.

Where? I did not see it.

> ==3055== 74,952 bytes in 2,082 blocks are definitely lost in loss
> record 
> 169 of 173
> ==3055==    at 0x4C24CCE: malloc (in 
> /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
> ==3055==    by 0x6E16C04: _xcb_in_read (xcb_in.c:152)
> ==3055==    by 0x6E15179: _xcb_conn_wait (xcb_conn.c:357)
> ==3055==    by 0x6E1670F: xcb_wait_for_reply (xcb_in.c:367)
> ==3055==    by 0x5CBF835: _XReply (xcb_io.c:366)
> ==3055==    by 0x5CA449B: XParseColor (ParseCol.c:128)
> ==3055==    by 0x581C60F: fl_parse_color(char const*, unsigned char&, 
> unsigned char&, unsigned char&) (in /usr/lib64/fltk-1.1/libfltk.so.1.1)
> ==3055==    by 0x5827B42: fl_draw_pixmap(char const* const*, int, int, 
> Fl_Color) (in /usr/lib64/fltk-1.1/libfltk.so.1.1)
> ==3055==    by 0x4186BF: HDSPMixerMeter::draw() (HDSPMixerMeter.cxx:45)
> 
> With the current 36 byte leak, I lose up to 207KB/s..

Is this the only bt you have?
There's a chance it's a bug in fltk not freeing its reply?
Because what's return by xcb_wait_for_reply must be freed by the caller,
so you can't blame XCB for mem leak AFAIK.

Cheers,
-- 
Julien Danjou
// ᐰ <julien at danjou.info>   http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
// Trust no one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20090413/59a3c06e/attachment.pgp