Re: [fluid-dev] glib crash

[Element Green]

On Wed, Aug 21, 2013 at 7:11 AM, address@hidden <address@hidden> wrote:

Well,

remember that the core dump was from a Mac system on which glib crashes. The same app does not crash on most systems, including mine.

I just ran the app on gdb on my system, and disassembled the same function (before running the program). This showed to the same instructions as in the core dump. And this does not crash on my machine…

0x039894aa <thread_memory_from_self+169>: jne    0x398958b <thread_memory_from_self+394>

0x039894b0 <thread_memory_from_self+175>: mov    0xa41b5(%ebx),%eax

0x039894b6 <thread_memory_from_self+181>: mov    %eax,0xa479d(%ebx)

0x039894bc <thread_memory_from_self+187>: lds    (bad),%edi

0x039894bd <thread_memory_from_self+188>: sti    

0x039894be <thread_memory_from_self+189>: adc    %al,0xa41ad(%ebx)

0x039894c4 <thread_memory_from_self+195>: lds    (bad),%edi

0x039894c5 <thread_memory_from_self+196>: sti    

0x039894c6 <thread_memory_from_self+197>: adc    %eax,0xa4795(%ebx)

0x039894cc <thread_memory_from_self+203>: lds    (bad),%edi

0x039894cd <thread_memory_from_self+204>: sti    

0x039894ce <thread_memory_from_self+205>: adc    %al,0xa41a5(%ebx)

0x039894d4 <thread_memory_from_self+211>: lds    (bad),%edi

I ran the program on my machine, and stepped through the thread_memory_from_self function. The "faulty" lds instructions do get executed…

1: x/i $pc  0x34894a5 <thread_memory_from_self+164>: lea    -0x1(%eax),%ecx

(gdb) 

0x034894a8 in thread_memory_from_self ()

1: x/i $pc  0x34894a8 <thread_memory_from_self+167>: test   %ecx,%eax

(gdb) 

0x034894aa in thread_memory_from_self ()

1: x/i $pc  0x34894aa <thread_memory_from_self+169>: jne    0x348958b <thread_memory_from_self+394>

(gdb) 

0x034894b0 in thread_memory_from_self ()

1: x/i $pc  0x34894b0 <thread_memory_from_self+175>: mov    0xa41b5(%ebx),%eax

(gdb) 

0x034894b6 in thread_memory_from_self ()

1: x/i $pc  0x34894b6 <thread_memory_from_self+181>: mov    %eax,0xa479d(%ebx)

(gdb) 

0x034894bc in thread_memory_from_self ()

1: x/i $pc  0x34894bc <thread_memory_from_self+187>: lds    (bad),%edi

(gdb) 

0x034894c4 in thread_memory_from_self ()

1: x/i $pc  0x34894c4 <thread_memory_from_self+195>: lds    (bad),%edi

(gdb) 

0x034894cc in thread_memory_from_self ()

1: x/i $pc  0x34894cc <thread_memory_from_self+203>: lds    (bad),%edi

(gdb) 

0x034894d4 in thread_memory_from_self ()

1: x/i $pc  0x34894d4 <thread_memory_from_self+211>: lds    (bad),%edi

(gdb) 

0x034894dc in thread_memory_from_self ()

1: x/i $pc  0x34894dc <thread_memory_from_self+219>: lea    0x5a55e(%ebx),%eax

(gdb) 

0x034894e2 in thread_memory_from_self ()

1: x/i $pc  0x34894e2 <thread_memory_from_self+225>: mov    %eax,(%esp)

(gdb) 

0x034894e5 in thread_memory_from_self ()

1: x/i $pc  0x34894e5 <thread_memory_from_self+228>: call   0x34d1a0c <dyld_stub_getenv>

(gdb) 

0x034894ea in thread_memory_from_self ()

1: x/i $pc  0x34894ea <thread_memory_from_self+233>: test   %eax,%eax

Am I thinking right ?

Thank you

Its interesting that the disassembly shows the offending instruction as being a single byte in length (the sti and adc instructions come afterwards), but when you executed it, it shows that EIP goes from 187 to 195 (8 bytes), so the sti and adc opcodes are actually part of the instruction at 187.  Time to look at the actual machine code, to manually decode the instruction.  You should be able to do that like:

x/8bx 0x039894bc

Looking at the disassembly prior to that instruction, it appears to be real source code, as it logically makes sense (registers are tested for values after being loaded, etc).  Something weird is going on at the offending instruction though.

Do you know any details about the differences in the CPUs?  Maybe this is a 64 bit related issue?  Although as far as I know most CPUs should be 64 bit capable these days.

Element