| Summary: | Uninitialized parameters to VALGRIND_MAKE_MEM_NOACCESS() not warned about. | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Vladimir Marko <swelef> |
| Component: | memcheck | Assignee: | Julian Seward <jseward> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | philippe.waroquiers |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Vladimir Marko
2017-03-10 14:11:53 UTC
Quick feedback: More generally, all valgrind client requests arguments for client requests in valgrind.h or memcheck.h could potentially be uninitialised, and so should be checked. Client requests are implemented by macros that expand to a very 'strange' sequence of instructions, recognised by the JIT so as to switch from the simulated CPU to the real CPU (and execute the client request on the real CPU). To trigger an error, it means that the macros would need to add some fake jump instruction to be evaluated on the simulated CPU to trigger an error msg. In other words, all the args of the macros should first be checked by expanding the code with e.g. the macro #define TRIGGER_MEMCHECK_ERROR_IF_UNDEFINED(x) \ if ((ULong)x == 0) __asm__ __volatile__( "" ::: "memory" ) similarly to what is done in coregrind/m_replacemalloc/vg_replace_malloc.c for malloc arguments. However, vg_replace_malloc.c is "pure valgrind code", only loaded when running under Valgrind, while client request expanded code is part of the compiled application code, even when not running under Valgrind. So, fixing this bug will increase the size and/or cost of the client request expanded code, even when not running under valgrind. Wondering if this additional size/cost is ok. For sure, this needs further discussion, once a prototype patch is done. |