Hi,
About 14 months ago, you reported a bug to the Debian BTS regarding a
crash of Xemacs on a nVidia board, possibly caused by a bug in libX11.
Did you reproduce this problem recently? If not, I will close this bug
in the next weeks.
Thanks,
Brice
--
To UNSUBSCRIBE, email to [EMAIL
On Mon, 2007-02-12 at 11:41 +0100, Brice Goglin wrote:
About 14 months ago, you reported a bug to the Debian BTS regarding a
crash of Xemacs on a nVidia board, possibly caused by a bug in libX11.
Did you reproduce this problem recently?
No, I haven't seen this in a while. I think it's OK to
Hi.
From: [EMAIL PROTECTED]
Subject: Re: Bug#343129: xemacs / libX11 / NVIDIA crashes on opteron under
kernel 2.6.14-2
Date: Wed, 14 Dec 2005 10:38:29 -0700
In working to figure out debian bug 343129, which involves crashes in
Xemacs, Ben Wing suggested compiling my own xemacs (21.4.18
Stephen J. Turnbull writes:
Ben == Ben Wing [EMAIL PROTECTED] writes:
Ben the best way to know for sure is for you to compille XEmacs
Ben yourself, with debugging support.
Also, Debian supplies -dbg packages for the X libraries, so you would
be able to get useful traces.
[EMAIL PROTECTED] writes:
OK, see the backtrace with the dbg version of libx11-6 below. We now
we know what xemacs passed, and where the libx11 died, and the error
is no such file or directory . Looking at the source for that file
(ChkIfEv.c) doesn't show any obvious (to me) place where a
Ben == Ben Wing [EMAIL PROTECTED] writes:
Ben the best way to know for sure is for you to compille XEmacs
Ben yourself, with debugging support.
Also, Debian supplies -dbg packages for the X libraries, so you would
be able to get useful traces. You just use LD_LIBRARY_PATH (or
something
Ohura-san,
In working to figure out debian bug 343129, which involves crashes in
Xemacs, Ben Wing suggested compiling my own xemacs (21.4.18) for
debugging. When I do that, the crash goes away. I configured it with
--debug and --with-gnome. What other flags did you use to configure
the
Ben Wing writes:
do the backtraces always look like this or do they vary?
They are always in XCheckIfEvent, although how they get there varies,
e.g.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912549568976 (LWP 29564)]
0x2bfb4ac0 in
Lonni J Friedman writes:
I have a few questions
Thanks for the quick response.
0) Does this reproduce if you're not using RenderAccel?
Yes. At least commenting out
#Option RenderAccel true
in the screen section of xorg.conf and restarting X doesn't fix the
problem.
Larry,
Given that this problem also exists with the 'nv' X driver, and you
cannot start X with the nvidia driver with the glx module, there's
likely something else broken in your environment. As you stated, it
sounds like you're hitting an X bug somewhere.
I'd be happy to help you with the
[EMAIL PROTECTED] wrote:
Ben Wing writes:
do the backtraces always look like this or do they vary?
They are always in XCheckIfEvent, although how they get there varies,
e.g.
ok, that's expected, since there are many places that the QUIT macro
occurs and it's triggered asynchronously.
Larry Hunter wrote:
Package: xlib11-6
Version: 6.8.2.dfsg.1-11
Severity: Important
X-Debbugs-CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
On an opteron /debian system, I recently upgraded to xemacs 21.4.18
using the Debian package xemacs-gnome-nomule, and now I get segfaults
in xemacs. I had
12 matches
Mail list logo