Closed Ju1He1 closed 7 months ago
Thanks for reporting this bug @Ju1He1! I'll take a look and make sure to post back the next steps. For now - I will be trying to duplicate this issue.
Oddly enough the BitScanReverse (line 5155 of your second image) should handle the instantiation of uxTopPriority
.
I did some digging. _BitScanReverse searches for the MSB. However uxTopPriority is left initialised. This will return some random MSB. Also _BitScanReverse() seams to return a boolean in case everything worked
I did the following changes
UBaseType_t uxTopPriority = 0;
BOOLEAN bRes = _BitScanReverse((DWORD*)&(uxTopPriority), (uxTopReadyPriority));
configASSERT(TRUE == bRes); //is there a better way to handle errors?
with these changes it works again. IMHO leaving variables uninitialized is pretty dangerous, we should init all variables to some error value by default. @kstribrnAmzn pls check if you can adopt these changes to your main branch :)
However uxTopPriority is left initialised.
I'm assuming you meant uninitialized there since this goes with your solution. This is interesting as _BitScanReverse() is supposed to set the value of uxTopPriority
to the index of the most significant bit set. In your case, this should have been bit 5 which would correspond to your example task priority.
This may be due to the version of VS that you're using. Our demo doesn't use the full VS setup but instead a stripped down version of MSBuild.
I've asked @chinglee-iot to duplicate this issue as he has a windows machine setup.
Hey @kstribrnAmzn : I agree this is a strange behaviour. Not sure if this is releated to the VS version though. This crash is 100% reproducible in debug builds. In release builds it occurs some times. This is because in the debug build the stack in initialised with 0xccccccc (i.e. a very high number which is likely to trigger an index out of bounds error). I do not know what the value of the stack is in release builds. =>for your tests please run debug builds :)
@Ju1He1
It looks like this issue is a data type problem.
From your screen share, UBaseType_t
is defined as 8 bytes data type while _BitScanReverse
takes a 4 bytes data type pointer to return index. This cause the problem that only the first 4 bytes are updated with index the second 4 bytes are filled with 0xCCCCCCCC in debug mode.
uxTopPriority = 14,757,395,255,531,667,461 => 0xCCCCCCCC00000005
In the implementation, UBaseType_t
is 4 bytes long with 32-bits compiler and is 8 bytes long with 64-bits compiler. portGET_HIGHEST_PRIORITY
is implemented differently with 64-bits compiler to consider in the size of UBaseType_t
.
It looks like UBaseType_t
is defined as 8 bytes data type but compiled with 32-bits compiler. Can you help to check the following information in your environment?
UbaseType_t
definitionportGET_HIGHEST_PRIORITY
implementation is usedUsually, they are controlled by MSVC predefined macro _M_X64
. Reference the following link.
Hey @chinglee-iot Thx for your answer
The latest release https://github.com/FreeRTOS/FreeRTOS-Kernel/releases/tag/V11.0.1 does not provide multiple implementations of portGET_HIGHEST_PRIORITY (). However Ubasetype_T is defined as typedef unsigned long long UBaseType_t;
(i.e. 64 bit).
When I replace the portGET_HIGHEST_PRIORITY() in the current release with the new version from the main branch it works :)
=> so could you create a new release to fix this issue?
The PR to supporting building for x64 in MSVC is merged after v11.0.1 is released. This fix will be included in the next release. Thank you for creating this issue.
can you make a gues when a next release will be created? Are we talking about a weeks or several months?
I will propose a new release to the team, but I can't guess the creation time. At the same time, we can consider the following methods to unblock your development:
This PR will be closed due to the fix is already merged in the main branch. Thanks for creating this issue again.
Describe the bug Hey guys, we upgraded to the latest FreeRTOS release. Unfortunately, when running the MSVC Simulation in latest VS 2022 we are running into a access violation after calling vTaskStartScheduler().
After expanding the macro it is clear that
uxTopPriority
has an undefined value which causespxReadyTasksLists[uxTopPriority]
to crash in tasks.c.Unexpanded:
Expanded
Target latest MSVC 17 Simulation
Host
To Reproduce Run
Expected behavior The application should not crash :D
Screenshots See above
Additional context I have taken the latest config file from the Windows Simulator. Not sure if this is relevant
Add any other context about the problem here. see above
Does anybody else has this issue?