System Environment: -------------------------- --Architecture: 32-bit and 64-bit --2D driver: git commit:be0591880f20bdcbae159d5ab47113b6cc6fbffe --3D driver: Mesa master commit: ba38909be21e4b33121b87bb7ac8743886a4f706 --DRM: git commit:5d8c754bc2c720d70bbdeca6b294660105717a62 --Xserver: git commit:3abce3ea2b1f43bd111664d4a57e5ccd282acab0 --Kernel: 2.6.23 Bug Description: when start a X.following error messages appear: Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/opt/X11R7/var/log/Xorg.0.log", Time: Tue Feb 19 15:46:14 2008 (==) Using config file: "/etc/X11/xorg.conf" Backtrace: 0: X(xf86SigHandler+0x79) [0x80ac1b9] 1: [0xffffe420] 2: X [0x80a1e4c] 3: X(DuplicateModule+0x38) [0x80a3768] 4: X(xf86AllocateScreen+0xe0) [0x80d1ec0] 5: X(xf86ConfigPciEntity+0x177) [0x80d2187] 6: /opt/X11R7/lib/xorg/modules/drivers//intel_drv.so [0xb7e1ecd1] 7: X(xf86CallDriverProbe+0x19b) [0x809f21b] 8: X(InitOutput+0x759) [0x80a09d9] 9: X(main+0x25b) [0x806b07b] 10: /lib/libc.so.6(__libc_start_main+0xdc) [0x9eb7e4] 11: X(FontFileCompleteXLFD+0x89) [0x806a6b1] Fatal server error: Caught signal 11. Server aborting [1]+ Segmentation fault I did a bisect and find commit 3abce3ea2b1f43bd111664d4a57e5ccd282acab0 import this problem: commit 3abce3ea2b1f43bd111664d4a57e5ccd282acab0 Author: Arjan van de Ven <arjan@infradead.org> Date: Mon Feb 18 18:13:10 2008 +1030 xfree86: plug a memory leak in xf86LoadModules. LoadModule() returns the only reference to a fresh piece of memory (a ModuleDescPtr). Sadly, xf86LoadModules dropped the return value on the floor leaking memory for each module it loaded.
*** This bug has been marked as a duplicate of bug 14536 ***
(In reply to comment #1) > > *** This bug has been marked as a duplicate of bug 14536 *** > I build the xserver(commit:6cbaf15e6109ba77819c4070f5b46c78237ec460) and the problem still exist.
(In reply to comment #2) > (In reply to comment #1) > > > > *** This bug has been marked as a duplicate of bug 14536 *** > > > > I build the xserver(commit:6cbaf15e6109ba77819c4070f5b46c78237ec460) and the > problem still exist. 6cbaf1... fixed the problem for me. can you provide a bit more info into what exactly causes the segfault? And where it happens? It could be that the memory we free is indeed referenced again. I had a look at that yesterday night but didn't find anything.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > > > > *** This bug has been marked as a duplicate of bug 14536 *** > > > > > > > I build the xserver(commit:6cbaf15e6109ba77819c4070f5b46c78237ec460) and the > > problem still exist. > > > 6cbaf1... fixed the problem for me. can you provide a bit more info into what > exactly causes the segfault? > And where it happens? > > > It could be that the memory we free is indeed referenced again. I had a look at > that yesterday night but didn't find anything. > Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1209682256 (LWP 4289)] 0x080a36dd in LoadSubModule (parent=0x0, module=0xb7dcd9c0 "int10", subdirlist=0x0, patternlist=0x0, options=0x0, modreq=0x0, errmaj=0xbfb65228, errmin=0xbfb65224) at loadmod.c:747 747 return (new); (gdb) bt #0 0x080a36dd in LoadSubModule (parent=0x0, module=0xb7dcd9c0 "int10", subdirlist=0x0, patternlist=0x0, options=0x0, modreq=0x0, errmaj=0xbfb65228, errmin=0xbfb65224) at loadmod.c:747 #1 0x080ce6fe in xf86LoadSubModule (pScrn=0x821cae8, name=0xb7dcd9c0 "int10") at xf86Helper.c:2367 #2 0xb7da980a in I830PreInit (pScrn=0x821cae8, flags=0) at i830_driver.c:1070 #3 0x080a0c7c in InitOutput (pScreenInfo=0x81eaf20, argc=1, argv=0xbfb65464) at xf86Init.c:752 #4 0x0806b07b in main (argc=1, argv=0xbfb65464, envp=0xbfb6546c) at main.c:356 in file xserver/hw/xfree86/loader/loadmod.c +744AddSibling(ModuleDescPtr head, ModuleDescPtr new) +745{ +746 new->sib = head; +747 return (new); } _X_EXPORT ModuleDescPtr LoadSubModule(ModuleDescPtr parent, const char *module, const char **subdirlist, const char **patternlist, pointer options, const XF86ModReqInfo * modreq, int *errmaj, int *errmin) { ModuleDescPtr submod; xf86MsgVerb(X_INFO, 3, "Loading sub module \"%s\"\n", module); if (PathIsAbsolute(module)) { xf86Msg(X_ERROR, "LoadSubModule: Absolute module path not permitted: \"%s\"\n", module); if (errmaj) *errmaj = LDR_BADUSAGE; if (errmin) *errmin = 0; return NULL; } submod = doLoadModule(module, NULL, subdirlist, patternlist, options, modreq, errmaj, errmin, LD_FLAG_GLOBAL); if (submod && submod != (ModuleDescPtr) 1) { +774 parent->child = AddSibling(parent->child, submod); submod->parent = parent; } return submod; }
so I'm reopening.
reverted and pushed as 67a78e84a81571cedaf7fd214a21ce1bbdc4fb3b. turns out the module _was_ referenced elsewhere and what looked like a memory leak wasn't actually a leak at all. sorry for the noise.
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.