Date: Wed, 20 Jan 2016 18:36:53 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: FreeBSD Current <freebsd-current@FreeBSD.org> Subject: Re: environment corrupt; missing value for QT_IM_MO Message-ID: <569FB7A5.4070106@FreeBSD.org> In-Reply-To: <569E3713.1060601@FreeBSD.org> References: <5514E5B0.1030509@rawbw.com> <568B8291.50700@FreeBSD.org> <568B84DC.7080705@FreeBSD.org> <569E3713.1060601@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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=<optimized out>, lockstate=0x7fffffffdb68) at /usr/src/libexec/rtld-elf/rtld.c:2438 #5 0x000000080060407f in _rtld (sp=<optimized out>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?569FB7A5.4070106>