The value of valgrind

This weekend I got quite a lot done on liboca, mainly working on the network stack, and the basic implementation of OCP.1, which is the TCP/IP-based protocol for OCA (There is room in the OCA standard for other transports). Anyhow, at one point, my unit tests broke in a suite of tests that tested code that should not have been affected by the code I was working on. In the end the fact that I had set up Valgrind, ended up showing me how to solve my problem, so I learned that hard way that it is an essential tool to run along with your standard test suite.

What is Valgrind?

"Valgrind is an instrumentation framework 
for building dynamic analysis tools. There 
are Valgrind tools that can automatically 
detect many memory management and threading 
bugs, and profile your programs in detail. You 
can also use Valgrind to build new tools. " 
                                      - valgrind.org

In its simplest form, it takes your code, instruments it and runs it on a processor emulator, and tells you if you’ve leaked memory, accessed memory you shouldn’t have, and a whole bunch of other stuff – I encourage you to check out the website for more detail.

So what happened?

So we already got to the fact that I had a theoretically non-impacted test stubbornly crashing with:

Segmentation fault (Core Dumped)

Frustratingly, I couldn’t reproduce the crash in a debugger, which left me thinking it was a race condition for a while, but all the tricks I tried to hunt down the race didn’t give me any inclination as to what was going on. Also, the core was not being dumped, by default Ubuntu doesn’t do that. You need to enable core dumps with:

$ ulimit -c unlimited

Anyhow, I then debugged the core dump:

$ gdb build/tests/all core

Finding that the Seg-fault was inside Google Test! Googling for this issue showed no known issues around this part of the code, so I was a little stumped.

So what next?

Looking further up the stack trace showed that it happened inside _malloc_consolidate which previous investigations have lead me to attribute to memory corruption, most often heap trashing. Anyhow, I have a bunch of verification scripts set up to automatically run the unit tests, static analysis and dynamic analysis (valgrind!), and was indeed running them. Lo and behold, valgrind (memcheck) was turning up 47 issues, all of which were relating to a few lines of code (that I had been working on) where I was deleting an object which was still needed by an asynchronous process. I fixed the errors rather easily, and hey presto! No more Segmentation Fault.

You see the problem was not even the unit test in question, but about 10 tests earlier, the heap was getting trashed, which was causing the test runner to seg-fault later on.

So what did I learn?

In the past I’ve had policies on repositories that no code makes it in without a successful build and test-run. Usually I compile with -Werror (or similar) so that my code never has any warnings (because I have to fix them, since they’re treated as errors). This time I added cppcheck and valgrind because I figured they would be useful. This experience taught me that if I ever encounter weird issues while I’m working, I should run the full verification suite because I will probably find something related to the weird issues that way.

My first ever audio plugin

I’ve been procrastinating working on the OCA library project that I’ve started, so I ended up writing a really naive distortion plugin.

My SI-D1 distortion running as a standalone JACK application.
My SI-D1 distortion running as a standalone JACK application.

It works as a LADSPA, LV2, VST (untested) plugin, or as a standalone application (as pictured above). I used the DISTRHO Plugin Framework which is how I can target all the platforms. It should, in theory, build on Windows as well.

The code itself is quite simple: it pre-amplifies the signal, and then applies a very hard clipping algorithm. The clipping levels are determined by the “Range” and “Bias” parameters. Range sets the distance between the thresholds, around 0.0, and then Bias moves those thresholds up or down. It doesn’t sound great but its a start.

I haven’t provided a binary download as yet, but you can get it on github.

Try it out and let me know what you think.

Towards a cross-platform C/C++ dev environment

As you’ve probably read in my recent posts, I’ve been getting involved in the linux audio community. I’ve discovered that I really like linux – especially the concept of a system-wide package manager, I wish Windows had one that everybody used.

What I miss is Visual Studio. I really can’t overstate the hit my velocity has taken without intellisense. Its not that I’m incapable of programming without it, but it takes such a long time to look through html SDK/API docs. So, I’ve been trying to sort out a system where I can lint my code, build my projects, get some form of auto-complete, and have a few other C/C++ specific conveniences, like switching between .h* and .c* files with the same base name. I also don’t want to be tied to a build system. I’m kinda greedy, I want a graphical debugger if I can. I’ve got a solution now which shows potential.

As text editors go, I’ve grown to like Atom by GitHub over the last year or so. It is built in JavaScript (mostly, they moved a few things down to native code for performance, it is now quite slick, and a lot better than it was even 6 months ago), and it is super extensible, but in a nice way, not like Eclipse.

Triggering builds

One of the challenges with Linux is that there are quite a few build systems in common use: autotools, scons, waf, cmake to name a few. I like waf, but autotools is super common. Anyway, I didn’t want to be tied to a build system, but I do want to do basic things like build or configure my project from a keyboard shortcut. There’s a nice plugin for this: build. It has a bunch of built-in build systems that are mainly web-focused, but it lets you basically tie any shell command to the keyboard shortcut if you want, by providing a file called .atom-build.json.

Here’s what mine looks like:

{
     "cmd": "./waf",
     "name": "Build",
     "sh": "true",
     "targets" : [
         {
               "cmd": "./waf configure",
               "name": "Configure",
               "sh": "true"
         }
   ]
}

It’s not perfect – if you switch target it remembers which is a pain for doing things like configure, or clean, which you do once in a while, then go back to building. I’ll probably fork it and make a more C/C++ centric version one day, but it works well enough. Install it as follows:

> apm install build
Linting

Ok, so I can build, and each time I build, I get to see what’s wrong but sometimes deciphering a big blob of compiler output is difficult, and slow. Atom has a plugin which gives a generic linting infrastructure. I guess it was originally built for JSLint or something. Users can create providers to this linter to handle various languages, and it just so happens there is one which uses GCC, and one which uses Clang, so take your pick. I’m using the GCC one.

> apm install linter linter-gcc

You can change the default compiler flags, so I added -Werror, to make warnings appear as errors – I use that in my build script as well. linter-gcc supports a per-project config file which allows you to configure the settings per project, called .gcc-flags.json. I haven’t had to add any flags to it as yet, but at some point I’ll write a waf plugin to dump my CFLAGS and CXXFLAGS into this file whenever I configure. If you use autotools, I’m sure your configure script could do something like that too. A note about this one: at the time of writing (version 0.36.0), this plugin is actually a little broken. I fixed it and the PR was merged, so you should probably get it from source instead, or install it with apm and then replace the main.js with one from github.

Auto-complete

Again, Atom has existing auto-complete infrastructure in the form of the autocomplete-plus plugin, which can be extended by providers – in this case autocomplete-clang. Now this is one of the key reasons LLVM and Clang were created, to be used in tool integrations. You’ll need to have Clang installed such that the clang executable is on your path, but that’s easy on all platforms. Install the plugins with:

> apm install autocomplete-plus autocomplete-clang

You can customize your cflags etc per project with a .clang_complete file, which is the same file used by the clang-complete plugin for VIM, which is neat. Again, I haven’t had to modify these yet, but getting waf to auto-generate the file should be pretty easy.

Switching files

Ok, so we can build, lint, and auto-complete now. All that’s left from my wish-list is switching between header and source files with the same name, and debugging. Lets deal with the former, there’s a plugin for that.

> apm install switch-header-source
Debugging

This one is probably the least satisfying. I’ve installed a plugin called atom-debugger, which basically bootstraps gdb. At the moment it is very basic, but I think it could be improved quite quickly, so I’ll probably find myself contributing to it. Install it with:

> apm install atom-debugger
Conclusion

Linux is actually a really awesome environment to write code in, mainly because of system wide package management, and a defined scheme for where libraries, headers etc go, which means that you very seldom have to add special include or lib directory paths to your compiler flags. Visual Studio is an incredibly powerful IDE, which you miss when you are relegated to a mere text editor. Atom, is a great, highly extensible text editor which can be extended to give you quite a functional IDE for developing in C/C++, without being tied to a buildsystem or compiler, and it can be done on Linux, OSX and Windows. Boom.

 

To share or not to share…

So, I’m gradually working towards making a simple fighting game, using my Kinect as the input sensor. I think initially it’ll be one person punching a punching bag, then two people competing, and then probably some sort of computer controlled AI which looks at your pose, and chooses the right pose/move accordingly (although since I don’t really know how to fight, that will be interesting).

The Experiment

Anyhow, a few weeks ago I got a very rudimentary scripting host working, where I have my rendering infrastructure written in C++, and I have a mono .NET window displaying the output etc. Well I have since improved it to allow me to create entities on-screen in a (somewhat) adhoc manner (they’re all the same entity at the moment). In doing this I decided to do an experiment to discover what we all know is true: if you have more than one instance of the same model on screen, it better be the same vertices et al in memory. My Naive version loaded the model from disk, and packed it into my renderable format in memory each time the scrip requested an entity from the engine. I wanted to do 1000 entities, but the Naive approach crashed my computer at ~380, so for my performance comparisons I only went up to 200. My second approach uses boost::flyweights to share the model amongst all the entities that use it. I performance tested this one up to 200 as well, but as you can see below it gets up to 1000 dwarves on screen quite happily.

Snow-white couldn’t cook for all these guys.

Continue reading “To share or not to share…”

.NET Class Wrapper coming along

I’ve been embedding mono into my game engine, and decided that what I needed was a code generator to generate C++ classes which wrap .NET classes that exist inside the sandboxed runtime.

I’ve decided on StringTemplate for the templating side of it, and after trying to write a template without first knowing what the class should actually look like, I set about writing an initial prototype of what I would like my generator to eventually produce. This went quite smoothly (if rather slowly), and eventually I found that my application, whilst calling all the .NET code I wanted it to, was crashing when trying to free some memory.

I eventually found that my problem was that I shouldn’t be calling free for a pointer that was allocated using g_malloc, because that’s just asking for trouble. However, g_free, just won’t compile (well, link actually), not in a million years, not in my code (but for some reason it does in libmono). However, the lovely people over at the mono-devel mailing list said I should use mono-free (which wasn’t in my library definition, causing me much angst). Eventually I edited mono.def, recompiled mono, and my code, and what do you know? It works.

Next stop, a code generator.

Progress with Mono!

So today I spent some time building embedded Mono into my game engine (if you can call it that, it’s pretty skeletal so far). It’s pretty poorly done at the moment (design-wise), but I can execute code from a .NET dll within my application. What I didn’t realise until just now, was that the mono runtime will happily load dll’s built with Microsoft’s compiler, which means I don’t even have to worry about needing a separate build environment for the C# code (although it’s pretty easy, just run xbuild on your project/solution from cygwin).

The next steps here will probably be along the lines of turning the runtime stuff into some sort of script host, and coming up with patterns for writing/generating bindings between the two environments. I think I’ll investigate SWIG for this. Binding C# code to C++ types will be fairly easy – the C++ type just needs to register all of its member functions with the runtime, and then a wrapper around these can be written in C# in much the same way as you would wrap any other C dll, using the extern keyword and the MethodImplAttribute. On the other hand, accessing C# types from within C++ requires a fair amount of code (somewhat like using reflection in C#), and so it will be necessary to use some sort of code generator to generate efficient wrappers.

Very Interesting.

Finally worked out my problem with Windows Events

For a while now I’ve been trying to use Windows Events as my logging framework, but I have suffered from one seemingly fatal problem: if my application terminated unexpectedly (thus ungracefully), my session was left open, and I was seemingly unable to stop it or re -enable providers against it. This was beginning to make me feel like Windows Events was not the right framework for debug logging, because an ungraceful termination is very likely during development. However, I have since found that I was not passing the name I thought I was to the StartTrace function, and so although I could close my session as long as my application didn’t terminate (due to some state in my logging class), a “Cold-Stop” (as in a ControlTrace call at the start of my app) would not work.

I have now corrected this bug in my code, and can now close the open session and restart it if I encounter ERROR_ALREADY_EXISTS upon starting my session.

WIN!

Success with Mono at last!

I have been trying (I use this term loosely, since I’ve probably only spent a slightly long working day on it), for a couple of weeks now to write a C++ application which spins up an embedded Mono runtime environment, and executes some C# code – my aim being to write a game engine which uses C# as its scripting language.

All of this would have been quite simple had I not decided that I want my engine to be 64-bit from the get-go, and so started my long journey to getting mono-embedded working.

First, I was under the impression (which turned out to be right), that I would need to build all of mono from source, so I checked out the source code (which took a long time my mono folder is 1.72GB on disk, although some of that must be binaries surely?), only to find that only the runtime can be built from Visual Studio (the framework and compilers must be built from cygwin – autotools, YUCK!). So I then asked the community how much I needed to build, and was told I only needed a 64-bit runtime. So, I tried to build the runtime in Visual Studio 2010, but couldn’t, so I moved to Visual Studio 2008, where I eventually managed to get the runtime compiling, but found there was a bug in the code which I later fixed on the advice of one of the community members.

So finally, I had a working runtime, only to find that the installed version of the framework I had was too old (it seems the source code I downloaded is much newer than the released 2.6.4 version of mono). So, I had to bite the bullet and install cygwin (which took me a couple of attempts to get right). Anyhow, nearly two hours later and the code is built, installed, and the test embedding application works like a charm.

WIN!

Thanks especially to shana for this article on building mono for windows. If you’re going to follow it, I recommend installing the cygwin version of make, rather than 3.80 (the article is a little old, and cygwin have fixed their make).

Anyhow, it is way past my bed-time on a Sunday, but I’ll post more about my experiences embedding mono in the future.

A Quick and Dirty tutorial on Event Tracing For Windows: Part 1 the Event Trace Session

[EDIT 4 September 2010]
Thanks to David M for pointing out an error in my code. When starting an ETW session you should pass in the
session name not the log file name. See the correction (in bold) in the LoggingController::Start member function below.
[/EDIT]

So, Windows Events, its the new Logging API for Windows Vista+, it brings together Event Tracing for Windows (ETW) and Windows Event Log. The basic layout of ETW is that you have an Event Tracing Session, for which you enable providers. These providers write log messages into the session. You can enable the providers with various settings allowing you to filter the type and criticality of the log messages, and do all that fun sophisticated tracing stuff. If you use a “manifest-enabled” provider (more on that later) you get the Windows Event Log side of it for free. You can also create consumers of these sessions, to monitor the logs and stuff. Continue reading “A Quick and Dirty tutorial on Event Tracing For Windows: Part 1 the Event Trace Session”