[webkit-dev] random seg fault on MIPS platform

[x yz]

Zoltan,
I appreciate very much your comments, that's sth in my mind but no clue, when 1st/2nd run ok and 3rd fail, I also doubt SMP. The case just as you mentioned.
But, what's the solution? why X86 gcc version has no such problem?
rgds
joe


--- On Sat, 5/9/09, Zoltan Herczeg <zherczeg at inf.u-szeged.hu> wrote:

> From: Zoltan Herczeg <zherczeg at inf.u-szeged.hu>
> Subject: Re: [webkit-dev] random seg fault on MIPS platform
> To: lastguy at yahoo.com
> Cc: webkit-dev at lists.webkit.org
> Date: Saturday, May 9, 2009, 2:11 AM
> 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
> >