| Summary: | SIGABRT caused by malloc around exaPrepareAccessReg_mixed | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Brandon Philips <brandon> | ||||||||||||||
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> | ||||||||||||||
| Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||
| Severity: | normal | ||||||||||||||||
| Priority: | medium | ||||||||||||||||
| Version: | git | ||||||||||||||||
| Hardware: | Other | ||||||||||||||||
| OS: | All | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
Created attachment 41188 [details]
dmesg
Created attachment 41189 [details]
gdb backtrace
Is there more information about the malloc failure in the X server stderr output? Should be captured in the gdm/kdm log file. Does the patch from bug 32803 happen to help for this as well? Created attachment 41982 [details]
/var/log/gdm/:0.log.2
Here is the gdm capture from Xorg. NOTE: I had to add export LIBC_FATAL_STDERR_=1 to get this.
(In reply to comment #4) > Does the patch from bug 32803 happen to help for this as well? Yes, I have the patch from 32803 and I am still hitting the bug. I am running the latest xorg-x11-server from openSUSE: https://build.opensuse.org/package/show?package=xorg-x11-server&project=X11%3AXOrg Thanks, Brandon Created attachment 41985 [details]
Latest backtrace
With the latest Xorg available to me the backtrace has changed abit and is around malloc in exaPrepareAccessReg_mixed().
Starting with MALLOC_CHECK=3 still works around the issue.
Created attachment 41986 [details]
gdm capture of latest Xorg crash
Here is what gdm captured from the latest Xorg when it crashes.
Well, the backtraces from the Xorg and gdm log files and from gdb all look different. :} So as in bug 32453, the real problem could be memory corruption somewhere else which is only caught in these places. Apart from running the X server in valgrind, getting a gdb backtrace for the free() failure in the gdm log file might be useful. Would http://cgit.freedesktop.org/xorg/xserver/patch/?id=99eeb211c73d28a60f9024f42cf9f9e45b8b0c3d happen to help? It appears that this bug report has laid dormant for quite a while. Sorry we haven't gotten to it. Since we fix bugs all the time, chances are pretty good that your issue has been fixed with the latest software. Please give it a shot. (Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git versions.) If upgrading to the latest isn't an option for you, your distro's bugzilla is probably the right destination for your bug report. In an effort to clean up our bug list, we're pre-emptively closing all bugs that haven't seen updates since 2011. If the original issue remains, please make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/ for what we need to see, and re-open this one. Thanks, The Nouveau Team |
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.
Created attachment 41187 [details] Xorg.1.log from the machine Using git nouveau kernel, libdrm, and nouveau xorg driver as of today on top of openSUSE Factory Xorg. Backtrace from gdb: #0 0x00007ff87fbb6ad5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ff87fbb7fd6 in abort () at abort.c:92 #2 0x00007ff87fbf75da in __malloc_assert (assertion=<value optimized out>, file=<value optimized out>, line=<value optimized out>, function=<value optimized out>) at malloc.c:352 #3 0x00007ff87fbf97a6 in sYSMALLOc (av=0x7ff87feece80, bytes=15335424) at malloc.c:3094 #4 _int_malloc (av=0x7ff87feece80, bytes=15335424) at malloc.c:4747 #5 0x00007ff87fbfbc69 in __libc_malloc (bytes=15335424) at malloc.c:3661 #6 0x00007ff87d146ef4 in exaPrepareAccessReg_mixed (pPixmap=0x1aef1a0, index=1, pReg=0x0) at exa_migration_mixed.c:203 #7 0x00007ff87d143602 in exaChangeWindowAttributes (pWin=0x1ad5dc0, mask=1) at exa.c:652 #8 0x00000000005602d7 in compChangeWindowAttributes (pWin=0x1ad5dc0, mask=1) at compinit.c:114 #9 0x0000000000436c4d in ChangeWindowAttributes (pWin=<value optimized out>, vmask=1, vlist=<value optimized out>, client=0xb870d0) at window.c:1459 #10 0x000000000043cb78 in ProcChangeWindowAttributes (client=0xb870d0) at dispatch.c:693 #11 0x00000000004428f1 in Dispatch () at dispatch.c:432 #12 0x0000000000425b5e in main (argc=9, argv=<value optimized out>, envp=<value optimized out>) at main.c:291 If I use the vesa driver the system comes up fine. Reproducing by launching emacs inside of a gnome session. If I use MALLOC_CHECK_=3 /etc/init.d/xdm restart I can sometimes get Xorg w/ nouveau to work for a few days before crashing. But, that isn't a real solution.