Summary: | x start fail | ||
---|---|---|---|
Product: | xorg | Reporter: | Pi, Fengming <fengming.pi> |
Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> |
Status: | VERIFIED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | normal | ||
Priority: | high | CC: | peter.hutterer |
Version: | git | ||
Hardware: | All | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Pi, Fengming
2008-02-18 23:55:04 UTC
*** 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.