| Summary: | [intel] glxcontexts eventually fails from running out of address space. | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | lin, jiewen <jiewen.lin> |
| Component: | Drivers/DRI/i915 | Assignee: | Eric Anholt <eric> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | jian.j.zhao |
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
xorg.conf
Xorg.0.log |
||
xorg.conf: https://bugs.freedesktop.org/process_bug.cgi#attach_19180 Xorg.0.log: https://bugs.freedesktop.org/process_bug.cgi#attach_19181 It works well with mesa_7_2_branch. Created attachment 19227 [details]
xorg.conf
Created attachment 19228 [details]
Xorg.0.log
commit 7d99ddcb2bb09f1f54d91e6e20e42d217a5bccdf Author: Eric Anholt <eric@anholt.net> Date: Fri Sep 26 12:48:23 2008 -0700 intel: Fix a number of memory leaks on context destroy. This fixes some of the problem, however mesa_7_2_branch, intel-2008-q3, and master, whether GEM or classic, still all leak memory in this context create/render/destroy testcase. The severity varies between the cases, and the messages will vary depending on GEM or not and exactly when in execution you run out of address space. However, they all have the same cause that needs to be fixed, and thus I'm removing the gem-classic annotation from the bug. This leak isn't much of a concern for DRI client apps, as few things allocate many contexts over their lifetimes. However, for AIGLX, we'll see many context create/destroys over the lifetime of the server, making this a concern. It is also not i915-specific, as the worst of the leak is going on in intel_*.c code. One worthwhile note: at this point we're not leaking kernel-side buffer objects from this test on 915 in GEM mode. Classic mappings get leaked from renderbuffer create/destroy cycles, so userland-side BO structs are getting leaked. Additionally, significant quantities of heap are being leaked, and valgrind wasn't being very helpful in figuring it out. *** Bug 17783 has been marked as a duplicate of this bug. *** Removing from blocker list, as it's merely a regression in severity, not existence of the bug. Ran it for a minute and a half with stable memory allocation size. Appears to be fine at this point. Verified on 945gm with following commits: Libdrm: (master)d74c67fb13d8c3e8c2e5968d827285d147a5dfc0 Mesa: (master)1f40ffca634b8d6699c9b5d153c231e79527317a Xserver: (master)36e24a6d93bd5aced4e566b80bf2d03555fab9ca Xf86_video_intel: (master)713820197755ea53003b36a920922c3c525eeeea |
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.
System Environment: -------------------------- --Platform: 945gm --Architecture(32-bit,64-bit,compatiblity): 32-bit --2D driver: xf86-video-intel-2.5-branch 8408995ffbf705aa0bc09ab72c58c2e31a4b70c3 --3D driver: intel-2008-q3 branch e636f5b76bbcfef95092d21646c844c0dfe770e0 --DRM:shipped with kernel 2.6.27-rc5 --libdrm: master 2db8e0c8ef8c7a66460fceda129533b364f6418c --Xserver: 1.5.1 --Kernel: 2.6.27-rc5 Bug detailed description: -------------------------- start X and run glxcontexts, it run for a second and then quit with meassage"Failed to drmMap depth buffer Segmentation fault " Reproduce steps: ---------------- 1. xinit & 2. ./glxcontexts