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

[Linda Walsh]

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?
---
	apparently.
> 
> 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!...in 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?
> 
> No.
---
	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 point...so when I get time, I'll move forward with trying 
the instructions
below...
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.
> 
> [2] http://x.cygwin.com/devel/backtrace.html
> 

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple