On Tue, 05 Aug 2014 14:24:48 +0100 Marc Zyngier <marc.zyng...@arm.com>
wrote:
> An update on this: the armel architecture is *not* affected, and this
> seems to be an armhf specific issue (tested by running an armel VM on
> the same hardware).
>
> I'd appreciate if anyone knowledgeable about this could have a look.
>
Hi Marc,
I had the same issue on my Chromebook running Jessie and 3.8.11 Chrome
kernel.
I did some digging around.
>From what I can see we have:
NS_IMETHODIMP
History::AddDownload(nsIURI* aSource, nsIURI* aReferrer,
PRTime aStartTime, nsIURI* aDestination)
Argument 0 is the "this" pointer and is 32-bit.
Arguments 1, 2 and 4 are 32 bit pointers.
Argument 3 (aStartTime) is 64 bit.
The function (and gdb) expects arguments 0, 1 and 2 to be in r0, r1, r2
and arguments 3 and 4 to be on the stack.
When I stepped through the NS_InvokeByIndex logic:
I saw arguments 0, 1, 2 and 4 in registers and
only argument 3 to be in the stack.
This then caused aDestination to be invalid and hence the crash.
I adjusted the logic of "copy_dword" in
xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp
such that "iregs_args" is set to "end" when we can't fit the 64-bit type in
the registers.
This appears to have fixed the file download problem for me, but obviously
needs more testing!
Cheers,
--
Steve
