chTestAddX() fails during test suite Topic is solved

Report here problems in any of ChibiOS components. This forum is NOT for support.
Thargon
Posts: 86
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 6 times
Been thanked: 12 times

chTestAddX() fails during test suite  Topic is solved

Postby Thargon » Wed Sep 05, 2018 4:49 pm

Hi,

when I run the default test suite by calling 'test_execute()' the kernel panics, stating that the assertion in 'chTimeAddX()' has failed. In my configuration CH_CFG_ST_RESOLUTION is set to 16 and CH_CFG_INTERVALS_SIZE is set to 32. If you need any further information, please ask ;)

Furthermore, I've found a type in the test suite: at test/rt/source/test/re_test_sequence_001.c : 214 it says "CH_CFG_USE_CONDVARS_TIMEO:" with a missing 'T' ;)

Best regards,
Thomas

User avatar
Giovanni
Site Admin
Posts: 11307
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 412 times
Been thanked: 342 times
Contact:

Re: chTestAddX() fails during test suite

Postby Giovanni » Thu Sep 06, 2018 2:02 pm

Hi,

I am unable to replicate, what version are you using? also, post your chconf.h, just in case.

Giovanni

Thargon
Posts: 86
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 6 times
Been thanked: 12 times

Re: chTestAddX() fails during test suite

Postby Thargon » Thu Sep 06, 2018 2:18 pm

Hi,

have a look at our repository: https://opensource.cit-ec.de/projects/amiro-os/repository/revisions/master/show/modules
There is a chconf.h for each module (in the subfolders), but each one includes the aos_chconf.h file, where very most settings are located. I hope the files are well enough organized so you can find everything you need easily.

I just noticed that there are issues with the PowerManagement module, which hosts a STM32F405, but the other two modules (STM32F103) both fail. I guess it has something to do with the 16 bit timers and thus 16 bit wide systime_t?!

Thanks for the help!
- Thomas

User avatar
Giovanni
Site Admin
Posts: 11307
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 412 times
Been thanked: 342 times
Contact:

Re: chTestAddX() fails during test suite

Postby Giovanni » Wed Sep 26, 2018 9:28 am

Hi,

The only way to trigger this is to use high frequencies and a 16 bits timer, the behavior of chTimeAddX() is correct, the assertion notifies you that you are trying to add a value that is greater than systime_t maximum value.

Giovanni

Thargon
Posts: 86
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 6 times
Been thanked: 12 times

Re: chTestAddX() fails during test suite

Postby Thargon » Wed Sep 26, 2018 10:29 am

Hi,

that is true in my case as I use a 16 bit timer but set a frequency of 1MHz. I didn't say that the chTimeAddX() function is broken, though, but it seems the default kernel test suite is.
In principle there should be no issue with my configuration as long as you don't try to use values greater than systime_t maximum, just as you said. The test suite hence should check for such edge cases and react accordingly.
In case my configuration is in fact illegal or not (officially) supported by ChibiOS, that should actually be checked in chchecks.h, not by the kernel test suite.

- Thomas

User avatar
Giovanni
Site Admin
Posts: 11307
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 412 times
Been thanked: 342 times
Contact:

Re: chTestAddX() fails during test suite

Postby Giovanni » Wed Sep 26, 2018 10:46 am

The configuration is legal, it is the test suite that cannot cope with it.

Giovanni

Thargon
Posts: 86
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 6 times
Been thanked: 12 times

Re: chTestAddX() fails during test suite

Postby Thargon » Mon Oct 08, 2018 5:04 pm

Hi,

I've had another look at the issue and found a solution, which I hope will satisfy everyone. I'll start with a brief argument, followed by the code and a more detailed explanation.

Looking at the function chTimeAddX(), the idea is to add some sysinterval_t value to a given systime_t and get the result again as systime_t. As with any summation, there is the possibility of overflows to occur. Especially if the sysinterval_t is wider than systime_t, this risk is exceptionally high. But since systime_t is expected to overflow over time anyway, the calculation of chTimeAddX() may overflow just as well. In this case, however, the information how often the original systime_t value revolved can not be obtained trivially. This again can be considered as legitimate limitation, though, as long as CH_CFG_ST_TIMEDELTA <= TIME_MAX_SYSTIME holds, because the system is expected to stay within the specified jitter in any situation.

These considerations in mind, I enhanced the chTimeAddx() function as follows:

Code: Select all

static inline systime_t chTimeAddX(systime_t systime, sysinterval_t interval) {

#if CH_CFG_ST_RESOLUTION < CH_CFG_INTERVALS_SIZE
  return  systime + (systime_t)(interval % ((sysinterval_t)1 << CH_CFG_ST_RESOLUTION));
#else
  return systime + interval;
#endif
}
First, I distinguish the trivial case (after #else), where systime_t can hold any interval value and thus will overflow no more than once.
For the other case, I "subtract" (modulo operator) a multiple of full systime_t revolutions, so that the remaining rest of interval will lead to one or none overflow of systime as it fits into the systime_t type. In order to prevent any side effects due to the wider sysinterval_t type, this value is casted to the correct systime_t type and added to the specified systime. Finally, the returned number is the correct systime_t value after an arbitrary number of overflows (which is unknown, though).

pro:
In contrast to the original implementation, any value of interval can be given to the function.
contra:
With the original implementation the result of chTimeAddX() would never be equal to the systime argument, which is possible now and might cause issues (although it should not, imo).

For my case, the kernel test suite does not panic anymore and everything else seems to be unaffected.
Let me know what you think about this =)
- Thomas


Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 1 guest