New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Never finding streams #11
Comments
Expected behaviour: create stream once, find it 9 times. |
Hello again. We made some investigations - this appears to be a very interesting and subtle bug. The problem lies in the tcp_getkey returning different values for the same session and tuple when called from different places in the code. The culprits are sfhash_3words and sfhash functions from sfhash.c. Gcc inlines sfhash.c inside sfhash_3words, and apparently does some tricky instruction reordering. This results in aux variable from sfhash_3words being uninitialized when used in sfhash! gcc even warns about this at build-time (see below). We verified this by adding attribute ((noinline)) to the definition of sfhash function. This makes the result of tcp_getkey consistent and resolves our bug. The bug is also resolved if we use clang instead of gcc: SET (CMAKE_C_COMPILER "clang" ) We failed to understand whether the code itself is incorrect (i.e. contains undefined behavior) or the gcc makes some wrong assumptions about what can be inlined and reordered. GCC version is:
OS is:
Warnings during build:
|
Everything works well if either |
Removing _HIDDEN attribute from sfhash* function also resolves the bug |
Final thougths: |
I tried removing sfhash.c and replacing sfhash.h with version from kernel (https://gitorious.org/wive-rtnl-ralink-rt305x-routers-firmware/wive-rtnl-ralink-rt305x-routers-firmware/source/81de0c05c5046b0c73eb07e8c43b68579b6cbf48:linux-2.6.21.x/include/linux/sfhash.h) the bug is still there. I'm more and more inclined to think of a probable gcc bug O_O. |
First of all, thank you ghostmansd and ngo. 10.0.0.233:48515 -> 173.194.71.94:80 (nil) All goes well, using gcc version 4.7.2 (Debian 4.7.2-5) ...
Thank you both! |
Hi again, I've created a mailing list for libntoh development issues, if you want to join please, send me your email. The libntoh-dev mailing list is: libntoh-dev@safetybits.net |
Hi, |
Hi. The same for me (gentoo, gcc-4.9.2). Removing _HIDDEN helps. |
Hi, |
So, removed _HIDDEN attribute. Thank you all! |
During libntoh testing, it was shown that libntoh never actually finds a stream, but always creates a new one. Here is an example source file.
https://gist.github.com/ghostmansd/5cb5b6f41fe72e554696
The text was updated successfully, but these errors were encountered: