Number of Illegally dereferenced pointer on version R2020b is decreased significantly?

Hi Anirban,

I'm comparing between version R2019b and R2020b when run same source code. Please take a look two shoots below:

• Source 780B

• Source 800B

Run 780B*: Number of Illegally dereferenced pointer on version R2020b is decreased to 264

Run 800B: Illegally dereferenced pointer on version R2020b is decreased to 237

Please let me know why Number of Illegally dereferenced pointer on version R2020b is decreased significantly?

Should we apply version R2020b?

BR

Thang Tran

[Rik]

If you want anyone else to have a shot at answering this question, you will have to provide a lot more explanation. Have a read here and here.

Answer 1

[Anirban]

Hi,

I assume you are using the exact same Polyspace project (with exact same configuration) in both versions. Can you check something real quick? Assuming that you are using the desktop products, on the Dashboard pane for a project, you can see the percentage of code covered by the verification. See more details in Dashboard. Can you check if the coverage is the same in both versions?

[Tran Thang]

Hi @Anirban,

I assume you are using the exact same Polyspace project (with exact same configuration) in both versions => Yes, they are same config

• Source 780B Dashboard

Version R2019b

Version R2020b

• Source 800B Dashboard

Version R2019b

Version R2020b

=> The percentage of code covered by the verification.

Please answer above two questions.

BR/ Thang Tran

[Anirban]

Thanks for the screenshots. It looks like the same amount of code was covered by the verification in both releases. Otherwise, it would be a cause for concern.

The reduction in oranges is usually an example of a good thing. There is constant work being done to improve the precision of a Code Prover analysis.

Orange checks are broadly speaking of two types:

• Actual issues that happens only on a subset of execution paths (so, you will see a run-time error only on some runs). These issues would always show up, irrespective of change in precision.
• Issues that appear because the analysis makes an overapproximation. As the analysis becomes more precise with each release, the number of these cases decreases.

Because the reduction in orange IDPs is quite dramatic, it would be nice to investigate further. The project might have many instances of a specific type of construct on which the analysis has become more precise. You can contact Support and ask for help with this.

[Tran Thang]

Hi @Anirban,

Please explain more clearly the sentences .

"Issues that appear because the analysis makes an overapproximation. As the analysis becomes more precise with each release, the number of these cases decreases."

Besides, when Mathlab released version R2020b, It will be more improvement.

Please let me know if it releate to Pointer or Array. Because the reduction in orange IDPs is quite dramatic

BR

Thang Tran

[Anirban]

Hi,

The orange checks that result from loss of precision, like the checks discussed in this answer, reduce each release because the analysis becomes more precise. In other words, Code Prover is able to definitely prove the absence of run-time errors in more number of situations. You should see exactly (or almost) the same increase in the number of green Illegally dereferenced pointer checks in R2020b, as the reduction in orange checks.

As for the precise types of orange checks that got reduced, this has to be investigated further. You can contact Technical Support for help, or compare the two results. With the Polyspace desktop product, an indirect way to diff two results would be the following:

1. Make a copy of the result in R2019b (so that you dont modify the original results). Select all Illegally dereferenced pointer checks in this copy and mass-add a custom Status to them. To create a custom review status, see Customize Polyspace User Interface.
2. Import comments from the R2019b results to the R2020b results. See Import Review Information from Previous Polyspace Analysis. If a check changes color, then the custom status does not get imported. Then, use the filters to only see those Illegally dereferenced pointer checks that do not have your R2019b status. See Filter and Group Results in Polyspace User Interface.

This way, you will see all those Illegally dereferenced pointer checks that changed color in R2020b. You can then spot-check one or two checks to see if you can find a pattern. For instance, maybe you can spot that the checks that turned from orange to green are ones you had already marked as not real problems in R2019b.

[Tran Thang]

Hi @Anirban,

Could you confirmed that Polyspace version r2020b has been improved something that relate to Illegally dereferenced pointer?

I need final answer.

BR

Thang Tran

[Walter Roberson]

"Final Answer" :

NO, Anirban has not confirmed that. However, if you create a Techical Support case and make your files available to them, then they will investigate.

Note: if I were Mathworks staff, I would refuse to provide a "final answer" to anything. If it were a matter that reached me in my volunteer capacity, I would tell the person to contact Mathworks Technical Support or Sales (as appropriate) for an official answer. If it were a matter that (hypothetically) reached me in my work, I would send the matter up to the appropriate project manager to choose to make a response or not.

[Tran Thang]

Hi @Walter Roberson,

Thank you for your answer,

I asked Mathworks Technical Support and waiting for them.

BR

Thang Tran

[Anirban]

Hi,

Without the results, it is difficult to confirm what is happening in your case. Can you try adding the option -consider-external-array-access-unsafe and see if the number of Illegally dereferenced pointer orange checks go back up? This option typically affects the number of Out of bounds array index checks, but if there are pointers to those arrays, then the number of Illegally dereferenced pointer checks can change, too.

Anyway, as you have realized, just from the screenshots of the number of results, it is difficult to make a conclusion. I can answer in a generic manner that there is a conscious effort from development to improve precision of Code Prover results every release. The goal is to give fewer false positives each release (as you probably know, Code Prover aims for zero false negatives subject to verification assumptions, so the fact that it misses something is usually not a concern).

[Tran Thang]

Hi @Anirban,

I compared result between R2019a and R2020b. I realized that almost cases, main_random in R2020b and it put pointer NOT NULL to function. => It will become GREEN. Please let me know why occur different?

BR

Thang Tran

[Anirban]

Hi,

In both releases, the message states that the pointer is not null. So that is not the difference.

An Illegally dereferenced pointer check consists of several checks:

• Whether the pointer is NULL.
• Whether the pointer points to a region that is ok to dereference.

It's the second check where R2019a and R2020b seems to differ. An interesting difference I notice is that in R2019a, the message states these things:

• Pointer may point to dynamically allocated memory. Is the pointer really pointing to dynamically allocated memory? Or, maybe Polyspace thinks it is doing that because of some overapproximation? And maybe Polyspace is more precise in R202b?
• Pointer points to some local variable in a function and is accessed outside the function. Again, this might be an overapproximation, that became more precise in R2020b.

I hope you were able to contact Support, and get a detailed investigation on your project.