Re: environment corrupt; missing value for QT_IM_MO

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