This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: segfault Xserver...current version (1.10, not 1.8)

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' it's "post-install
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 need to
call some common update routine that didn't get called to update the version?

Sounds like a case of the tar and post-install scripts expecting things to be
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 that setup
is broken -- and won't install single packages without alot of effort (as at least one other
person posted!),

So please be aware, I didn't know that cygcheck relied on some private-static
database may have little to do with the actual system (files could have been restore, as
well -- in fact WERE! the /bin dir, when nothing worked, I guess I thought
cygcheck looked at version numbers in the binaries...but ... well silly me (hey,
if it was something I relied on, I'd want it to tell me what the actual binaries are,
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 unexpected!)...

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 that it
occurred in.

The instructions below don't say anything about getting a stack backtrace
for the binary I'm running. They talk about downloading a different binary that
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 when I get time, I'll move forward with trying the instructions
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 [2] to obtain an Xserver backtrace would also be of great help.


-- Problem reports: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]