Re: segfault Xserver...current version (1.8)
Csaba Raduly wrote: On Sat, Aug 6, 2011 at 8:01 PM, Linda Walsh wrote: Jon TURNEY wrote: (snip) Next time, please *attach* the *full* XWin.0.log --- That was the full log...it had been truncated -- perhaps by the failing processes...A full log from a non-crashed version (i.e. I haven't run yast2), is here: To attach is to use File-Attach-File... or click the paperclip icon, as opposed to pasting the log into the body of the message. Ah...I focused on the 'full' part, not the attached part. It's just damn confusing. One list, filters attachments, another, they expect it... ARG! Also, please set Thunderbird to attach files correctly: --- Don't worry, Have done so in the past, forgot that this list *wants* them as attachments (vs. some others lists where such will be automatically stripped)... http://blog.crox.net/archives/23-How-to-set-thunderbird-to-correctly-attach-text-files-with-Content-Disposition-attachment-instead-of-inline.html Yeah -- that's why I don't like to include cygcheck.out's They give out lots of info that isn't _entirely_ relevant. It's not even an accurate package listing if one has installed packages w/tar by hand. What you deem relevant may not match what others on this list deem relevant. You might omit information that would have helped diagnosing your problem. There's a reason for what's written in Problem reports: http://cygwin.com/problems.html --- There are reasons for everything we come up with. That doesn't mean they are _always_ good reasons. Note I did try to underline the word entirely, AND, I did include it, whatever my reservations. I was merely commenting on how, in some cases it provides 'random goose chase' information. More often than not, I've seen it used to blow off user bug reports because some i isn't dotted, or t, crossed. Whatever, I understand, which isn't to say I always necessarily enjoy it -- but in this circumstance, considering the abstractions and mixtures of SW, I thought such a report more than reasonable to provide. I'm just wondering if there's a way to turn on coredumps and give stack traces of the X I'm running vs. downloading some 'extra special' version. I get coredumps on linux and windows, and am able to generate backtrace info on both for many situations (more on linux than windows), sometimes it leads me to investigate things more on my own and even find workaround or fixes, but the X server hasn't crashed on me since the last report, (but I am steering away from running yast2 for the time being!) C'est la vie Cheers! Linda -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: segfault Xserver...current version (1.10, not 1.8)
On 06/08/2011 19:01, Linda Walsh wrote: 1.8.0-1 is not the current version, 1.10.3-1 is (See [1]). I'm running 1.10.3.1 as you can see from the full log... I will now crash my xserver... [duplicate portions of above log suppressed...exactly the same timestamps up to [4096.679]]. [100813.992] Segmentation fault at address 0x0 [100813.992] Fatal server error: [100813.992] Caught signal 11 (Segmentation fault). Server aborting [100813.992] Works fine for most things... But ran yast2, on my suse box kills it every time. w/signal 11. If this is still reproducible when you've upgraded to the current version of the Xserver, can you tell me what SuSE version you are using, please? Suse 11.4 Ishtar: rpm -qa|grep -P '(?:patterns.*yast2)|(?:yast2.*ui-.*)' yast2-ycp-ui-bindings-2.20.3-3.1.x86_64 patterns-openSUSE-yast2_install_wf-11.4-6.9.1.x86_64 yast2-ycp-ui-bindings-devel-2.20.3-3.1.x86_64 yast2-libyui-devel-2.20.2-3.1.x86_64 patterns-openSUSE-yast2_basis-11.4-6.9.1.x86_64 yast2-libyui-2.20.2-3.1.x86_64 I cannot reproduce this problem running yast2 from SuSE 11.4 on x86. Following the instructions at [2] to obtain an Xserver backtrace would also be of great help. --- Previous version didn't have a problem. 'Previous' is not a number. cygcheck.out: [snip] xorg-server 1.8.0-1 OK [snip] - Yeah -- that's why I don't like to include cygcheck.out's They give out lots of info that isn't _entirely_ relevant. It's not even an accurate package listing if one has installed packages w/tar by hand. 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. Also, don't do that, it's not supported. Regarding a stack traceback -- I dont' see where the Xserver has produced a corefile to run gdb on (???). Does it produce one? No. As I said once already: Following the instructions at [2] to obtain an Xserver backtrace would also be of great help. [2] http://x.cygwin.com/devel/backtrace.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
'de' keyboard layout issues (Re: AW: AW: AltGr key mostly fires an additional CONTROL key)
On 04/08/2011 03:21, Paul Maier wrote: Thanks for the logs, that was very useful. I still can't reproduce this (although holding AltGr down to make it autorepeat seems the best way to try to do that). It is a timing issue with the keypress/release messages so it might be sensitive to CPU speed, or perhaps you have some software installed which looks at keypress/release messages and changes the timing? I've had a go at fixing it. Can you please try the build I've uploaded at [1] and see if it still shows the problem for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.20110803-git-a493c0465e56ce0b.exe.bz2 Hi Jon, works fine for me. I Played around quite a while, but the CONTROL-locking didn't occur any more. Yippie! Is it ok, if I leave the hotfix file permanently in on my PC (I mean, did you base it on a recent XWin released version with just my bug fix in - or is there other experimental stuff inside?), then I'll use it automatically during work and I can let you know in case of problems. That particular build is 1.10.3-1 plus the patch for your issue. I wouldn't have started a thread with the following, but since we have already started looking at this keyboard, maybe you are interested in some of these: A new thread would have been fine :-) I am assuming you are using the 'de' keyboard layout: [ 29391,484] (--) Windows keyboard layout: 0407 (0407) Deutsch, type 4 [ 29391,484] (--) Found matching XKB configuration German (Germany) [ 29391,484] (--) Model = pc105 Layout = de Variant = none Options = none [ 29391,484] Rules = base Model = pc105 Layout = de Variant = none Options = none Tilde sign (~) should be a normal (not a blind) key. In Windows I hit AltGr++ to get ~, in XWin I need to type AltGr++ then space to get a ~. See attachment for the initial XWin xmodmap -pke table. Possible xmodmap correction (works fine): keycode 35 = plus asterisk plus asterisk asciitilde This is a can of worms I don't want to open :-) At the moment, in the 'de' layout, the tilde deadkey will add a macron diacritic, e.g. AltGr + + + a = ã. I really lack the expertise to determine if this is a bug in xkeyboard-config (if this german keyboard behavior is something no german keyboard user would ever expect or want) The xkb configurations we use come from the xkeyboard-config project, and aren't trying to be identical to Windows, but to conform to the appropriate national standards and user expectations. However, I can see in the case of XWin this is problematic, as it will be confusing to switch between X and normal Windows windows which have different keyboard behavior. As a workaround, you might find specifying -xkbvariant nodeadkeys, deadgraveacute or deadacute helpful. Euro Currency sign doesn't work. I know - it's not a latin1 character, but together with CP1252 this xmodmap correction works like Windows: keycode 26 = e E e E 0x0080 I guess this is another symptom of Xlib not understanding the de_DE.CP1252 locale. This works fine in the de_DE.UTF-8 locale. I suppose I could patch Xlib to fix this, but I'd rather encourage people to use UTF-8 locales. ALT+Space produces a NBSP character (HEX A0) in Windows, but not in XWin. xmodmap correction is unfortunately not possible, because the xmodmap setting on ISO_Level3_Shift+Space is just thrown away: Something like keycode 65 = space NoSymbol space NoSymbol nobreakspace or keycode 65 = space space space space nobreakspace doesn't work: it's discarded and the setting is not shown on a xmodmap -pke. So I put nobreakspace to the fifth place of another key - there it works. That would be good if key 65 (space key) would accept above xmodmap setting or have it initially. Reading [1], this looks like an (undocumented) Windows-ism http://en.wikipedia.org/wiki/Non-breaking_space#Keyboard_entry_methods Number block is not working. See attachment for the initial XWin xmodmap -pke table (all these KP_* settings look good at the first sight, but the keys don't produce numbers). Possible xmodmap correction (works fine): keycode 63 = asterisk asterisk keycode 79 = 7 7 keycode 80 = 8 8 keycode 81 = 9 9 keycode 82 = minus minus keycode 83 = 4 4 keycode 84 = 5 5 keycode 85 = 6 6 keycode 86 = plus plus keycode 87 = 1 1 keycode 88 = 2 2 keycode 89 = 3 3 keycode 90 = 0 0 keycode 91 = period period keycode 108 = Return Return keycode 112 = slash slash I can't reproduce this problem. I wonder if this is a problem with handling numpad overlaid onto normal keys on a laptop keypad? Again, -logverbose 3 output together with xev output would be helpful. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ:
Re: Problem starting XWin Server
On 30/07/2011 07:10, Jan Chludzinski wrote: From within a mintty shell, I get: $ startxwin giving up. startxwin: No such file or directory (errno 2): unable to connect to X server startxwin: No such process (errno 3): Server error. That's odd. I can't really understand how that can happen. I'd suspect that startxwin is failing to fork/exec Xwin successfully, possibly due to an application causing cygwin difficulties [1] (Unfortunately, 64-bit Windows itself seems to sometimes cause similar problems) Are you able to start the server directly by running 'XWin'? [1] http://cygwin.com/faq-nochunks.html#faq.using.bloda -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
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? --- 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 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
