Bug 17712

Summary:

permanently growing memory leak

Product:

xorg

Reporter:

Oleksiy <postinfern>

Component:

Lib/Xlib

Assignee:

Xorg Project Team <xorg-team>

Status:

RESOLVED DUPLICATE

QA Contact:

Xorg Project Team <xorg-team>

Severity:

critical

Priority:

high

CC:

postinfern

Version:

7.3 (2007.09)

Keywords:

have-backtrace, patch

Hardware:

All

OS:

All

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
patch and test application	none
patch extracted from attachment#19092	none

Description Oleksiy 2008-09-22 03:11:43 UTC

Created attachment 19092 [details]
patch and test application

Simple application using Motif 2.3 run under valgrind:

==13778== 1,872 bytes in 52 blocks are definitely lost in loss record 109 of 129
==13778==    at 0x40233F0: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==13778==    by 0x46C3842: (within /usr/lib/libxcb.so.1.0.0)
==13778==    by 0x46C2616: (within /usr/lib/libxcb.so.1.0.0)
==13778==    by 0x46C40E8: xcb_wait_for_reply (in /usr/lib/libxcb.so.1.0.0)
==13778==    by 0x434146C: _XReply (xcb_io.c:364)
==13778==    by 0x4320235: XGetWindowProperty (GetProp.c:64)
==13778==    by 0x417217F: read_settings (xsettings.c:444)
==13778==    by 0x4172642: xsettings_client_new (xsettings.c:481)
==13778==    by 0x41728B9: XmeGetSetting (xsettings.c:550)
==13778==    by 0x4151BE9: BlinkRate_xsetting (TextF.c:1759)
==13778==    by 0x41589EE: _XmTextFieldDrawInsertionPoint (TextF.c:1784)
==13778==    by 0x4159781: RedisplayText (TextF.c:2339)
==13778== 
==13778== LEAK SUMMARY:
==13778==    definitely lost: 1,872 bytes in 52 blocks.
==13778==      possibly lost: 0 bytes in 0 blocks.
==13778==    still reachable: 432,145 bytes in 2,827 blocks.
==13778==         suppressed: 0 bytes in 0 blocks.
==13778== Reachable blocks (those to which a pointer was found) are not shown.

The real problem is in XCB part of Xlib.
Leak is produced when application calls XGetWindowProperty using atom XSETTINGS. XCB return  error (xcb_generic_error_t ?) that is not freed & and is rewrited on next call. XSETTINGS mechanism in Motif is such that xsettings info is always requested from X while app is running. This makes leak permanently growing.
To reproduce bug Xlib must be configured with option --with-xcb. Use Motif 2.3.
Application must use some class of TextField widget.

see attachment for the patch and test application.

Links: http://bugs.motifzone.net/show_bug.cgi?id=1450

Comment 1 Oleksiy 2008-09-22 03:41:30 UTC

more detailed backtrace:

==3079== 1,224 bytes in 34 blocks are definitely lost in loss record 96 of 123
==3079==    at 0x40227C9: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==3079==    by 0x4581B09: read_packet (xcb_in.c:144)
==3079==    by 0x4582758: _xcb_in_read (xcb_in.c:500)
==3079==    by 0x4580C6B: _xcb_conn_wait (xcb_conn.c:325)
==3079==    by 0x458213C: xcb_wait_for_reply (xcb_in.c:344)
==3079==    by 0x4326738: _XReply (xcb_io.c:367)
==3079==    by 0x42FBBB1: XGetWindowProperty (GetProp.c:64)
==3079==    by 0x4168E2B: read_settings (xsettings.c:444)
==3079==    by 0x41692ED: xsettings_client_new (xsettings.c:481)
==3079==    by 0x416958F: XmeGetSetting (xsettings.c:551)
==3079==    by 0x4149AF7: BlinkRate_xsetting (TextF.c:1759)
==3079==    by 0x41501CD: _XmTextFieldDrawInsertionPoint (TextF.c:1784)
==3079== 
==3079== LEAK SUMMARY:
==3079==    definitely lost: 1,224 bytes in 34 blocks.
==3079==      possibly lost: 0 bytes in 0 blocks.
==3079==    still reachable: 218,033 bytes in 2,699 blocks.
==3079==         suppressed: 0 bytes in 0 blocks.
==3079== Reachable blocks (those to which a pointer was found) are not shown.

Comment 2 Julien Cristau 2008-09-22 04:19:36 UTC

Created attachment 19096 [details] [review]
patch extracted from attachment#19092 [details]

Comment 3 Julien Cristau 2008-09-22 04:21:37 UTC

already fixed a few days ago.

*** This bug has been marked as a duplicate of bug 17616 ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.