Bug 533879

Program received signal SIGABRT, Aborted.
0x00007fd7fa3986b5 in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);

Created attachment 368246 [details]
/var/log/Xorg.1.log

I tested on real hardware - an NVIDA 9400 GT - and, after I hacked it up enough to make sure the nouveau module didn't load, it worked and got through gdm. That was not a clean install or live boot test, it was my day-to-day working install. I was able to reproduce jlaska's crashes in a KVM using a live image, so I will test the exact same procedure on the same real hardware and another test machine shortly.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Yeah, attachment in the comment 2 has this backtrace:

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x49e8d8]
1: /usr/bin/X (0x400000+0x619c9) [0x4619c9]
2: /lib64/libpthread.so.0 (0x7fd7fbbab000+0xefa0) [0x7fd7fbbb9fa0]
Segmentation fault at address (nil)

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting

Still determining the blocker worthiness of this issue.  In the meantime, moving this under the appropriate X blocker bug.

(In reply to comment #5)
> Still determining the blocker worthiness of this issue.  In the meantime,
> moving this under the appropriate X blocker bug.  

Let's try that again, but with the correct bug#

tested on three real hardware systems now - NVIDIA 9400 GT, Radeon 4770, Vaio P (Intel Poulsbo) - vesa comes up fine on all of 'em. I'm feeling happier that this is restricted to qemu.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

for completeness, if this is qemu-only, it's not a blocker and well into 'doctor-it-hurts' territory. there's no reason to use the vesa driver within qemu.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

There's definitely something weird at work here.  We're crashing here:

(gdb) bt 1
#0  0x0014f6ff in bits_image_fetch_untransformed_repeat_none (image=0x9955878, 
    wide=<value optimized out>, x=<value optimized out>, 
    y=<value optimized out>, width=<value optimized out>, 
    buffer=<value optimized out>) at pixman-bits-image.c:497

which looks like:

if (x < image->width)
{
    w = MIN (width, image->width - x);

    if (wide)
        image->fetch_scanline_raw_64 ((pixman_image_t *)image, x, y, w, buffer, NULL, 0);
    else
        image->fetch_scanline_raw_32 ((pixman_image_t *)image, x, y, w, buffer, NULL, 0);
    width -= w;
    buffer += w * (wide? 2 : 1);
    x += w;
}

we're not in wide mode here, so this is fetch_scanline_raw_32.  But:

(gdb) print *image
$19 = {common = {type = BITS, ref_count = 1, clip_region = {extents = {x1 = 0, 
        y1 = 0, x2 = 0, y2 = 0}, data = 0x166e20}, have_clip_region = 0, 
    client_clip = 0, clip_sources = 1, dirty = 0, need_workaround = 0, 
    transform = 0x0, repeat = PIXMAN_REPEAT_NONE, 
    filter = PIXMAN_FILTER_NEAREST, filter_params = 0x0, n_filter_params = 0, 
    alpha_map = 0x0, alpha_origin_x = 8519915, alpha_origin_y = 10223880, 
    component_alpha = 0, classify = 0, 
    property_changed = 0x14f440 <bits_image_property_changed>, 
    get_scanline_32 = 0x14f750 <bits_image_fetch_untransformed_32>, 
    get_scanline_64 = 0x14f7b0 <bits_image_fetch_untransformed_64>, 
    destroy_func = 0x32d570 <destroy_drawable>, destroy_data = 0x9957218}, 
  format = 402819208, indexed = 0x0, width = 38, height = 34, 
  bits = 0x9957248, free_me = 0x0, rowstride = 38, fetch_pixel_raw_32 = 0, 
  fetch_pixel_raw_64 = 0, fetch_pixel_32 = 0, fetch_pixel_64 = 0xdd, 
  fetch_scanline_raw_32 = 0x9955fb0, fetch_scanline_raw_64 = 0, 
  store_scanline_raw_32 = 0, store_scanline_raw_64 = 0, 
  store_scanline_32 = 0x14ef50 <bits_image_store_scanline_32>, 
  store_scanline_64 = 0x14efb0 <bits_image_store_scanline_64>, read_func = 0, 
  write_func = 0}

fetch_scanline_raw_32 looks like it's something other than a function pointer.  pmap says that's backed by an anonymous mmap, and 'image' itself is:

(gdb) print image
$20 = (bits_image_t *) 0x9955878

so it sure does look like it's pointing into the malloc arena for some reason.

probably a dumb question, but does 'wide mode' have anything to do with the resolution of the display? because it occurs to me that all the systems I tested VESA works okay on have widescreen displays, whereas qemu is a square one (1024x768).

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

No, wide mode means more than 32bpp here.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Decoding the image format (402819208 = 0x18028888) we get

   bpp:   24 bit
   type:  ARGB
   a:     8
   r:     8
   g:     8
   b:     8

which is meaningless since there is more depth than there is bpp.

Pixman should certainly fail more graciously when people use unsupported formats, but the bug here is with whoever (presumably the vesa driver) created a picture with that combination.

Or rather, the render initialization code ends up adding a depth 32 bit format with a 24 bpp.

*** Bug 555221 has been marked as a duplicate of this bug. ***

Also fails on ATI Radeon 7200 on PowerPC. My computer is an Apple Power Mac G4 with AGP Graphics.

Problem exists on Fedora 11 as well.

william: what exactly do you mean? Are you using the vesa driver? seeing the same failure as the above? If not, please file a new bug. Thanks.

Yes, someone reccomended that I try to use the VESA driver to circumvent problems with the Radeon driver in Fedora 11 (and 12). X refuses to start with the VESA driver when used with my video card. I'd have to look more closely at the output, but I filed my comments based on the basic description of the bug. There are so many log files and output readings above that it's hard to compare, especially when the bug was originally reported against virtual hardware, but then others are testing it on actual hardware. When I get home tonight I will try to reproduce and post some output.

Uh, Adam:

I unintentionally deleted the mini x.conf file that started X in VESA mode. I remember that the file only had like three lines in it, but I can't remember what it said. If you could tell me what little bit needs to be in there to get this to load in VESA mode again, I can post my output.

Thanks,
William

Take a look at:

https://fedoraproject.org/wiki/How_to_create_xorg.conf

Thanks. Yeah, I've even read that article before, I don't know why I couldn't think of that. Here is my output. Please let me know if this looks like an entirely different bug to you or if it actually fits in here.

------------------------

[William@localhost ~]$startx
xauth:  creating new authority file /home/William/.serverauth.1566


X.Org X Server 1.6.3.901 (1.6.4 RC 1)
Release Date 2009-8-25
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.18-164.el5 ppc
Current Operating System: Linux localhost.localdomain 2.6.30.10-105.fc11.ppc #1
 Thu Dec 24 16:28:20 UTC 2009 ppc
Kernel Command line: root=/dev/mapper/VolGroup-lv_root ro rhgb quiet
Build Date: 09 September 2009 11:36:55AM
Build ID: xorg-x11-server 1.6.4-0.1.fc11
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implememented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Oct 11 10:37:12 1976
(==) Using config file: "/etc/X11/xorg.conf"

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x50) [0x101014e0]
1: /usr/bin/X(xf86SigHandler+0xd8) [0x10085fc8]
2: [0x100364]
3: /usr/lib/xorg/modules//libint10.so(LockLegacyVGA+0x50) [0xf241c30]
4: /usr/lib/xorg/modules//libint10.so(xf86ExtendedInitInt10+0x1e0) [0xf245f30]
5: /usr/lib/xorg/modules//libvbe.so(VBEExtendedInit+0x320) [0xf281760]
6: /usr/lib/xorg/modules/drivers//vesa_drv.so [0xf2a9f24]
7: /usr/bin.X(InitOutput+0x5bc) [0x1006a6cc]
8: /usr/bin/X(main+0x224) [0x10021bb4]
9: /lib/libc.so.6 [0xf7f343c]
10: /lib/libc.so.6 [0xf7f35e0]

Fatal server error:
Caught signal 7. Server aborting


Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
Please also check the log file at "/var/log/Xorg.o.log" for additional
 information.

giving up.
xinit:  No such file or directory (errno 2):  unable to connect to X server
xinit:  No such process (errno 3):  Server error.

------------------------------

And yes, I see that my year on my clock is at 1976. If anybody could shoot me an e-mail as to how to fix that without XWindows and without Mac OS installed on a Power Mac G4, I would appreciate it. Please don't post the response here, as it is probably not relevant to the bug. I don't have good access to the mailing list now since apparently the postmaster for the Fedora Project doesn't like GMANE. If anyone wants to argue about that, please shoot me an e-mail about that, too, don't write about it here.

As for the log file, that is going to take some difficult maneuverings with my home networking and mini-server programs to get up here if you need it, I can't type that whole thing out like I did with this screen output.

Created attachment 387081 [details]
My Xorg.0.log file showing the VESA driver failure.

William, that crash is almost certainly unrelated to this bug. Please file a new bug against the vesa driver.

Done.

Bug 559317

changing the title to emphasize virtual nature of this bug

xorg-x11-drv-vesa-2.3.0-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/xorg-x11-drv-vesa-2.3.0-2.fc14

xorg-x11-drv-vesa-2.3.0-2.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-vesa'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/xorg-x11-drv-vesa-2.3.0-2.fc14

(In reply to comment #8)
> for completeness, if this is qemu-only, it's not a blocker and well into
> 'doctor-it-hurts' territory. there's no reason to use the vesa driver within
> qemu.

The vesa driver offers a much better range of guest screen resolutions than the cirrus one, or at least it did in F12 when it worked well. In F13 it was unbearably slow (Bug #589447) and with an F14 guest on an F13 host I can't get it to work at all at the moment.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

xorg-x11-drv-vesa-2.3.0-2.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.