This is the mail archive of the
mailing list for the Cygwin project.
Re: segfault Xserver...current version (1.10, not 1.8)
- From: Linda Walsh <cygwin at tlinx dot org>
- To: cygwin-xfree at cygwin dot com
- Cc: "cygwin at cygwin dot com" <cygwin at cygwin dot com>
- Date: Mon, 08 Aug 2011 16:39:55 -0700
- Subject: Re: segfault Xserver...current version (1.10, not 1.8)
- References: <4E3B3328.email@example.com> <4E3D6469.firstname.lastname@example.org> <4E3D8169.email@example.com> <4E3FD322.firstname.lastname@example.org>
Jon TURNEY wrote:.
Does this mean that the xorg-server version reported by cygcheck is
incorrect because you've installed the tar file by hand?
I just cannot understand how you could paste your cygcheck.out, but not
mention that important fact.
I cannot understand how you cannot understand that I'd have no inherent
clue how cygcheck would work or fail -- and that by taking a
cygwin-setup tar image
from it's setup dir, and installing it by hand, and then 'hand-calling'
script", wouldn't update the versions for cygcheck. I was surprised
when you highlighted
the wrong version.
I did run the post-install scripts for the package. Perhaps it they
call some common update routine that didn't get called to update the
Sounds like a case of the tar and post-install scripts expecting things
done, that are not clearly spelled out anywhere. So, how would would
you have expected
me to know that? Magic? It's not like I've had to do it before. Just
is broken -- and won't install single packages without alot of effort
(as at least one other
So please be aware, I didn't know that cygcheck relied on some
database may have little to do with the actual system (files could have
been restore, as
well -- in fact WERE!...in the /bin dir, when nothing worked, I guess I
cygcheck looked at version numbers in the binaries...but ... well silly
if it was something I relied on, I'd want it to tell me what the actual
not just what some static db thinks they are...but...that's me, and I'm
used to things not
always being the way the 'should' be...(so you have to program for the
Also, don't do that, it's not supported.
Installing single packages is supposed to be supported, it's broken.
What is the workaround?
Regarding a stack traceback -- I dont' see where the Xserver has produced
a corefile to run gdb on (???). Does it produce one?
Oh. I try to config most of my apps to generate core dumps so I can
get tracebacks of the actual problem that occurred in the actual binary
The instructions below don't say anything about getting a stack backtrace
for the binary I'm running. They talk about downloading a different
may not reproduce the problem. In which case, I don't know if the
problem is solved,
or something just didn't step on something, randomly in memory due to
some flailing pointer.
Anytime you substitute a binary, getting a stacktrace or trying to
produce a problem
becomes an iffy proposition, because you aren't using the same program.
That said, I suppose I don't care that much, other than to get the problem
fixed at some point...so when I get time, I'll move forward with trying
Which, BTW, I had already read before I asked about the coredumps for
the current binary --
(I'd like to know how to enable coredumps for the current binary! not a
different one, but
that may not be possible -- you might think about being able enable it
in the future based
on some ENV setting...just a thought)...
As I said once already:
Yes you did, but that wasn't my question -- all I asked was about core
dumps for the current
binary. I didn't say I wouldn't do the below -- nor did I say the below
told me to use
the core dumps from my current binary... It was a related question, but
not about how to do
the 'below'...sorry if that was confusing...
Following the instructions at  to obtain an Xserver backtrace would
also be of great help.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple