Environment: xorg-server - GIT Commit - 25344ba7f7845654364d62bf15322b3b79465bd9 2 Computers First computer runs X Backend and Xdmx Second computer runs kpersonalizer with it's DISPLAY variable set to the first machine's :1. On the first machine: Backend X is started with: X :0 -ac Xdmx is started with: Xdmx :1 -ac +xinerama -display :0 -input :0 On the second machine: export DISPLAY=firstmachine:1 kpersonalizer At this point kpersonalizer will display in Xdmx and function normally. Click next through all the screens until the last screen with the Finish button. Click the Finish button, the window will disappear and Xdmx will segfault. Program received signal SIGSEGV, Segmentation fault. 0x08192a4d in privateExists (privates=0x6503c4cc, key=0x8229440) at privates.c:79 79 return *key && *privates && (gdb) bt #0 0x08192a4d in privateExists (privates=0x6503c4cc, key=0x8229440) at privates.c:79 #1 0x081929e4 in dixLookupPrivate (privates=0x6503c4cc, key=0x8229440) at privates.c:162 #2 0x080c922c in FreePicture (value=0x8817d10, pid=2097797) at picture.c:1547 #3 0x08198587 in FreeClientResources (client=0x880a708) at resource.c:812 #4 0x08173a15 in CloseDownClient (client=0x880a708) at dispatch.c:3637 #5 0x0816b56c in Dispatch () at dispatch.c:430 #6 0x0815e1c1 in main (argc=8, argv=0xbfa03954, envp=0xbfa03978) at main.c:285
A simpler test is to start kpersonalizer as prescribed, but then CTRL-C the application just after it displays - no specific timing required. No need to interact with the displayed application either.
I've narrowed this down further. Once kpersonalizer is fully running and waiting for user input, the following data structure is populated with this data: ((PicturePtr)clientTable[1].resources[181]->value)->pDrawable->pScreen: 139601136 After hitting CTRL-C, Xdmx begins to cleanup the memory used to display that app. At the point of interest, it gets down into AllocateGlyphHash(): #0 AllocateGlyphHash (hash=0xbf930e6c, hashSet=0x821da98) at glyph.c:462 #1 0x080c25dc in ResizeGlyphHash (hash=0x822b418, change=0, global=1) at glyph.c:495 #2 0x080c2a04 in FreeGlyphSet (value=0x87f68a0, gid=2097172) at glyph.c:589 #3 0x08199458 in FreeClientResources (client=0x87e6708) at resource.c:874 #4 0x081743bc in CloseDownClient (client=0x87e6708) at dispatch.c:3648 #5 0x0816be5c in Dispatch () at dispatch.c:430 #6 0x0815eab3 in main (argc=8, argv=0xbf931094, envp=0xbf9310b8) at main.c:288 Within that function is the call to xcalloc: hash->table = xcalloc (hashSet->size, sizeof (GlyphRefRec)); Immediately before this call, the data is as expected: ((PicturePtr)clientTable[1].resources[181]->value)->pDrawable->pScreen: 139601136 Immediately after this call, the data is nulled out: ((PicturePtr)clientTable[1].resources[181]->value)->pDrawable->pScreen: 0
Even more interesting: Just before that call to xcalloc, hash->table was pointing to the memory location 0x80c205f. Just after that call to xcalloc, hash->table is now pointing to the memory location 0x8f9c1f0. What makes this interesting is this structure: ((PicturePtr)clientTable[1].resources[181]->value)->pDrawable->pScreen: The location for pScreen (&...->pScreen) that holds the pointer to the pScreen data is 0x8f9c658. Now here's the stinker: That call to xcalloc requested 1208 bytes of memory. malloc returned 1208 bytes of memory starting at 0x8f9c1f0. Doing the math 0x8f9c1f0 + 1208 = 0x8f9c6a8. If I understand the problem correctly, the pointer to the pScreen data for that picture is being overwritten by the xcalloc call.
A thought occured to be over dinner... Perhaps xcalloc() is working correctly, and that memory location was already freed. Ran it through valgrind and sure enough, that's the case. I'll go back and re-check where the free() occurs...
It seems that (...->pScreen) is being deleted early on during FreeClientResources(), but then needed later for a call by FreePicture(), also in FreeClientResources(). Initially I thought a quick workaround might be to add a if(!pScreen) to FreePicture(), but seeing how that memory has already been freed - there's no guarantee that (...->pScreen) will be 0x0.
Ahah! After adding some specific fprintf() statements to DeleteWindow, CrushTree, and Xfree(), a clear picture of what's going on is forming: If Xorg is run w/o Xdmx, and kpersonalizer displayed to that, there are 97 calls to Xfree() from DeleteWindow()->CrushTree(). Additionally, there are calls to FreePicture() before 6 of those Xfree()'s. Comparing that to when Xorg is run w/ Xdmx, and kpersonalizer displayed to Xdmx, there are still 97 calls to Xfree() from the same location. However, there are no calls to FreePicture() before those 6 Xfree()'s. I'll attach the output from valgrind from running the plain Xorg and the Xorg + Xdmx. I'll also attach a diff of the changes made in case anyone wants to duplicate.
Created attachment 30565 [details] valgrind output - plain Xorg kpersonalizer displaying to plain Xorg # X :0 -ac
Created attachment 30566 [details] valgrind output - Xorg + Xdmx kpersonalizer displaying to Xdmx # X :0 -ac # Xdmx :1 -ac +xinerama -display :0
Created attachment 30567 [details] fprintf-debugging-statements.patch
Created attachment 30570 [details] [review] dmxDestroyWindow() - must call the X's native DetroyWindow() Problem solved! dmxDestroyWindow wasn't calling X's DestroyWindow(). Here is the patch that fixes this bug.
Patch merged into http://cgit.freedesktop.org/~whot/xserver/ Thanks for your work, your effort is much appreciated. I'll close this bug once it hits master.
Closing Patch commited to git master as f713f447a2110718dfc091380699362d76f0cd6c.
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.