ci/Vulnerabilities checker

[Luni-4]

Pull Request Template

Checklist

• Confirm that run-checks script has been executed.

Related Issues/PRs

This PR introduces a series of checks to detect:

• Memory leaks
• Undefined behaviours
• Data race detections

Since these checks are quite heavy, it would be better to run them before a release. Now I have added the pull_request event just to check if they work

Changes

Summarize the problem being addressed and your solution.

Testing

Describe how these changes have been tested.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (ec9df53) 87.42% compared to head (084d5d6) 87.42%.
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #964   +/-   ##
=======================================
  Coverage   87.42%   87.42%           
=======================================
  Files         502      502           
  Lines       50967    50967           
=======================================
  Hits        44557    44557           
  Misses       6410     6410           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Luni-4]

It seems we have some memory vulnerabilities detected during tests:

• Thread sanitizer found a data race in tests::ad_conv https://github.com/Tracel-AI/burn/actions/runs/6908132856/job/18796765104?pr=964#step:5:1923 in burn_ndarray
• Some leaking bytes in burn-compute https://github.com/Tracel-AI/burn/actions/runs/6908132856/job/18796765319?pr=964#step:5:1230, they are also found by valgrind https://github.com/Tracel-AI/burn/actions/runs/6908132856/job/18796765793?pr=964#step:5:1203

[nathanielsimard]

@Luni-4

I think those are all fine, maybe we could validate the conv_transpose kernel in burn-ndarray, but the memory leaks are normal in burn-compute, since we re-implement a garbage collector with its own logic to when it should cleanup memory.

[antimora]

We should in a scheduled scanner style similar to other security scanners. See: https://github.com/Tracel-AI/burn/security/code-scanning

[Luni-4]

@Luni-4

I think those are all fine, maybe we could validate the conv_transpose kernel in burn-ndarray, but the memory leaks are normal in burn-compute, since we re-implement a garbage collector with its own logic to when it should cleanup memory.

Hmm, I do not know the code of those crates, but having memory leaks is never a good sign. In my opinion, we should try to identify the causes of those leaks and thread races.

For what concerns the scheduled tasks, I approve the approach, in this way we are not binded to a specific event (a release, a push or pull request event)

[Luni-4]

@nathanielsimard @antimora

We can merge this PR that analyzes vulnerabilities as well.

Added features:

• Run each Tuesday at 21:00 (UTC) and when a new release is pushed
• Run 4 different types of tools:
  1. A vulnerabilities detector, valgrind, which produces a detailed analysis printed in the log
  2. A data race detector
  3. A memory leak controller
  4. An undefined behaviours detector

As now, we do not open new issues with stderr output for what concerns 2, 3, and 4. We can do that in a following PR. We do not consider 1 since valgrind analysis is too detailed and any possible issues would be too long to analyze

[antimora]

LGTM. Thanks @Luni-4 for your work with infrastructure. It's looking great!

Lets a give a try for this workflow.