Inspector C bitfields MSVC 64-bit debug build reports false positives

[Hill__Stephen]

The following code produces false uninitialized memory access error, on line 14, in Inspector 2023.0 when used on a 64-bit debug build of MSVS2019 or MSVS2017:

typedef unsigned char U8;
typedef struct
{
    U8  SN_H : 4;  /* byte 1 */
    U8  R : 3;
    U8  DC : 1;
    U8  SN_L;    /* byte 2 */
} tNrPdcpPduHdr_Sn12;

int main(void)
{
    U8 DC = 1;
    tNrPdcpPduHdr_Sn12* pHdr = (tNrPdcpPduHdr_Sn12*)malloc(8);
    pHdr->DC = DC;
    pHdr->R = 0;
    free(pHdr);
    return 0;
}

If the assignment of ->DC is switched with ->R, then it passes. Seems to be related to use of literal.

If any optimization is enabled it passes.

If instead built with GCC under Debian it passes.

[Rahila_T_Intel]

Hi,

Thanks for posting in Intel Communities.

We were able to reproduce the "uninitialized memory access error" with your code while analyzing with Intel Inspector.

 

Uninitialized memory access means that pointer which is supposed to contain the valid address was not initialized(does not contain valid address) probably null or some junk.

To avoid this type of memory error, always initialize variables before using them.

 

It is mentioned in Inspector document https://cdrdv2-public.intel.com/780271/inspector_user-guide-linux_2023.2-767796-780271.pdf (page 207)

Also a possible workaround can be:

You could try to use calloc instead of malloc, for initialization. By default, calloc initializes allocated memory with zeros. 

tNrPdcpPduHdr_Sn12* pHdr = (tNrPdcpPduHdr_Sn12*)calloc(1,8);

Kindly let us know if you need any more clarification on this.

If this resolves your issue, make sure to accept this as a solution. This would help others with similar issue. 

Thanks

[Hill__Stephen]

If you take a look at the code, you will see there are no reads of the malloc'ed block at all.

The problem though is clear once you look at the disassembly ... in that the MSVC compiler, at least for debug compilation produces x86 inststructions for writing to the bitfield which cause the false positive...

[Hill__Stephen]

Note that we cannot possibly incur the cost of calloc(), especially when the code afterwards is setting all the used bytes of the block anyway.

[Rahila_T_Intel]

Hi,

We are working on this internally and will get back to you soon.

Thanks

[Rahila_T_Intel]

Hi,

We apologize to say that this is not an issue of Intel Inspector. This "Uninitialized memory access" error is visible only when we create the executable using Visual studio Debug mode, as you already mentioned.

Could you please try to create the executable in Release mode of VS ?

Or you can try to use VScode or g++ compiler .

Please let us know if you need further clarification.

Thanks 

[Hill__Stephen]

As I stated in my original post:

* If the assignment of ->DC line is switched with ->R line of code, then it passes. Seems to be related to use of literal.
* If any compiler optimization is enabled it passes.
* If instead built with GCC under Debian it passes.

The reason becomes clear when one uses the disassembly view in Inspector to see what the compiler has produced. With the MSVC debug build it produces a read/modify/write arrangement to partially modify the byte, and hence Inspector sees the first read as reading uninitialized data.

[Rahila_T_Intel]

Hi,

The disassembly view in Intel Inspector reveals how the compiler generates code, particularly in a Visual Studio debug build. The code produced might involve a read/modify/write sequence, which the Inspector interprets as accessing uninitialized data during the initial read operation.

When using Inspector, especially in debug builds, certain compiler optimizations might be disabled to facilitate better debugging, potentially leading to different code generation strategies.

In debug builds, compilers might employ different strategies that can affect how variables are read, modified, or written, especially in scenarios involving byte-level operations.

If you need further clarification, please let us know.

Thanks

[Rahila_T_Intel]

Hi,

We haven't heard back from you.

Could you please confirm whether we can close the case?

Thanks

[Hill__Stephen]

I have tried using /O1 and /O2 and unfortunately Inspector is now giving false +ves in other code that also has the same pattern as above .... malloc block and then set bitfield. But in these other cases the debug build doesn't produce a false positive.

I am now completely stuck as to how to resolve this problem, as the codebase is full of this code pattern.

Regards,

Steve

[Rahila_T_Intel]

Hi,

We are investigating the issue further. Will update you soon.

Thanks

[Kaleem_A_Intel]

Hi,

I tried with the “Intel OneAPI command prompt for Intel 64 Visual Studio 2019” to build the code snippet in debug mode. The resulting executable did not encounter any errors when analyzed with the inspector. 

Thanks

[Hill__Stephen]

Here's what I see in Inspector:

P1: Error: Uninitialized memory access: New
 P1.4: Error: Uninitialized memory access: New
  C:\Users\hil71789\source\repos\BitFieldTest\BitFieldTest.cpp(20): Error X4: Read: Function main: Module c:\views\bitfieldtest\x64\debug\bitfieldtest.exe
  Code snippet:
   18      U8 DC = 1;
   19      tNrPdcpPduHdr_Sn12* pHdr = (tNrPdcpPduHdr_Sn12*)malloc(8);
  >20      pHdr->DC = DC;
   21      pHdr->R = 0;
   22      free(pHdr);

  Stack (1 of 1 instance(s))
  >bitfieldtest.exe!main - C:\Users\hil71789\source\repos\BitFieldTest\BitFieldTest.cpp:20
   bitfieldtest.exe!invoke_main() - d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
   bitfieldtest.exe!__scrt_common_main_seh() - d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
   bitfieldtest.exe!__scrt_common_main() - d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:330
   bitfieldtest.exe!mainCRTStartup - d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp:16
   kernel32.dll!BaseThreadInitThunk - c:\windows\system32\kernel32.dll:0x1733e
   ntdll.dll!RtlUserThreadStart - c:\windows\system32\ntdll.dll:0x526ab

Attached MSVS project including binary, and Inspector project

[clevels]

Hello- thank you for your patience. I have provided our development team the reproducer and will provide an update when they respond.

[clevels · Accepted solution]

Intel® Inspector is no longer included in the Intel® HPC Toolkit. It is now downloadable as a standalone package and it will be discontinued in 2025 or later. Customers who have purchased Intel® Priority Support will continue to receive support. Please see Intel Inspector deprecation article for more information.