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