From owner-freebsd-current@freebsd.org Wed Jan 20 16:38:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A977FA8AD04 for ; Wed, 20 Jan 2016 16:38:00 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DCFC01D70 for ; Wed, 20 Jan 2016 16:37:59 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA05937 for ; Wed, 20 Jan 2016 18:37:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1aLvlW-0006HX-Gz for freebsd-current@FreeBSD.org; Wed, 20 Jan 2016 18:37:50 +0200 Subject: Re: environment corrupt; missing value for QT_IM_MO To: FreeBSD Current References: <5514E5B0.1030509@rawbw.com> <568B8291.50700@FreeBSD.org> <568B84DC.7080705@FreeBSD.org> <569E3713.1060601@FreeBSD.org> From: Andriy Gapon X-Enigmail-Draft-Status: N1110 Message-ID: <569FB7A5.4070106@FreeBSD.org> Date: Wed, 20 Jan 2016 18:36:53 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <569E3713.1060601@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 16:38:00 -0000 On 19/01/2016 15:16, Andriy Gapon wrote: > So, it's "QT_IM_MODULE=xim" with 4 bytes (corresponding to "DULE") replaced with > zeroes. This is 100% reproducible in my current environment, so it could be a > deterministic write to a wrong offset. Okay, I've debugged and fixed the problem, but I do not have any exciting discoveries. just another lesson that problems with an environment (in the general sense of that word) could manifest themselves in very strange ways. In the following debugging session it's LSCOLORS variable that was corrupted: (gdb) p environ[81] $3 = 0x7fffffffef32 "LSCOLORS" (gdb) p environ[82] $4 = 0x0 (gdb) x/s 0x7fffffffef32 0x7fffffffef32: "LSCOLORS" (gdb) x/s 0x7fffffffef3a 0x7fffffffef3a: "" (gdb) x/s 0x7fffffffef3b 0x7fffffffef3b: "" (gdb) x/s 0x7fffffffef3c 0x7fffffffef3c: "" (gdb) x/s 0x7fffffffef3d 0x7fffffffef3d: "" (gdb) x/s 0x7fffffffef3e 0x7fffffffef3e: "xcxdxbxegedabagacad" (gdb) watch -l *(int *)0x7fffffffef3a Hardware watchpoint 2: -location *(int *)0x7fffffffef3a Old value = 1719158077 New value = 0 OPENSSL_ia32_cpuid () at /usr/src/secure/lib/libcrypto/amd64/x86_64cpuid.S:45 45 movl %eax,%r11d (gdb) p/x 1719158077 $7 = 0x6678453d (gdb) bt #0 OPENSSL_ia32_cpuid () at /usr/src/secure/lib/libcrypto/amd64/x86_64cpuid.S:45 #1 0x00000008160e5b1d in OPENSSL_cpuid_setup () at /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/cryptlib.c:699 #2 0x0000000815fe7dde in _init () from /lib/libcrypto.so.7 #3 0x00007fffffffdae0 in ?? () #4 0x00000008006049c8 in objlist_call_init (list=, lockstate=0x7fffffffdb68) at /usr/src/libexec/rtld-elf/rtld.c:2438 #5 0x000000080060407f in _rtld (sp=, exit_proc=0x7fffffffe130, objp=0x7fffffffe138) at /usr/src/libexec/rtld-elf/rtld.c:665 #6 0x0000000800602439 in .rtld_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:39 (kgdb) list 40 movq %rbx,%r8 41 42 xorl %eax,%eax 43 movl %eax,8(%rdi) 44 cpuid 45 movl %eax,%r11d 46 47 xorl %eax,%eax 48 cmpl $1970169159,%ebx 49 setne %al (kgdb) p/x $rdi $11 = 0x7fffffffef32 It did not make sense to me that libcrypto would have such a bug and then I noticed that libcrypto.so.7 was involved. The current version is libcrypto.so.8, but I have forgotten to run make delete-old-libs, so I had both installed. And it turned out that libreoffice executable was linked to both because one of libraries, libtspi.so.1 from trousers-tddl-0.3.10_7, hadn't been updated since libcrypto.so.8 was introduced. -- Andriy Gapon