Latest Tweets

MODEST: Tested on a Real GNU/Linux box!

The “chosen one”

After a long development during these summer work-days, MODEST has been evolved sufficiently so as to be tested on a Real GNU/Linux box.

Thus, I chose a Debian Etch 4.0 installed on an Intel MacBook – first generation -, to execute the tests. This laptop was running a 32 bit GNU/Linux Kernel 2.6.18, compiled as described in the INSTALL file of our MODEST source code.

The gross bug appeared…

Running MODEST I detected an annoying BUG, not previously detected because of the fact  that I was running MODEST all the time inside a Virtual Machine, with relatively non-cpu-peak processes, which, in turn, opened a few files. This way, its FDT was very limited, and there was no way to overgrown upper the NR_OPEN_DEFAULT imposed limit by the GNU/Linux Kernel.

However, running MODEST in a real GNU/Linux box could allow to test it with real programs, like OpenOffice, Gedit, and these sort of processes. It was then: a gross Segmentation Fault message shown up, causing a Kernel OOPS which hanged up the computer entirely!

It ocurred just when I runned umodest tool with the “-i” flag, that is: when I was trying to gather information about the process FDT. I supossed the problem had to be related to the fill_file_information() function and to the fds_info[] data structure, in charge of storing all opened files’ information by the given process, with the well-known upper-limit of NR_OPEN_DEFAULT files.

I was right; in fact, this upper-limit can’t be considered as the maximum number of opened files simultaneously by any process, really. But as far as MODEST is concerned, there’s no need of considering more than NR_OPEN_DEFAULT slots per FDT: it was designed bearing in mind processes running with one, two or three output data files, which fit perfectly in the first NR_OPEN_DEFAULT table positions.

Fixing the BUG

As soon as I realized that, I wrote a trivial code before calling the fill_file_information() routine so that the number of files reported by the given process would never exceeded this upper-limit of NR_OPEN_DEFAULT, which was the culprit  causing the Segmentation Fault Kernel awful message discussed earlier, as shown next:

...
for(ifd=0;ifd<fopened->next_fd && ifd <NR_OPEN_DEFAULT;fill_file_information(ifd , fopened),ifd++);
...

As a result …

Now, MODEST has been running for some days in this GNU/Linux real box, without errors or BUGS. This way, it seems to me that MODEST project could be considered as a stable one, at least for testing purposes and experimental approaches to the FDT, Kernel module programing, and so on. It is quite obvious this project has to evolve more than it does now so as to become useful.

Get the latest MODEST source code changes using the CVS, right HERE.