So I'm playing around in VS2022 with /fsanitize=address but I fail to understand how is this useful if it only catches only a small ammount of out of bounds accesses. For instance, this simple program works fine:

int main()
{
  unsigned char arr[2] = { 0xAA, 0xAB };
  arr[255] = 4;
}

Is there something I'm missing? I see that small indexes like arr[2] do trigger address sanitizer errors. Is there a way to configure the limits of the address sanitizer?

Context: I discovered a bug in my C program where I would index an array using a variable which is wrongly reset to 0xFF under certain circumstances but none of my ~300 tests detect this. I thought the address sanitizer would detect it but it seems I'm wrong.

So I'm playing around in VS2022 with /fsanitize=address but I fail to understand how is this useful if it only catches only a small ammount of out of bounds accesses. For instance, this simple program works fine:

int main()
{
  unsigned char arr[2] = { 0xAA, 0xAB };
  arr[255] = 4;
}

Is there something I'm missing? I see that small indexes like arr[2] do trigger address sanitizer errors. Is there a way to configure the limits of the address sanitizer?

Context: I discovered a bug in my C program where I would index an array using a variable which is wrongly reset to 0xFF under certain circumstances but none of my ~300 tests detect this. I thought the address sanitizer would detect it but it seems I'm wrong.

• c
• address-sanitizer

• 4 Are you sure this code is not optimized out? It does not do anything, so the offending stack writes could be not happening at all. – Eugene Sh. Commented Feb 6 at 17:20
• 1 Do you want a possibility to configure the range of sanitizer? Or would you also like a (speculated) explanation of how your observation might have been caused? I ask because I could provide some hopefully insightful (though not guaranteed) speculation, while how to configure is a question that can probably only be answered by studying the manual of your sanitizer. Consider asking so that an answer you would find helpful would actually match your question. – Yunnosch Commented Feb 6 at 17:22
• 1 @gregspears I think we are in the same boat, feeling that technical discussion, even speculation, would be more helpful than how to configure. – Yunnosch Commented Feb 6 at 17:27
• 1 Aside, it is virtually impossible to detect these things reliably. In this case, the sanitizer is likely implemented via stack canaries, but if the write happens far beyond the canary, it goes undetected. On the other hand, the memory which does not belong to the process is not supposed to be writable. But again, there is certain granularity to the allocated memory, so the specific write might still hit the page which is accessible. and technically belonging to the process. – Eugene Sh. Commented Feb 6 at 17:38
• 1 @Yunnosch I figured that you need more paddlers :D – Eugene Sh. Commented Feb 6 at 17:45

1 Answer 1

how is this useful if it only catches only a small ammount of out of bounds accesses

First of all, catching even a small amount of errors is useful.

Secondly, it catches far more than a small amount of errors. It's common to accidentally dereference one beyond what's valid. NULL dereferences is another huge source of invalid dereferences, and those are also caught (by gcc's address sanitizer if not VS's).

This is why an address sanitizer provides a lot of value as a debugging tool.