Hello In WApplication *wApplicationCreate(WWindow *wwin) in application.c the pointer to the wapp is saved using XSaveContext,
XSaveContext(dpy, main_window, wAppWinContext, (XPointer)wapp); So if you free that resource the data associated with the window will become a dangling pointer! Which will make valgrind throw up loads of errors! When the life cycle of a window ends the wApplication is free'd through: wApplicationDestroy(WApplication *wapp) in application.c Have a look in event.c in the function static void handleDestroyNotify(XEvent *event) for an example of how a window / application is free'd up. On Wed, Aug 19, 2009 at 1:16 AM, Carlos R. Mafra<[email protected]> wrote: > On Mon 17.Aug'09 at 14:27:13 -0700, John H. Robinson, IV wrote: >> > On Mon 17.Aug'09 at 15:10:00 +0200, Carlos R. Mafra wrote: >> > >> > LEAK SUMMARY: >> > ==26635== definitely lost: 3,618 bytes in 12 blocks. >> > ==26635== indirectly lost: 5,312 bytes in 166 blocks. >> > ==26635== possibly lost: 0 bytes in 0 blocks. >> > ==26635== still reachable: 1,571,268 bytes in 13,554 blocks. >> > ==26635== suppressed: 0 bytes in 0 blocks. >> > ==26635== Reachable blocks (those to which a pointer was found) are not >> > shown. >> > ==26635== To see them, rerun with: --leak-check=full --show-reachable=yes >> > >> > So yeah, it looks like there a few memory leaks in wmaker. >> >> I'm not surprised. It will take a while to hunt them all down and plug >> them up. > > So I took this report and started to study it, > > 837 bytes in 19 blocks are definitely lost in loss record 83 of 128 > ==5055== at 0x4C2362E: malloc (vg_replace_malloc.c:207) > ==5055== by 0x4576ED: wmalloc (memory.c:88) > ==5055== by 0x40C2A3: wApplicationCreate (application.c:285) > ==5055== by 0x44A031: wManageWindow (window.c:1379) > ==5055== by 0x420333: handleMapRequest (event.c:622) > ==5055== by 0x422524: DispatchEvent (event.c:230) > ==5055== by 0x46037F: WMHandleEvent (wevent.c:235) > ==5055== by 0x420174: EventLoop (event.c:396) > ==5055== by 0x42782E: main (main.c:815) > > and as valgrind says that it is "definitely lost" and the trace contains > wmaker-only > functions, I thought that was a good starting point to learn something. > > It turns out that in window.c:1379, which is inside the function > wManageWindow(), > we have > > app = wApplicationCreate(wwin); > > and no wfree(app) after that. > > And the valgrind trace contains "wApplicationCreate (application.c:285)", > and that line reads > > wapp = wmalloc(sizeof(WApplication)); > > and later the function returns this pointer "wapp" (or returns NULL if > something goes wrong). > > So for me it looks like we should have > > wfree(app); > > inside the function wManageWindow() in window.c after we are done with it. > This is the piece of code which I am talking about (src/window.c), > > app = wApplicationCreate(wwin); > if (app) { > app->last_workspace = workspace; > > /* > * Do application specific stuff, like setting application > * wide attributes. > */ > > if (wwin->flags.hidden) { > /* if the window was set to hidden because it was hidden > * in a previous incarnation and that state was restored */ > app->flags.hidden = 1; > } else if (app->flags.hidden) { > if (WFLAGP(app->main_window_desc, start_hidden)) { > wwin->flags.hidden = 1; > } else { > wUnhideApplication(app, False, False); > raise = True; > } > } > wfree(app); <---- I put this here! > } > > but strangely enough putting wfree(app) there made things much worse > and the valgrind report was huge and with lots of new errors, so > this is not the way to go. > > Does somebody have some idea of what is going on here? I missed > something, but I don't know what :-) > > > -- > To unsubscribe, send mail to [email protected]. > -- To unsubscribe, send mail to [email protected].
