I'm trying to use Valgrind on a program that I'm working on, but Valgrind generates a bunch of errors for one of the libraries that I'm using. I'd like to be able to tell it to suppress all errors which involve that library. The closest rule that I can come up with for the suppression file is
{
rule name
Memcheck:Cond
...
obj:/path/to/library/thelibrary.so
}
This doesn't entirely do the job, however. I have to create one of these for every suppression type that comes up (Cond, Value4, Param, etc), and it seems to still miss some errors which have the library in the stack trace.
Is there a way to give Valgrind a single suppression rule to make it completely ignore a particular library? And even if there is no way to make such a rule which covers all suppression types, is there at least a way to create a rule which ignores all errors of a particular suppression type from a particular library?
For most of the suppression types, you omit the wildcard, like so:
{
name
Memcheck:Cond
obj:/path/to/lib/lib.so.10.1
}
{
name
Memcheck:Free
obj:/path/to/lib/lib.so.10.1
}
{
name
Memcheck:Value8
obj:/path/to/lib/lib.so.10.1
}
Note that you must list each type of error separately, you can't wildcard them. You must also list the entire pathname of the library (as shown by valgrind, with any "decorations" like version numbers).
Also, leaks are handled differently -- for those you need something that looks like this:
{
name
Memcheck:Leak
fun:*alloc
...
obj:/path/to/lib/lib.so.10.1
...
}
It appears that it is necessary to include a separate suppression record for each type of error (Cond, Value4, Param, etc). But based on my testing with valgrind-3.6.0.SVN-Debian, I believe you can use the following simplified form for each type of error...
{
<insert_a_suppression_name_here>
Memcheck:Cond
...
obj:/path/to/library/thelibrary.so.*
...
}
{
<insert_a_suppression_name_here>
Memcheck:Leak
...
obj:/path/to/library/thelibrary.so.*
...
}
The three dots are called frame-level wildcards in the Valgrind docs. These match zero or more frames in the call stack. In other words, you use these when it doesn't matter who called into the library, or what functions the library subsequently calls.
Sometimes errors include "obj:" frames and sometimes they only use "fun:" frames. This is based, in general, on whether or not that function is included in the library's symbol table. If the goal is to exclude the entire library, it may work best if the library does not include symbols so that you can exclude based on the library filename instead of having to create separate suppressions for each function call within the library. Hopefully, Valgrind is clever enough to suppress errors based on library filename even when it does know the function name, but I haven't verified this.
If you do need to add suppressions based on individual functions within the library, you should be able to use the same form...
{
<insert_a_suppression_name_here>
Memcheck:Leak
...
fun:the_name_of_the_function
...
}
Note: You can include --gen-suppressions=all on the valgrind command-line in order to see the exact form and names (including any C++ mangling) required to suppress each error. You can use that output as a template for your suppression records -- in which you would usually want to replace most lines with ... in order to simplify the process of suppressing all errors that might occur in association with a specific library or function call.
Note: <insert_a_suppression_name_here> is a placeholder in which you can type whatever descriptive text that you want. It is required to not be blank.
nobar's answer almost worked for me, but I was getting a syntax error:
==15566== FATAL: in suppressions file "suppresion.error.txt" near line 4:
==15566== bad or missing extra suppression info
==15566== exiting now.
For system calls, I needed to add an extra line as the docs state:
Param errors have a mandatory extra information line at this point,
which is the name of the offending system call parameter.
So I ended up with this and it worked:
{
<sup_mmap_length>
Memcheck:Param
mmap(length)
...
fun:function_from_offending_lib
...
}
Related
I'm learning to use vim, but I think it's inconvenient to generate function definition in .cpp file from its declaration in .h file.
For example, if I declare a function void print(const vector<int>& arr); in A.h, I have to open A.cpp and type the following:
void print(const vector<int>& arr) {
}
(or use yy copy the declaration line, then delete ; and add {}...)
When some derived classes need to override function in base class, it can be a heavy job...
Is there any convenient plugin or command to help me deal with it?
My lh-cpp plugin has been providing this feature for quite some time now.
Go on the function declaration, type :GOTOIMPL et voilà!. It either moves the cursor to a function definition (from its declaration), or if none exists, it generates an empty shell to define that function.
Note: I'm currently in the process of improving the feature to support any kind of function declaration. To support template functions, you'd have to use the gotoimpl_with_libclang branch and the support plugin vim-clang (in V2Upgrade branch).
At this precise moment the sister command :MOVETOIMPL doesn't work as expected with constructors defined with initializer-lists, which has side effects on the :Constructor command. :MOVETOIMPL is meant to change an inline definition into a declaration plus a separate definition in a .cpp file typically.
Note: lh-cpp is a complex plugin that provides many things and that has many dependencies. Regarding overriding, it provides an :Override command to let us select which function we want to override -- this feature requires my current working branches of lh-cpp and vim-clang.
If you are using Neovim, you can try my plugin: cppassist.nvim, which can basically be used normally, but there are still many problems. Welcome to ask me questions!
This plugin will recursively search in your working directory until a file matching the same name with the counterpart extension is discovered. Note that the search also respects your .gitignore if one exists and any file ignored in git will be ignored in the results. As such, I suggest working from the root of your project. Once that file is found, it will automatically be opened in the current buffer. If no corresponding file is found, a message will be logged to the messages buffer -- use :messages to review your recent messages.
It uses regular expressions instead of LSP to generate function definition. Currently, it supports most keywords, as well as template types, and can generate multiple function definitions simultaneously in view mode.
However, the definition of nested classes is not currently supported. Also, if the function definition is already generated, press the shortcut key again and it will generate the function definition again.
Is there a way to disable react-jsx transformation in some files of a ReasonReact project?
I think the other way around is possible by not adding "reason": { "react-jsx": 3 } to bsconfig.json and by adding ##bs.config({jsx: 3}) to the top of the files where you want react-jsx transformation, but that would force me to add this annotation in too many files.
I'd like to build a small DSL based on JSX in a few files while benefiting from React in the rest of my project.
Note: the solution suggested is not very straight forward, and I think it's much simpler to add ##bs.config annotations explicitly in all required files, but if you really don't want to do that, the following might work.
If I'm reading the compiler code correctly, user-defined ppxs are applied before ReasonReact ppx. In the linked compiler module, Cmd_ppx_apply.apply_rewriters will apply with all arguments passed with -ppx flag, and Ppx_entry.rewrite_implementation is ReasonReact ppx.
Assuming that's true, one could have a ppx that checks a top-level statement like ##custom.jsx at the top of the file, that the ppx would check. The ReasonReact ppx used to have a similar check, in case it serves as reference.
Then if this statement is found, the custom ppx would process the nodes that have the #JSX attributes and make sure it removes the attributes from them, so when the compiler passes the AST to ReasonReact ppx, it won't see them.
Note this would break if the ReScript ppx pipeline is updated one day to a driver-based one (unlikely I'd say because that would mean ReScript should support native libraries as 1st class citizens somehow), or if the ordering that was mentioned above changes (ReasonReact ppx applies before user-defined ones).
I want to be able to include ("import") source files but I don't need to do any preprocessing on them (not C or C++, etc). The only thing I need to be able to do is, if there's a syntax/semantic error in one of the included files, my error message would need to indicate in which file the error occurred.
From what I have surmised from reading, all I need is to use PUSHSTREAM in the lexer section but it's unclear to me exactly what I need to define. Would appreciate any pointers
I was unable to find following vim completer feature. Say you write a code and you specify a type before including appropriate header file defining this type e.g.:
int main(){
uint8_t a = 0, b = 5;
...
return 0;
}
What you end up with is:
use of undeclared identifier 'uint8_t'
warning in VIM (I use YouCompleteMe) and a compilation error:
error: unknown type name ‘uint8_t’
What I'm looking for is a completer that suggests you something like
use of undeclared identifier 'uint8_t' did you include stdint.h?
If no such feature exists so far, what is the reason?
In lh-cpp I had a small feature, that given a ctags database will be able to add the inclusion statement related to the symbol under the cursor. Now I've extracted the feature to lh-dev.
I also remember to have defined an associative map that knows where a few symbols from the standard library come from, so far I only use it to automatically add the inclusion statement for types we inherit from in my C++ class snippets. What is sure, is that it could also be used for fixing missing includes (not everybody want to parse the standard library with ctags).
Note however, my scripts don't try to automatically detect all missing includes to add them. It's much too complex in real C++ projects.
You may need to add directory path to the -I option list of your compiler, or add the directory path to VIM's path option variable
:help 'path
If you don't know wich path to include, locate stdint.h could be a good start.
Related Link.
Say there is a single warning such as path_statements, unused_variables. Is there a way to ignore a single instant of this, without isolating them into a code block or function?
To be clear, when there is a single warning in the code. I would like the ability to quiet only that warning, without having to do special changes addressing the particular warning.
And without this quieting warnings anywhere else, even later on in the same function.
With GCC this can be done as follows:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wformat"
/* Isolated region which doesn't raise warnings! */
this_would_raise_Wformat(args);
#pragma GCC diagnostic pop
Does Rust have the equivalent capability?
Note, am asking about the general case of how to quiet warnings.
Am aware there are ways to resolve unused var warning for eg.
To silence warnings you have to add the allow(warning_type) attribute to the affected expression or any of its parents. If you only want to silence the warning on one specific expression, you can add the attribute to that expression/statement:
fn main() {
#[allow(unused_variables)]
let not_used = 27;
#[allow(path_statements)]
std::io::stdin;
println!("hi!");
}
However, the feature of adding attributes to statements/expressions (as opposed to items, like functions) is still a bit broken. In particular, in the above code, the std::io::stdin line still triggers a warning. You can read the ongoing discussion about this feature here.
Often it is not necessary to use an attribute though. Many warnings (like unused_variables and unused_must_use) can be silenced by using let _ = as the left side of your statement. In general, any variable that starts with an underscore won't trigger unused-warnings.
If you want to silence all warnings of a kind in a module, write e.g. #![allow(dead_code)] (note the exclamation mark) at the top of the module. This will disable all warnings of this kind in the whole module. You can also call rustc with e.g. -A dead_code.
You can disable all warnings by writing #![allow(warnings)] at the top of the module.
You can insert a module (as described in the Rust book) where the specific warnings are ignored.
As Lukas said, you can also write e.g. #[allow(dead_code)] on a statement or an expression.