cbab

Yup, basically Chrome is using an inverted flame graph (See [1] for additional infos and tools).

[1] https://github.com/brendangregg/FlameGraph

A great book on the subject is "The Art of Debugging with GDB, DDD, and Eclipse" [1].

[1] http://www.nostarch.com/debugging.htm

Very nice concept. Reminds me a lot of my TI-83 graph calculator days with a small dose of Scorched Earth :).

Thanks for reporting your issues on Fedora.

4) We will definitely fix that omission.

5a) liburcu is a dependency of the lttng-ust and lttng-tools. The dependency should be accounted for in the respective Fedora packages.

6) Yes please submit a bug for this at [1]. We will investigate that failure to build on Fedora.

[1] http://bugs.lttng.org/projects/lttng-modules

You can also find all the presentations/publications that we did through the years here [1].

[1] http://lttng.org/publications/

Thanks, we worked quite hard on this new redesign!

edit: Yes, EfficiOS [1] is the open source business behind the LTTng project :).

[1] https://www.efficios.com/

The Userspace RCU [1] library might also be interesting for wait-free linked lists and other RCU aware data structures.

[1] http://lttng.org/urcu/

One of the main technical reason I would say is that CeroWRT has the CoDel[1] queue management enabled by default. See also [2].

[1] http://www.bufferbloat.net/projects/codel/wiki

[2] https://www.bufferbloat.net/projects/cerowrt/wiki/How_is_Cer...

Yes indeed. Encouraging open source contribution, validating that he/she can get stuff done and evaluate culture fit. Win-win-win.

On recent C++ projects, I used the TAP [0] test format. It's quite minimalistic and does the job.

Debugging tools have improved quite a bit. I suggest you take a look at asan [1] for memory related errors. Also, tsan [2] looks very promising for data races detection. I think both tools have been integrated within LLVM/Clang/GCC.

Also, you might want to take a look at tracing tools such as (shameless plug!) LTTng [3] for userspace.

Static analysis tools are quite "en vogue" right now. IMO, nothing comes close to Coverity Scan [4]. It's free for open source projects, but you will have to fork (quite) a bit of money to run this tool on proprietary applications. On the other hand, purely FOSS static-analyzer such as clang-analyzer and cppcheck can catch nasty errors. I would suggest using a mix of all these tools.

[0] http://testanything.org/testing-with-tap/c-plus-plus.html

[1] https://code.google.com/p/address-sanitizer/

[2] https://code.google.com/p/data-race-test/wiki/ThreadSanitize...

[3] http://lttng.org/ust

[4] https://scan.coverity.com/

I respectfully disagree with this. Ignoring return values is _not_ good practice. It is a slippery slope to bad software. By catching these memory errors, a program has the chance to properly teardown and report a message to the user instead of crashing.

Absolutely! Codebases in "franglais" are terrible. Also, when documenting such codebases, I cringe whenever I see public APIs with mixed language members.

or LTTng with both kernel and userspace tracers http://lttng.org

Disclaimer: LTTng developer :)