Bug#295605: pterm doesn't start
On Thu, May 26, 2005 at 05:24:36PM +0100, Colin Watson [EMAIL PROTECTED] wrote: On Sun, Feb 20, 2005 at 06:16:30PM +0100, Marc A. Lehmann wrote: On Sun, Feb 20, 2005 at 02:27:24PM +, Jacob Nevins [EMAIL PROTECTED] wrote: This sounds to me like it might be a problem with libgtk1.2 rather than putty. But it's clearly not font-related, as the badmatch is in response to a XChangeProperty, at least in the dump I made. (Clearly pterm starts for some people, so there must be something specific about your situation that's breaking it.) I investigated a bit more, and the problem seems to occur when another app stores a non-latin1 string in the cut buffer (e.g., a string with japanese characters), which changes the type of CUT_BUFFER0. It works fine for me with pterm 0.58-1 (I tried Japanese text copied from a UTF-8 pterm and from a EUC-JP kterm). Would you mind re-testing? Sure, no change, though: Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 59 error_code 8 request_code 18 minor_code 0 ii pterm 0.58-1 PuTTY terminal emulator xprop -root shows: CUT_BUFFER3(UTF8_STRING) = 0x73, 0x69, 0x70, 0x3a, 0x30, 0x38, 0x30, 0x30, 0x33, 0x33, 0x30, 0x31, 0x30, 0x30, 0x30, 0x40, 0x73, 0x63, 0x68, 0x6d, 0x6f, 0x72, 0x70, 0x2e, 0x64, 0x65 Are you sure kterm and/or pterm actually do set one of the cut buffers to non-STRING type in your tests? Also, it should be fairly trivial, for someone who knows the code, to fix it given the dump, without further testing. Actually, identifiying the bug is easy even without code knowledge: The only occurrences of XChangeProperty I could find is in unix/gtkwin.c:init_cutbuffers, and indeed it assumes that all cut buffers have type STRING. A BadMatch there should either be ignored (which is fine as the only reason for the changeproperty is making sure the cut buffer is alive) or the correct type should be used when appending (which is racy). -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295605: pterm doesn't start
On Sun, Feb 20, 2005 at 06:16:30PM +0100, Marc A. Lehmann wrote: On Sun, Feb 20, 2005 at 02:27:24PM +, Jacob Nevins [EMAIL PROTECTED] wrote: This sounds to me like it might be a problem with libgtk1.2 rather than putty. But it's clearly not font-related, as the badmatch is in response to a XChangeProperty, at least in the dump I made. (Clearly pterm starts for some people, so there must be something specific about your situation that's breaking it.) I investigated a bit more, and the problem seems to occur when another app stores a non-latin1 string in the cut buffer (e.g., a string with japanese characters), which changes the type of CUT_BUFFER0. It works fine for me with pterm 0.58-1 (I tried Japanese text copied from a UTF-8 pterm and from a EUC-JP kterm). Would you mind re-testing? Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295605: pterm doesn't start
This sounds to me like it might be a problem with libgtk1.2 rather than putty. See for instance http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=234994 which is correlated with use of TrueType fonts (although the error there appears to always be BadValue, rather than BadMatch). (Clearly pterm starts for some people, so there must be something specific about your situation that's breaking it.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295605: pterm doesn't start
On Sun, Feb 20, 2005 at 02:27:24PM +, Jacob Nevins [EMAIL PROTECTED] wrote: This sounds to me like it might be a problem with libgtk1.2 rather than putty. But it's clearly not font-related, as the badmatch is in response to a XChangeProperty, at least in the dump I made. (Clearly pterm starts for some people, so there must be something specific about your situation that's breaking it.) I investigated a bit more, and the problem seems to occur when another app stores a non-latin1 string in the cut buffer (e.g., a string with japanese characters), which changes the type of CUT_BUFFER0. This is unlikely to be a gtk+ problem as other gtk+ apps don't have this problem and start fine. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295605: pterm doesn't start
Package: pterm Version: 0.55-1.0.0.1.amd64 Severity: important pterm doesn't start (I originally thought this were a 64-bit problems, but I reproduced it on my 32-bit x86 box). When starting pterm, I get: fuji ~# pterm Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 59 error_code 8 request_code 18 minor_code 0 [Exit 1] I created a tcpdump of a connection http://data.plan9.de/pterm-error.pcap) which contains all x requests (ethereal can decode them quite nicely), from start to exit, which might help identifying what goes wrong. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (700, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11-rc2 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages pterm depends on: hi libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libglib1.2 1.2.10-9The GLib library of C routines ii libgtk1.21.2.10-17 The GIMP Toolkit set of widgets fo ii libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-10 X Window System miscellaneous exte ii libxi6 4.3.0.dfsg.1-10 X Window System Input extension li ii xlibs4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
