| Summary: | memory leak in error case | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Matthias Clasen <mclasen> | ||||||
| Component: | Lib/Xlib | Assignee: | Jamey Sharp <jamey> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | medium | CC: | postinfern | ||||||
| Version: | unspecified | ||||||||
| Hardware: | Other | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
Created attachment 18950 [details] [review] patch Turns out to be a pretty ordinary memory leak in _xReply. process_responses returns the error, and _xReply copies it over to rep and forgets to free it afterwards. Actually an xlib bug. Patch looks good to me. Applied, thanks! |
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.
Created attachment 18933 [details] minimal testcase I've tried to track down a memory leak that I see in libxklavier-using applications: ==3331== 36 bytes in 1 blocks are definitely lost in loss record 5,707 of 8,140 ==3331== at 0x4006AEE: malloc (vg_replace_malloc.c:207) ==3331== by 0x74C00F: (within /usr/lib/libxcb.so.1.0.0) ==3331== by 0x74A2F9: (within /usr/lib/libxcb.so.1.0.0) ==3331== by 0x74BC81: xcb_wait_for_reply (in /usr/lib/libxcb.so.1.0.0) ==3331== by 0xBCFFF0: _XReply (xcb_io.c:366) ==3331== by 0xBACC52: XGetWindowProperty (GetProp.c:64) ==3331== by 0x5DD18D: xkl_engine_if_window_has_wm_state (in /usr/lib/libxklavier.so.12.1.0) ==3331== by 0x5D5C46: xkl_engine_process_create_window_evt (in /usr/lib/libxklavier.so.12.1.0) ==3331== by 0x5D678B: xkl_engine_filter_events (in /usr/lib/libxklavier.so.12.1.0) ==3331== by 0x50EB174: gsd_keyboard_xkb_evt_filter (gsd-keyboard-xkb.c:320) It turns out that the leak can be reproduced in a minimal example using just libX11, see the attached testcase. What it does is call XGetWindowProperty with a nonexisting window, causing a BadWindow error, that is ignored by the custom error handler.