Re: Some comments about GVFS


Carl Worth wrote:
Anyway, I've learned a few new things, and found the discussion very
useful. I hope you have as well.


By the way, is that a compile-time or a run-tim environment variable?
And what measures do you take to advertise it?

It's a run-time env variable. I think we don't advertise it at all, it's more of a defense against people who have strong views on the topic and prefer "undefined behavior probably a crash" to "just exit" ...

How does your D-Bus unit testing arrange to test all the OOM code

I have a dbus_malloc wrapper and it can be told to fail the Nth malloc. The test suite runs once and counts mallocs, then it runs over and over and over failing mallocs 1, 2, 3, 4, 5... ;-) Brute force!

When I first implemented this it found quite a few bugs, I then implemented something similar for part of libxml and also found a lot, so that's why my party line since has been that trying to handle OOM without testing the OOM codepaths is more hopeful fantasy than anything else. (it's just too hard to get right without testing - in some cases in dbus-daemon I had to implement fairly complex "transactions" that could be rolled back, in other cases I had to change the library API to allow e.g. callbacks to signal OOM)

What we're doing in cairo, (only fairly recently, and thanks to Chris
Wilson), is to run cairo's standard test suites but with a valgrind
skin that Chris wrote to progressively inject malloc failures. The
skin is quite general and is described here:

Very nice.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]