[webkit-dev] random seg fault on MIPS platform

[Zoltan Herczeg]

Hi,

I don't know anything about MIPS architecture (only x86, ARM and PowerPC),
but we have experienced similar things on ARM, until we have found the
gcc's __clear_cache(void* begin, void* end) function. It calls a kernel
utility, which flushes out the data cache (some mrc instructions can only
executed on kernel level).

1) The program always fails without gdb, because the instructions are not
flushed out to the SDRAM. Instruction cache always loads the instructions
directly form the SDRAM.
2) With gdb, it is sometimes work, sometimes not. GDB itself allocates a
big amount of memory, so the cache is partly flushed out when it stops at
a breakpoint. Note that, the disassembly shows the content of the data
cache, not the instruction cache.

Zoltan

> Hi,
>>50% of time when I use gdb then arith functions works. it may fail at
>> 1st, or 3rd try, and 100% fail w/o gdb. I just use jsc to do sth like
>> 5%2, 5*3, etc.
>
> It is with in call of ctiTrampoline(code, registerFile, callFrame,
> jexception, pptr, globalData), jit code executed and may be in last line
> of op_mod() when it tried to convert result, gdb simply shows segment
> fault, or PC stops at an non-coded area, w/o gdb it says invalid
> instruction. It may be in JITcell,h in
> ALWAYS_INLINE double JSValuePtr::toNumber(ExecState* exec) const
>     {
>         return JSImmediate::isImmediate(asValue()) ?
> JSImmediate::toDouble(asValue()) : asCell()->toNumber(exec);
>     }
> due to exec pointer wrong.
>
> if I continue to use same arithmatic function the generated jit code won't
> call op_mod() unless it is the 1st time, I think it is because jit code is
> already there. If another thread handles the real operation and not sync'd
> then it may be the case. Note I use BCM chip with two CPUs - BCM
> customized SMP and BCM Linux.
>
> when it works, before and after ctiTrampoline() the stack is balanced and
> registers are ok. where is the jit stack and how to check its balance?
>
> when it fails, stacks shows we are nearby jit code - the code w/o calling
> OP_mod() CPP function as it fails at 3rd try. But PC points to a data
> structure:
> any comments? thanks a lot!!
> rgds
> joe
>
> //////////////
> (gdb) c
> Continuing.
>
> Program received signal SIGILL, Illegal instruction.
> 0x2aacd000 in ?? ()
> (gdb) where
> #0  0x2aacd000 in ?? ()
> warning: GDB can't find the start of the function at 0x2aacd000.
> ...
> #1  0x2aacd000 in ?? ()
> warning: GDB can't find the start of the function at 0x2aaccfff.
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) backtrace
> #0  0x2aacd000 in ?? ()
> #1  0x2aacd000 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) p/x $sp
> $1 = 0x7fa439d8
> (gdb) p/x $pc
> $2 = 0x2aacd000
> (gdb) p/x $t9
> $3 = 0x2aac9588
> (gdb) x/10i $t9 = jit code, no actual call to op_mod() cpp function
> 0x2aac9588:	sw	ra,-40(s5)
> 0x2aac958c:	lui	s7,0x0
> 0x2aac9590:	ori	s7,s7,0xa
> 0x2aac9594:	sw	s7,0(s5)
> 0x2aac9598:	lui	s7,0x0
> 0x2aac959c:	ori	s7,s7,0xa
> 0x2aac95a0:	sw	s7,8(s5)
> 0x2aac95a4:	lui	v0,0x0
> 0x2aac95a8:	ori	v0,v0,0xa
> 0x2aac95ac:	sw	v0,32(s5)
> (gdb)
> 0x2aac95b0:	lui	v0,0xffff
> 0x2aac95b4:	ori	v0,v0,0xffff
> 0x2aac95b8:	sw	v0,32(s5)
> 0x2aac95bc:	lw	at,-40(s5)
> 0x2aac95c0:	nop
> 0x2aac95c4:	addiu	sp,sp,-4
> 0x2aac95c8:	sw	at,0(sp)
> 0x2aac95cc:	lw	ra,0(sp)
> 0x2aac95d0:	addiu	sp,sp,4
> 0x2aac95d4:	jr	ra
> 0x2aac95d8:	nop
> (gdb) p/x $ra //$ra = tobe returned addr after ctiTrampoline(), correct
> $4 = 0x676d64
> (gdb) x/10i $pc //sth not patched well??
> 0x2aacd000:	0x4941444a
> 0x2aacd004:	jalx	0x21a5a881
> 0x2aacd008:	j	0x2984c8b4
> 0x2aacd00c:	andi	at,s3,0x3134
> 0x2aacd010:	0x6d202c30
> 0x2aacd014:	0x7a69735f
> 0x2aacd018:	0x66373d65
> 0x2aacd01c:	xori	s3,t1,0x3461
> 0x2aacd020:	ori	t0,t1,0x3864
> 0x2aacd024:	addi	t4,at,10544
> (gdb)
> 0x2aacd028:	jalx	0x25b185d9
> 0x2aacd02c:	j	0x28c0f594
> 0x2aacd030:	andi	s0,at,0x3030
> 0x2aacd034:	0x720a0a38
> 0x2aacd038:	0x64496765
> 0x2aacd03c:	j	0x28e0c4f4
> 0x2aacd040:	nop
> 0x2aacd044:	nop
> 0x2aacd048:	nop
> 0x2aacd04c:	nop
>
> 0x2aacd028:	jalx	0x25b185d9
> 0x2aacd02c:	j	0x28c0f594
> 0x2aacd030:	andi	s0,at,0x3030
> 0x2aacd034:	0x720a0a38
> 0x2aacd038:	0x64496765
> 0x2aacd03c:	j	0x28e0c4f4
> 0x2aacd040:	nop
>
>
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>