[haiku-development] Latest changes and general status.
- From: "Bruno G. Albuquerque" <bga@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 22 Apr 2008 21:40:19 -0300 (BRT)
One of the things I have been doing almost every day is to try to build
Haiku and to track down bugs when I found then. As I mentioned on April
1st, I managed to compile Haiku inside itself but based on all activity
after that it seems it was more out of luck than anything else. Just after
I managed to do that, Axel started working on fixes for memory Tracking
and the block cache problems and after that I was never able to go through
the entire build process again (of course, it was for a good reason. :) ).
Then recently Ingo found and tracked down a bug where our semaphore code
was not really working as expected and ended up doing what seems to be a
complete rewrite of our locking primitives. Well, giving credit where
credit is due, this was probably, at least on my configuration, the single
change in Haiku with the most impact since we actually managed to run
Tracker on it. Not only Haiku feels a lot faster now (compiling it inside
itself seems to be at least one order of magnitude faster) as the last bug
I was still getting (a random mimeset failure while building) is now gone.
I managed, again, to build Haiku (up to a point, see below) inside itself!
The only thing that still fails is when it tries to set the script to copy
all coreutils files to the image. It complains about a missing " somewhere
(I will post a bug about this). Note this bug is not about compiling Haiku
inside itself anymore but probably a syntax problem somewhere probably
related to our bash version.
Anyway, the reason for this email is to list what it seems to still be
preventing Haiku to be usable for use in its own development process:
1 - We still have memory problems. Either we are incorrectly tracking
free/allocated memory or we are leaking memory at a very basic level. Even
unzipping files, which was supposed to use a relativelly constant amount
of memory when being executed, seems to leak around 500 Kb/s when
unzipping the Haiku tree inside itself. The memory is not reclaimed after
it runs which means that the amount of memory used when starting the zip
process is smaller than the amount after running it (I am not considering
caches here at all). The net result of this is that it is impossible to
build Haiku inside itself with less than 1.2 Gb of memory (this is the
peak memory used here when compiling). Swap file support will of course
helps with that, but I really hope we manage to track this down and fix it
before we get that running or it can mask the problem.
2 - I started to get some new KDLs in the block cache after Ingo's
changes. It seems to be easy to reproduce when trying to start firefox
after compiling Haiku inside itself. I will also create a bug about this.
3 - There may or may not be at least one serious BFS bug around. I didn't
really find anything like that (except for the block cache KDL) but others
have reported it.
And that's about it. Of course there are several other bugs or missing
features around, but the ones listed above seem to be the ones really
blocking it.
-Bruno
Other related posts:
