Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

valgrind use cases #35

Open
ejrgilbert opened this issue Jun 4, 2024 · 1 comment
Open

valgrind use cases #35

ejrgilbert opened this issue Jun 4, 2024 · 1 comment
Assignees
Labels
enhancement New feature or request investigation Issue to document idea and research while investigating it

Comments

@ejrgilbert
Copy link
Owner

ejrgilbert commented Jun 4, 2024

e.g. track liveness with mallocs (what memory regions are currently live) along with memory accesses (am I accessing a region of memory that is currently live?)

General

  • Output commentary should have clear marking as not program output, e.g.:
    ==12345== some-message-from-Valgrind
    
  • Print a stack trace for each error and warning
  • When an error is reported, it is given the full commentary for only 1 instance, e.g.:
    ==25832== Invalid read of size 4
    ==25832==    at 0x8048724: BandMatrix::ReSize(int, int, int) (bogon.cpp:45)
    ==25832==    by 0x80487AF: main (bogon.cpp:66)
    ==25832==  Address 0xBFFFF74C is not stack'd, malloc'd or free'd
    ==25832== Invalid read of size 4
    ==25832==    at 0x8048724: BandMatrix::ReSize(int, int, int) (bogon.cpp:45)
    ==25832==    by 0x80487DD: main (bogon.cpp:69)
    
  • Give errors in the order users should fix them
    • For example, a program which copies uninitialised values to several memory locations, and later uses them, will generate several error messages. The first such error message should give the most direct clue to the root cause of the problem.
  • Have a quiet mode that only outputs errors (not warnings)
  • Create option to stop after a certain number of errors
  • Timestamp option using sys.time or similar

Memcheck

  • Invalid read: say size, memory location, and where in the code it is
  • A comment is given for what the likely error cause is
  • Output the error before the code executes, as it will likely segfault
  • Set a limit for the number of errors you collect in order to not bloat it
  • Have toggleable warnings for unsafe things (incrementing pointers and the like)
  • Create option to stop after a certain number of errors
@ejrgilbert ejrgilbert added the enhancement New feature or request label Jun 4, 2024
@wavid-b wavid-b self-assigned this Jun 11, 2024
@wavid-b
Copy link
Collaborator

wavid-b commented Jun 11, 2024

Here is where I'm going to be putting the info https://docs.google.com/document/d/1dpfPOlc9bpuV2BuPVpwjU-3xXUa50yNfixyTND91p7Q/edit?usp=sharing

DM me for edit access and I'll add you

@ejrgilbert ejrgilbert changed the title collect valgrind use cases valgrind use cases Aug 12, 2024
@ejrgilbert ejrgilbert added the investigation Issue to document idea and research while investigating it label Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request investigation Issue to document idea and research while investigating it
Projects
None yet
Development

No branches or pull requests

2 participants