-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
tests/thread_float: improve and add script #16901
Conversation
Could you also provide a |
991915a
to
2b50205
Compare
Done. I'm not sure if it makes sense to also match the output after the period (since that will greatly depend on the precision of the (soft) FPU and the printf() implementation). In any case, I'm not a decent Python programmer anyway, so I better not try to extend the test and leave this to someone more qualified, if this is considered to be beneficial. |
Please remember, that periods have special meaning in regular expressions ;-). |
Btw.: I think I just realized what the test might be about: Whether the FPU context is properly saved and restored on context switching. Which apparently is not the case for my STM32F767ZI, the threads end up with a (slightly) different result each time. It is a pity that there is no README or anything pointing out the reasoning of the test. |
7283c3c
to
56fbe40
Compare
I think I'm now happy with the test. May I squash? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will provide suggestions for that.
Here we go.
5ca22e2
to
eb87273
Compare
5ecd434
to
b63b44e
Compare
The last CI run shows the expected failure on I assume blacklisting native for now to get the test in is fine? To he honest, I'm not sure how to fix the issue on native. I think it is exposing a bug in glibc. But since the makecontext() / swapcontext() is obsolete since quite some time, I guess the enthusiasm to fix them is limited. |
b63b44e
to
5e9e3fd
Compare
All green now (after disabling the test run for |
I'm OK with merging as is, but if there is a possible bug then I think an issue should be opened as well. |
I cannot reproduce the issue with the current riotbuild. Maybe the issue has been solved by switching to the newest Ubuntu TLS release? I'll revert the blacklisting. Let's see, what happens. |
5e9e3fd
to
57b35c8
Compare
All green with testing on |
For me it fails locally still... can we be sure the last run was not just lucky? |
Not really. Let me disable the test again. But this time, we skip compile tests :-) I'll open the issue. |
- Perform the same computation over and over again. If the results differ, context switches have an impact on the calculation (e.g. when the FPU internally uses more bits than a float, but that bits are not saved / restored on context switch) - Give the three threads the names "t1", "t2", and "t3" and print them on console, instead of the process ID. This makes interpretation of the output easier, as the process IDs depend e.g. on whether a given platforms requires an idle thread or not. - Do not use the thread ID in the calculation, but the number at the end of the thread name. This will result in the number printed only depending on the precision of the (software) FPU and the printf() implementation, and not on which threads are created in which order (including the idle thread) - Add a script to support running `make test` Update tests/thread_float/tests/01-run.py Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr>
57b35c8
to
f62b662
Compare
Issue opened at: #17170 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK!, I agree with the current status where a potentially flaky native test is blacklisted.
Thanks for the rework @maribu! |
Contribution description
make test
Testing procedure
The test should still work, but now have easier to read output.
Issues/PRs references
#16896