search

EarthScope / ringserver

Apache License 2.0
31 stars 17 forks source link

RingStream entries handled incorrectly due to a C undefined behaviour #29

Closed yensoon2 closed 2 years ago

yensoon2 commented 3 years ago

The int64_t hval = (int64_t)0xcbf29ce484222325ULL; C declaration results in a C undefined behaviour on my platform, because 0xcbf29ce484222325ULL is greater than INT64_MAX on my platform.

This C undefined behaviour causes FVNhash64("NN_SSSSS_LL_CCC/MSEED") to erroneously return -9223372036854775740 (i.e. 0x8000000000000044) rather than 18422540039308572745 (i.e. 0xffaa028f1765f849) on my platform, which prevents ringserver from handling RingStream entries correctly on my platform.

This pull request fixes this C undefined behaviour, so can you please accept this pull request?

Thank you very much for your efforts!

chad-earthscope commented 3 years ago

Thanks for the PR @yensoon2. I'll have not yet reviewed this but your changes look reasonable and appropriate.

Out of curiosity, which platform (compiler, OS,...) is giving you an error with the unfixed code?

Thanks for the contribution!

yensoon2 commented 3 years ago

Good morning @chad-iris,

I can (often) reproduce this issue on CentOS 7.0 x86-64, and GCC with the “-Wall” and “-O2” (and probably other) compilation flags. I believe that, without the “-O2” compilation flag, this issue becomes (mostly) unreproducible.

Thank you very much for writing ringserver!

BradAvenson commented 2 years ago

Thanks to @yensoon2 , this fixed a bug I was seeing in an Arm based Linux build.

Guillaume-Savaton-ESEO commented 2 years ago

Applying this patch to the source tree at tag v2020.075 seems to cause alignment traps on my platform. I don't see a reason why changing int64_t to uint64_t would produce this behavior.

I am running ringserver on a Yocto-based embedded system (Linux 4.19, armv7l, 32-bit).

yensoon2 commented 2 years ago

I don't see a reason why changing int64_t to uint64_t would produce this behavior.

I also don’t see why changing int64_t to uint64_t would be the cause of any unaligned memory accesses.

If there are any unaligned memory accesses in ringserver, then you can imagine that these unaligned memory accesses must have been present since before this pull request.

Since we are talking about unaligned memory accesses, did you know that libslink v2.7.x (also) suffers from unaligned memory accesses? Although ringserver does not link against libslink, you can imagine that, perhaps, some of libslink’s unaligned memory accesses might have been accidentally and unknowingly replicated in ringserver’s source code …

chad-earthscope commented 2 years ago

@yensoon2 I think I've disconnected this PR when I renamed the master branch to main. If you still have a repository with this in it could you re-attached/create the PR? I think I can see the changes in the first comment, if they are that simple I can apply them myself, but I don't want to miss any of your work being included.