You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, when using ne10_add_float_neon sometimes SIGSEGV is thrown.
It happens when one of the source vectors is ended at a memory segment end.
In the code below (line 100 in NE10_add_neon.s) the values to be added are loaded before end check:
@ load the next set of values
vld1.32 {q0}, [r1]!
vld1.32 {q1}, [r2]!
bgt .L_mainloop_float @ loop if r3 > 0, if we have at least another 4 floats
This causes an address beyond the end to be accessed which may cause a SIGSEGV when no memory is present there.
This logic (loading values before checking end of loop) is presented also in other NE10 modules.
Has anybody encountered this problem?
Maybe there is a fix?
Thanks,
Ury.
The text was updated successfully, but these errors were encountered:
Hey, Ury. I can't say I've run into this problem myself, but it sure does look like a bug. For the time being, you could always just move the load instructions to always occur before the corresponding add (removing the initial loads in .L_check_mainloop_float). While this doesn't make for a particularly sophisticated "optimised" implementation, it's relatively close to the original code (which, in itself, isn't particularly clever) and should actually function correctly.
Alternatively, you could always pad your data structures so that the additional load is never a problem. This is a bit of a sad solution though. Hopefully we can get this fixed in the repository some time soon to address the issue properly at its source.
Hi joesavege, thanks for your reply. I can modify (and did) the code for this specific routine, but this problem is present also in other routines, possibly including fft, and I do not have the knowledge to modify all. Regarding padding data structure, this is my current (unhappy) workaround.
It would definitely be good to get these kinds of sloppy issues resolved wherever they are present within Ne10, so thanks for reporting this. The automated tests frequently use array guards to check for out-of-bounds writes, but perhaps it would also be worth adding checks for out-of-bounds reads.
Hi, when using
ne10_add_float_neon
sometimes SIGSEGV is thrown.It happens when one of the source vectors is ended at a memory segment end.
In the code below (line 100 in NE10_add_neon.s) the values to be added are loaded before end check:
This causes an address beyond the end to be accessed which may cause a SIGSEGV when no memory is present there.
This logic (loading values before checking end of loop) is presented also in other NE10 modules.
Has anybody encountered this problem?
Maybe there is a fix?
Thanks,
Ury.
The text was updated successfully, but these errors were encountered: