kneth

Joined 12 years ago

Karma
293
Submissions
55
Member since
Jun 13
Chemist by education, geek by Nature [ my public key: https://keybase.io/kneth; my proof: https://keybase.io/kneth/sigs/GLbZtg2dN3w1hP-K1iIJqVXhtHFDboE2pyAaY_L4YrM ]
View on Hacker News

Recent submissions

Comment · 1 year ago
CrateDB (a distributed database for real-time analytics) is introducing its MCP server
Comment · 9 years ago
Well, China has more than four times as many citizens.
Comment · 9 years ago
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.

Comment · 9 years ago
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.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton