[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#297985: xserver-xfree86: X server crashes when compiling a program from gnat-gps



severity 297985 important
tag 297985 = upstream moreinfo
thanks

Your bug report had an inflated severity.  Please review the following
information.

Before filing a bug against the XFree86 X server, please note the
following, which is displayed by default when the "reportbug" command is
used with recent versions of the xserver-xfree86 package:

  Please be cautious with your bug severities.  Most bugs in the XFree86 X
  server are specific to particular drivers, and often manifest only on
  particular models of display adapter.  This means that while the X server
  may be unusable for you, it typically is not for the majority of users.
  Therefore, bug severities of "critical" or "grave" are seldom appropriate.

  In general, if the X server crashes, hangs, or locks up your system, the
  bug should be assigned a severity of "important".  If you are in doubt
  about what severity to use, choose "normal".  The Debian package
  maintainers will upgrade reports if they have severities that are too low
  -- you need not fear that your report will be ignored because it was filed
  with a lower severity than was appropriate.

[The following is a form letter.]

Can you reproduce the problem with xserver-xfree86-dbg?  Install the
package and tell debconf you want to use that X server.  Then restart the X
server and try to reproduce the bug (hopefully, this is easy).  If it
doesn't crash, let us know.  If a bug is in the XFree86 X server's ELF
module loader, you likely won't see it when you use the debugging server.
We still want to know that information.  If it does crash, become root,
enable core dumps ("ulimit -c unlimited" in bash), start the X server as
root and reproduce the crash again:

# startx $(which x-terminal-emulator) -- :1

(If no X server is running at DISPLAY=:0, you can leave off the "-- :1"
part).

This will launch the X server running a lone terminal client with no window
manager.  Run the client that provokes the crash from the terminal prompt.
If you can only reproduce the crash with a more elaborate environment, then
go ahead and produce that environment.  Be sure to tell us what you did to
get it (e.g., launching GNOME or KDE, setting up a particular screensaver,
running an SDL game -- whatever it takes).  It is not wise to run X clients
as root except when absolutely necessary, so if the session doesn't crash,
don't leave it running.  Shut it down as soon as you can.  It might also be
a good idea to scrub out root's home directory (/root) of hidden files and
directories created by desktop environments and whatever X clients you
attempted to reproduce the crash with.  Look for /root/.gnome /root/.kde,
and so forth.

If the X server crashes, it should leave a core dump in /etc/X11.

We then run the GNU Debugger, GDB, on the core file and executable.  We're
interested in a backtrace of execution.  The X server has a signal handler
in it so it can do things like exit gracefully (restoring the text console,
and so forth), so we're not actually interested in all the stack frames --
just those "above" the signal handler.

Here's an example GDB session I logged after provoking an artificial server
crash (with "kill -SEGV").

  % gdb $(which XFree86-debug) core
  GNU gdb 6.1-debian
  Copyright 2004 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for details.
  This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/libthread_db.so.1".

  Core was generated by `/usr/X11R6/bin/X :1'.
  Program terminated with signal 6, Aborted.
  Reading symbols from /usr/lib/libfreetype.so.6...done.
  Loaded symbols for /usr/lib/libfreetype.so.6
  Reading symbols from /usr/lib/libz.so.1...done.
  Loaded symbols for /usr/lib/libz.so.1
  Reading symbols from /lib/libm.so.6...done.
  Loaded symbols for /lib/libm.so.6
  Reading symbols from /lib/libc.so.6...done.
  Loaded symbols for /lib/libc.so.6
  Reading symbols from /lib/ld-linux.so.2...done.
  Loaded symbols for /lib/ld-linux.so.2
  #0  0x400f2721 in kill () from /lib/libc.so.6
  (gdb) bt
  #0  0x400f2721 in kill () from /lib/libc.so.6
  #1  0x400f24c5 in raise () from /lib/libc.so.6
  #2  0x400f39e8 in abort () from /lib/libc.so.6
  #3  0x08464b8c in ddxGiveUp () at xf86Init.c:1173
  #4  0x08464c6b in AbortDDX () at xf86Init.c:1224
  #5  0x08508bd7 in AbortServer () at utils.c:436
  #6  0x0850a563 in FatalError (f=0x8a26ea0 "Caught signal %d.  Server aborting\n") at utils.c:1421
  #7  0x0847fbf5 in xf86SigHandler (signo=11) at xf86Events.c:1198
  #8  <signal handler called>
  #9  0x40199dd2 in select () from /lib/libc.so.6
  #10 0x401f8550 in ?? () from /lib/libc.so.6
  #11 0x400164a0 in ?? () from /lib/ld-linux.so.2
  #12 0xbffff8f0 in ?? ()
  #13 0x08502520 in WaitForSomething (pClientsReady=0xbffff944) at WaitFor.c:350
  #14 0x084cff54 in Dispatch () at dispatch.c:379
  #15 0x084e763c in main (argc=2, argv=0xbffffe04, envp=0xbffffe10) at main.c:469
  (gdb) bt full -7
  #9  0x40199dd2 in select () from /lib/libc.so.6
  No symbol table info available.
  #10 0x401f8550 in ?? () from /lib/libc.so.6
  No symbol table info available.
  #11 0x400164a0 in ?? () from /lib/ld-linux.so.2
  No symbol table info available.
  #12 0xbffff8f0 in ?? ()
  No symbol table info available.
  #13 0x08502520 in WaitForSomething (pClientsReady=0xbffff944) at WaitFor.c:350
          i = 2
          waittime = {tv_sec = 118, tv_usec = 580000}
          wt = (struct timeval *) 0xbffff910
          timeout = 599999
          standbyTimeout = 1199999
          suspendTimeout = 1799999
          offTimeout = 2399999
          clientsReadable = {fds_bits = {0 <repeats 32 times>}}
          clientsWritable = {fds_bits = {1, 146318192, -1073743800, 140704020, 147350456, 147350040, 2, 312, 1, 1075418973, -1073743800, 139461033, 147374816, 1, -1073743680, 9, 1073833120, -1073742332, 
      -1073743784, 139526463, 9, -1073743680, 1, 139458611, 147350456, 147350040, -1073743752, 139529154, 147339744, -1073743680, 1, 1074655182}}
          curclient = 147556952
          selecterr = 3
          nready = 0
          devicesReadable = {fds_bits = {1, 1, 6, 146327832, 147350508, 0, 315, 302, 9, 3, 315, 302, 9, 3, 0, 0, 146318192, 1075807568, -1073743880, 137843170, 146125816, 3, 313, 147556952, 0, 15066597, 3, 
      -1, 147350500, 1, 0, 146319268}}
          now = 16069
          someReady = 0
  #14 0x084cff54 in Dispatch () at dispatch.c:379
          clientReady = (int *) 0xbffff944
          result = 0
          client = 0x8c8c2e0
          nready = -1
          icheck = (HWEventQueuePtr *) 0x8b45c68
          start_tick = 940
  #15 0x084e763c in main (argc=2, argv=0xbffffe04, envp=0xbffffe10) at main.c:469
          i = 1
          j = 2
          k = 2
          error = -1073742332
          xauthfile = 0xbfffffba "/root/.Xauthority"
          alwaysCheckForInput = {0, 1}
  (gdb) quit

In the example above, you can see I used "bt full -7" to get the
"outermost" seven stack frames, complete with local variable information,
where available.  Your stack trace may vary.  We want to see all the stack
frames *below* (numbered greater than) "<signal handler called>" in the
list.  If you get confused, just send us the output of "bt full" (with no
number after it) and we'll sort it out.

If you could send us such a stack trace, that would be very helpful.

-- 
G. Branden Robinson                |      We either learn from history or,
Debian GNU/Linux                   |      uh, well, something bad will
branden@debian.org                 |      happen.
http://people.debian.org/~branden/ |      -- Bob Church

Attachment: signature.asc
Description: Digital signature


Reply to: