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

New plugin proposal: Memory Testing #277

Open
dpostorivo opened this issue Jun 11, 2018 · 7 comments · May be fixed by #807
Open

New plugin proposal: Memory Testing #277

dpostorivo opened this issue Jun 11, 2018 · 7 comments · May be fixed by #807

Comments

@dpostorivo
Copy link
Contributor

One thing that I've done outside of Ceedling, but I would like to see done in Ceedling is running a memory analyzer like Valgrind or Dr Memory as an option. Out of curiosity how many people would like a plugin like this in Ceedling?

One open question I have if people want this is: How do we want this implemented? Do we just want to run Valrind or Dr Memory on the executable after we've collected the test results or would we want this to be like the gcov plugin that builds a separate executable for each test in an isolated environment?

@dpostorivo dpostorivo changed the title New plugin prosoal: Memory Testing New plugin proposal: Memory Testing Jun 11, 2018
@Jasonmh-macom
Copy link

I am interested in having this option. I'm actually ran across this issue whilst googling trying to find how to integrate valgrind...

An a previous project we used a shell script that just ran valgrind on the test executables without really doing anything special re: environment and it seemed to work just fine. I don't really have a strong preference either way though.

Just my $0.02

@mvandervoord
Copy link
Member

This is a good idea for a plugin! Thanks for the thought!

@dpostorivo
Copy link
Contributor Author

@mvandervoord I have a few questions on the implementation. In my mind, you would choose to do a memory test separate from actually running a test. Since all that needs to happen is the objects need to be run with a different executable, I'd figure that the plugin not worry about its own objects in contrast right now with the gcov plugin builds which everything separately.

However, I'm curios about about two things:

  1. Is it viable to check if objects are generated or need to be updated before a plugin runs. I.E. If I want to run a memory test on test_foo.c and I run the command ceedling memcheck:foo, is there a way to verify that test_foo.out has already been generated and is updated?

  2. Along the same lines, is there a way to suppress tests results if someone just wants to run the memory check?

@lyager
Copy link

lyager commented Oct 24, 2018

Just wanted to hear if anyone have done any work towards getting the unittests to run under Valgrind? Anything to share?

@lyager
Copy link

lyager commented Nov 1, 2018

I've created a merge request that attempts to fix the command_hook plugin. #307

After linking I'm able to use Valgrind with the hook. Agreed, best scenario would be to create a Valgrind plugin - the above merge makes the command_hook work how I thought it was supposed to work.

@ojousima
Copy link

This feature seems to be implemented by now, maybe this issue could be closed?
https://blog.zaleos.net/unit-testing-c-code-with-ceedling-and-cmock/

@jamestiotio
Copy link

It seems that we can use Valgrind via command_hooks. The article linked by @ojousima also uses the command_hooks approach.

That said, we can also add a Valgrind plugin to provide a more seamless integration of Valgrind with Ceedling. I can work on this and raise a PR to eventually close this issue.

@jamestiotio jamestiotio linked a pull request Sep 1, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants