When memmove() Fails
news.realm.io
When memmove() Fails
1–5 of 5 posts
Re: When memmove() Fails
#2I went over the article a couple of times, but I cannot quite tell what the actual memmove bug is. Does this assert(ptr == array + 1) imply that the buggy memmove returns the wrong pointer?
Re: When memmove() Fails
#3I went over the article a couple of times, but I cannot quite tell what the actual memmove bug is. Does this assert(ptr == array + 1) imply that the buggy memmove returns the wrong pointer?
As the author of the article, I might be able to clarify a bit ;-). It is not absolutely clear to me what the bug is. It only appears on a few devices so it is not a trivial bug. It seems to be triggered by certain sizes and probably how the block is placed in memory. To answer your question: yes, the return value of memmove seems to be wrong in some cases. ChengYi He's analysis indicates that an ARM/Neon instruction is skipped which could explain the miscalculation. Why it skips the instruction (more precisely, why PC is not incremented correctly after returning from an exception) isn't clear to me or ChengYi He.
Re: When memmove() Fails
#4I went over the article a couple of times, but I cannot quite tell what the actual memmove bug is. Does this assert(ptr == array + 1) imply that the buggy memmove returns the wrong pointer?
As the author of the article, I might be able to clarify a bit ;-). It is not absolutely clear to me what the bug is. It only appears on a few devices so it is not a trivial bug. It seems to be triggered by certain sizes and probably how the block is placed in memory. To answer your question: yes, the return value of memmove seems to be wrong in some cases. ChengYi He's analysis indicates that an ARM/Neon instruction…
What exception(s) might happen in this context? It should be possible to examine the disassembly (or the code) of the relevant exception handler(s).
Re: When memmove() Fails
#5Earlier quoted context omitted.
As the author of the article, I might be able to clarify a bit ;-). It is not absolutely clear to me what the bug is. It only appears on a few devices so it is not a trivial bug. It seems to be triggered by certain sizes and probably how the block is placed in memory. To answer your question: yes, the return value of memmove seems to be wrong in some cases. ChengYi He's analysis indicates that an ARM/Neon instruction…
What exception(s) might happen in this context? It should be possible to examine the disassembly (or the code) of the relevant exception handler(s).
The exception is related to emulating NEON instructions. So we are talking about very low-level exceptions (or signal handling) - at kernel/C library level.
I am not sure if this exception is the cause. And even if you could examine the assembler code, you will not be able to fix it: the affected devices have reach end-of-life years ago, and vendors will not fix the bug :-( The only chance for a fix is that app developers implement a workaround.