While I have been using Ubuntu 8.04 LTS (hardy) in my work laptop (for the very same reasons I used dapper for a long time), I knew that some Ubuntu 9.04 (jaunty) users were having problems with icemon (the icecream monitor) not working, i.e., not showing any nodes. I did not investigate the reasons behind this, but a colleague reported that he could successfully make it work by using the older version from intrepid.

So here goes a small how-to on installing the older icecc-monitor version (from intrepid) in jaunty:

1. Download the icecc-monitor .deb package from http://packages.ubuntu.com/intrepid/i386/icecc-monitor/download
2. Install the package with:

$ sudo dpkg -i icecc-monitor_*.deb

3. The step above will successfully install the package, but in a future whole-system upgrade, it will again install the newer (buggy) version. To avoid that, you can tell dpkg to lock the package version, using the following command:

$ echo icecc-monitor hold | sudo dpkg --set-selections

If necessary, you can unlock it anytime using the command:

$ echo icecc-monitor install | sudo dpkg --set-selections

I did not check yet whether this has already been reported to the Launchpad, if anyone knows, feel free to comment.

If you ever come across an error like this when compiling C++ code with Qt derived class definitions:


g++ -Wl,--no-undefined -o test test.o -L/usr/lib -lQtGui -lQtCore -lpthread
test.o: In function `main':
test.cpp:(.text+0x2c): undefined reference to `vtable for MyClass'
collect2: ld returned 1 exit status
make: *** [test] Error 1


It is probably because either you defined a class in a .cpp file or you forgot to add some header file to the HEADERS variable in the .pro file.

This happens because moc (Qt’s meta-object compiler) only runs on header files by default (and only on those listed in the HEADERS variable), therefore it did not generate the necessary MOC code for that class.

The fix is to simply move the class definition to a header, and make sure it is added to the HEADERS variable in the qmake project file.

I used to work on development of a tracing tool at work, that required me reading some glibc code to understand internals of core library functions (following the “Use the source, Luke” Open Source principle for developer documentation). I use Ubuntu, so it seemed simpler to use its glibc sources so I don’t have to recompile glibc myself. Here are the instructions I use for setting up my environment for glibc code navigation (tested on Hardy running on x86):

# gcc 4.2 is required to configure libc6
$ sudo apt-get install build-essential gcc-4.2

# download sources
$ sudo apt-get source libc6
$ cd glibc-2.6.1/

# the "configure_i686" rule also calls other rules that
# unpack the sources and apply distro-specific patches
$ ./debian/rules configure_i686

# create a tags file to easily navigate between functions with Vim
$ cd build-tree/glibc-2.6.1/ && ctags -R --exclude=.pc

I have some items on my TODO list regarding Boomerang. Here they are:

• migrate functional testsuite to DejaGNU (on progress)
• increase test code coverage by writing new tests
• update/fix/extend unit tests

Migration to dejagnu will allow to write more flexible functional tests, such as ones to test for error handling. Right now, Boomerang’s functional testsuite only covers the decompilation phase (as far as I can see), and only covers 48.1% of code (according to gcov/lcov). Next, I plan to increase this coverage percentage by writing new tests (and understanding the code a bit more on the way) and finally, once I start getting hands dirty on coding, I will fix/extend unit tests.

These are my short term plans. Long term plans are (not detailed yet): remove dependency on some (old, unmaintained) third-party tools, such as NJMC toolkit and old bison++/flex++ (this needs to be discussed on the mailing list); reuse code where possible, instead of reimplementing things like the PE/ELF/etc. parsers; make boomerang more modular, possibly allowing to compile it as a shared library (already possible?) or replacing some algorithms; take a look at DCC code (now GPL licensed); experiment with new concepts on the RE/Decompilation research field.

Just saw some good news about Wine approaching 1.0 stable release. It remembered me of how capable Wine is now. Some years ago, I would try running an application under Wine and hope it would at least show something and not crash. Nowadays, when I find some Windows application I need to use, I first try running it under Wine and if it does not work as I like, I fall back to QEMU or VMWare. Hopefully, for most applications I have tried, Wine worked just fine.

Last night I tried enabling coverage in boomerang compilation. It seems it will not be as easy as I thought. Gcov is failing to find source files, although the .gcda and .gcno files are being generated and are on the correct location. Snippet from gcov error:

$ gcov c/ansi-c-parser.gcda -o c -b >/dev/null
ansi-c.y:cannot open source file
/usr/local/lib/bison.cc:cannot open source file
ansi-c-parser.cpp:cannot open source file


In this case the source file is in c/ansi-c-parser.cpp, but it insists on looking for it in the current directory. For this specific case, I figured out the errors are due to #line directives generated by bison++, but there are various errors like this. I’ll look into them at another time. Currently, I’m investigating unexpected errors reported by the functional testsuite (more on this later).

Last weekend I made my first code contribution to the Boomerang project: I fixed some tests from the testsuite that were segfaulting or failing due to changes in the debug output. After sending the patch to the mailing list, I was given write access to their CVS repository so I can now commit my fixes myself .

My plans for now are to:

1. do test coverage analysis on the current code using gcov/lcov
2. if coverage is not acceptable, add more tests to the testsuite
3. when coverage become acceptable (I still need to define the acceptance criterion), I can then starting making improvements or more complex changes to the code

Of course, before doing any big changes that would affect current functionality, I will submit a patch to the list, so other developers can comment on it. That’s the “Open Source way” of development IMHO.

I am about to graduate in Computer Science at Universidade Federal do Amazonas (UFAM), so I think I will now have more time to continue my personal research on some subjects I am interested in, but never found time to continue after I entered college.

One of these subjects is Reverse Engineering (RE). Before entering college, I played a little with RE and started a project on reverse engineering a driver for my scanner. It was quite challenging, and I liked it a lot, but never had time since then to either continue this project or start new ones.

Now it is time to change . During college I developed interest in Artificial Intelligence (IA) and ontologies. This (somehow ) led me to create interest in a research area known as “program comprehension” or “program understanding”. This is a research domain that, in my opinion, includes RE when it is applied to understanding how a system works. Therefore, my focus will be on applying RE techniques for program understanding.

As a first step, I started gathering some domain knowledge, but I would like to make something more pragmatic in parallel, so my studies could have a focus. I decided for now to work with the Boomerang decompiler and make some RE experiments with it. I chose it because It is, to my knowledge, the most advanced Open Source decompiler I am aware of, and decompilers can help understanding programs for which you don’t have sources. Of course, there are some other tools I would like to experiment with, such as Sparse.

I will probably make some kind of schedule so I don’t lose track during my research. More to follow!

Hi all,

After a long period without posts, I’m back to activity Here goes my latest contributions to Open Source projects (mostly as part of my work at INdT):

strace ARM fix: link to post

ltrace fixes:

#450931
#176413
#462530
#462531
#462532
#462533
#462535

apt-cacher “multiple mirrors” bug: #462948

That’s it for now. Expect more patches to come!

Update (2008-03-08): all my ltrace patches were accepted into Debian and applied as of version 0.5-3.1. Of course, it still needs to be applied upstream, but hey, thats good news!

Gostaria de dedicar este breve post a todos os familiares e amigos das pessoas que estavam no vôo 1907 da Gol. Eu pessoalmente conhecia algumas delas e sei a falta que elas farão. Cabe a nós lembrarmos dos bons momentos vividos com as pessoas que amamos e, acima de tudo, tê-las como lições de vida a serem seguidas.

Meu sincero apoio.