Bug 30712 - segfault when setting resolution to 2560x1600, possibly related to disabling 3D on Radeon HD 4670
Summary: segfault when setting resolution to 2560x1600, possibly related to disabling ...
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-08 10:09 UTC by Adam J. Richter
Modified: 2018-06-12 19:06 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
Xorg log file of crash when setting resolution to 2560x1600, perhaps related to disabling 3D (159.29 KB, patch)
2010-10-08 10:09 UTC, Adam J. Richter 		no flags Details | Splinter Review
excerpt from running gdb on X server crashing when setting resolution of DVI-1 monitor to 2560x1600 (DVI-0 is 1920x1200) (930 bytes, text/plain)
2010-10-08 10:10 UTC, Adam J. Richter 		no flags Details
gdb log of Xorg-1.9.0.901 + xf86-video-ati git (2010.10.08) + Mesa-7.9 under Electric Fence (2.26 KB, text/plain)
2010-10-08 12:03 UTC, Adam J. Richter 		no flags Details
View All

Description Adam J. Richter 2010-10-08 10:09:26 UTC 
Created attachment 39291 [details] [review]
Xorg log file of crash when setting resolution to 2560x1600, perhaps related to disabling 3D

I have two screens: DVI-0 drives a 1920x1200 display and DVI-1 drives a 2560x1600 display that initially comes up as 1920x1200.  If I layout the screens horizontally in a 4480x1600 frame buffer with the 2560x1600 display on the left (origin 0,0) and the 1920x1200 display on the right (origin 2560,0).  One of two things occurs:

1. the X server gets a segmentation fault, or
2. if the X server had been running for a while, the server does not get a segmentation fault, but 3D effects in gnome desktop are disabled (not a big problem, but worth mentioning for debugging).

I got the X server to crash while attached to gdb, and my hypothesis is that the X server is trying to deference a pointer that points to something that may have been freed already.  I think that this happens less often if the X server has been running for a while because perhaps that memory address gets reallocated and becomes a readable address again.

I have attached a server log file and an excerpt from a gdb session.
Comment 1 Adam J. Richter 2010-10-08 10:10:38 UTC 
Created attachment 39292 [details]
excerpt from running gdb on X server crashing when setting resolution of DVI-1 monitor to 2560x1600 (DVI-0 is 1920x1200)
Comment 2 Alex Deucher 2010-10-08 10:24:09 UTC 
Does this only happens when you have a GL compositor running?  Mesa has a maximum texture size limit of 4k even though the hw is capable of 8k textures.  Your desktop is larger than that limit.
Comment 3 Adam J. Richter 2010-10-08 12:03:32 UTC 
Created attachment 39294 [details]
gdb log of Xorg-1.9.0.901 + xf86-video-ati git (2010.10.08) + Mesa-7.9 under Electric Fence

I don't know how to turn off 3D effects in gnome desktop, but running the X server under electric fence gets a memory fault in free() in 3D initialization shortly after I log into the gnome desktop via gdm.  This is with ElectricFence configured to allow zero length mallocs.  I have attached a gdb excerpt.

The attached gdb excerpt is from Xorg-1.9.901 + Mesa-7.9, but it also happens under Xorg-1.9.0 + Mesa-7.8.1.

Also thanks for the note about the 4K texture size limit.
Comment 4 Alex Deucher 2010-10-08 12:26:04 UTC 
(In reply to comment #3)
> I don't know how to turn off 3D effects in gnome desktop, 

System -> Preferences -> Desktop Effects on most distros.
Comment 5 Alex Deucher 2012-04-25 06:03:12 UTC 
Is this still an issue with a newer driver/kernel?
Comment 6 Adam Jackson 2018-06-12 19:06:38 UTC 
Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.

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.