[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: x-www-browser for ultra5 ultra60



On Wed, 2009-03-25 at 04:58 +0000, Howard Eisenberger wrote:
> On 2009-03-25, Julien Cristau wrote:
> 
> >> Core was generated by `/usr/lib/iceweasel/firefox-bin -a iceweasel
> >> https://signin.ebay.ca/ws/eBayISAPI'.
> >> Program terminated with signal 10, Bus error.
> >>
> >> #0  0xf69bf6bc in der_TimeStringToTime (dst=0x115f574, string=<value
> >> optimized out>, generalized=2) at dertime.c:311
> >> #1  0xf69bf780 in DER_GeneralizedTimeToTime_Util (dst=0x115f574, time=<value
> >> optimized out>) at dertime.c:239
> >
> > dertime.c:311 seems to be:
> >     *dst = PR_ImplodeTime(&genTime);
> >
> > PR_ImplodeTime returns an int64.  Here dst is 0x115f574, which is not
> > aligned on a double-word boundary.  So that'd explain the SIGBUS.
> >
> > The backtrace you get doesn't go further?  It'd be nice to know what the
> > DER_GeneralizedTimeToTime_Util caller is...
> 
> I saved it this time. Not sure how much you need, but here is a bit more.
> 
> #0  0xf69bf6bc in der_TimeStringToTime (dst=0x115f574, string=<value
> optimized out>, generalized=2) at dertime.c:311
> #1  0xf69bf780 in DER_GeneralizedTimeToTime_Util (dst=0x115f574, time=<value
> optimized out>) at dertime.c:239
> #2  0xf6aa4f54 in pkix_pl_OcspResponse_VerifySignature (response=0x115f554,
> cert=0x1159b74, procParams=0x11437e4, pPassed=0xf2cea084,
> #pNBIOContext=0xf2cea078, plContext=0x1143150) at pkix_pl_ocspresponse.c:883
> #3  0xf6a5b610 in pkix_OcspChecker_Check (checkerObject=0x1148e8c,
> #cert=0x1159b74, procParams=0x11437e4, pNBIOContext=0xf2cea19c,
> #pResultCode=0xf2cea190, plContext=0x1143150) at pkix_ocspchecker.c:266
> #4  0xf6a72bb4 in pkix_CheckChain (certs=0x115ad44, numCerts=2,
> #checkers=0x115ad0c, revCheckers=0x115f0e4, removeCheckedExtOIDs=0x115e8b4,
> #procParams=0x11437e4, pCertCheckedIndex=0x11588f4, 
>     pCheckerIndex=0x11588f8, pRevChecking=0x115891c, pReasonCode=0x1158908,
> #pNBIOContext=0xf2cea284, pFinalSubjPubKey=0xf2cea290,
> pPolicyTree=0xf2cea28c, pVerifyTree=0x0, plContext=0x1143150)
>     at pkix_validate.c:354
> #5  0xf6a76284 in pkix_Build_ValidateEntireChain (state=0x11588d4,
> anchor=0x11432ec, pNBIOContext=0xf2cea45c, pValResult=0xf2cea488,
> #verifyNode=0x1159184, plContext=0x1143150) at pkix_build.c:1619
> #6  0xf6a7a734 in pkix_BuildForwardDepthFirstSearch
> #(pNBIOContext=0xf2cea654, state=0x11588d4, pValResult=0xf2cea64c,
> #plContext=0x1143150) at pkix_build.c:3052

I've spent some time looking at this, and I'm a bit worried about
PKIX_PL_Object_Alloc.  Specifically, sizeof(PKIX_PL_Object) seems to be
28 on 32bit, and __alignof__(PKIX_PL_Object) is 4.  PKIX_PL_Object_Alloc
goes to allocate some space for one PKIX_PL_Object + the size it was
asked for, and then goes and returns object + 1.  Thus, if
PKIX_PL_Malloc gives it a 8 byte aligned pointer, PKIX_PL_Object_Alloc
will return an unaligned address to its caller.  PKIX_PL_OcspResponse's
size is 56, and it has to be 8 byte aligned on sparc, so it's possible
this is the problem here.

Mike, any idea?

Cheers,
Julien


Reply to: