FreeLists / haiku-development / [haiku-development] Re: Latest changes and general status.

["Salvatore Benedetto" <emitrax@xxxxxxxxx>]

On 23/04/2008, Bruno G. Albuquerque <bga@xxxxxxxxxxxxx> wrote:
> 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.

After reading this two things come two my mind.
1 - Coverity might help.
2 - Memory documentation like the one Zhao wrote would help with this
as well. As more people would be able to read the memory code. 4 eyes
are better than 2! :)

>
>  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
>
>
>

Regards,
-- 
Salvatore Benedetto (a.k.a. emitrax)
Student of Computer Engineer
University of Pisa
www.haiku-os.it