thos – Page 7 – Thomas Wood

OHMan

“Hi, my name is OHMan. Keep me close and I will help.”

Opkg Memory Cleanup

Last Friday I decided to use Valgrind to check the memory usage in opkg and discovered that it was leaking quite a substantial amount of memory.

Over the last two and a half days I’ve been fixing all the memory leaks exhibited by running my libopkg_test application. I have reduced the directly lost and indirectly lost memory to 0 bytes. The reachable memory at exit has been reduced to 29kB (down from ~13MB), with the remaining blocks belonging to libgpgme and libcurl which does not appear to be freed by their
respective de-initialisation routines.

Having had such a detailed look at the code, I am fairly certain further optimisation work is possible in terms of both memory usage and speed.

Some interesting statistics:

I’ve add some 65 additional free and deinit statements
… of which 52 are additional free() calls alone
18 files changed, mostly in libopkg, but also one in libbb
There where a total of 184 lines inserted and 25 lines deleted in the full diff

I used Valgrind’s memcheck tool to help identify the leaks and massif to visualise the memory usage. It seems the Valgrind authors have remove the postscript output from massif in favour of an ascii chart. I’d be interested if anyone knows a way to display the massif output in a more graphical (non-ascii) way.

N.B. The scales on the two graphs are different, so be sure to read the axis when comparing!

Before the cleanup…

 ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 67 from 1)
 malloc/free: in use at exit: 14,808,479 bytes in 577,152 blocks.
 malloc/free: 1,145,825 allocs, 568,673 frees, 1,444,779,097 bytes allocated.
 For counts of detected errors, rerun with: -v
 searching for pointers to 577,152 not-freed blocks.
 checked 12,358,812 bytes.

 LEAK SUMMARY:
    definitely lost: 611,971 bytes in 40,899 blocks.
    indirectly lost: 1,425,560 bytes in 83,798 blocks.
      possibly lost: 183 bytes in 7 blocks.
    still reachable: 12,770,765 bytes in 452,448 blocks.
         suppressed: 0 bytes in 0 blocks.

    MB
22.73^                                                   #                    
     |                                                  @#                    
     |                                                @ @# :                 .
     |                                              ,@@ @# : :   :. : . .. :::
     |                                            , @@@ @# : :,: :: : : :: :::
     |                                           ,@ @@@ @# : :@: :: : : :: :::
     |                                         , @@ @@@ @# : :@: :: : : :: :::
     |                                        @@ @@ @@@ @# : :@: :: : : :: :::
     |                 ,                     .@@ @@ @@@ @# : :@: :: : : :: :::
     |                @@.                  . :@@ @@ @@@ @# : :@: :: : : :: :::
     |              .@@@:                  : :@@ @@ @@@ @# : :@: :: : : :: :::
     |            . :@@@: :     ..@      .:: :@@ @@ @@@ @# : :@: :: : : :: :::
     |           @: :@@@: ::. . ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
     |          @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
     |        , @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
     |       .@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
     |     : :@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
     |    .: :@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
     |    :: :@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
     |  : :: :@ @@: :@@@: ::: : ::@ : : :::: :@@ @@ @@@ @# : :@: :: : : :: :::
   0 +----------------------------------------------------------------------->MB
     0                                                                   73.83

Number of snapshots: 53
 Detailed snapshots: [6, 7, 8, 11, 12, 13, 21, 30, 31, 32, 33, 34, 35, 36, 37, 38 (peak), 41]

The two peaks in the graph represent the parsing of the repository data into a hash table. In my test application, the repository data is updated from the feeds, so the package lists are re-parsed. Previously, the main de-initialisation procedure for opkg (which, I hasten to add, was inherited from ipkg) did not free the hash table of packages properly, which meant every time the package list was refreshed, the entire hash table of packages would be leaked. Had a user refreshed the package list several times in one session, it’s likely the device would very quickly have run out of memory.

After the cleanup…

 ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 65 from 1)
 malloc/free: in use at exit: 29,064 bytes in 2,013 blocks.
 malloc/free: 1,145,726 allocs, 1,143,713 frees, 1,443,951,146 bytes allocated.
 For counts of detected errors, rerun with: -v
 searching for pointers to 2,013 not-freed blocks.
 checked 390,804 bytes.

 LEAK SUMMARY:
    definitely lost: 0 bytes in 0 blocks.
      possibly lost: 0 bytes in 0 blocks.
    still reachable: 29,064 bytes in 2,013 blocks.
         suppressed: 0 bytes in 0 blocks.
 Reachable blocks (those to which a pointer was found) are not shown.
 To see them, rerun with: --leak-check=full --show-reachable=yes


    MB
13.04^             #                                 .                        
     |             #                                 :                        
     |            :#                                ::                        
     |           .:# @                             ::: :                      
     |           ::# @                            .::: :.                     
     |          @::# @    . ..                    :::: ::  .. ,.     ,:       
     |         :@::# @:  .:@::  :                ::::: :@  :::@:   .:@:.      
     |        .:@::# @: .::@:::::.              .::::: :@. :::@::::::@::      
     |       ,::@::# @: :::@::::::             .:::::: :@: :::@::::::@:::     
     |       @::@::# @: :::@::::::.            ::::::: :@: :::@::::::@::.     
     |      ,@::@::# @: :::@:::::::           .::::::: :@: :::@::::::@:::     
     |     ,@@::@::# @: :::@:::::::.         .:::::::: :@: :::@::::::@::::    
     |     @@@::@::# @: :::@::::::::         ::::::::: :@: :::@::::::@::::.   
     |    .@@@::@::# @: :::@::::::::         ::::::::: :@: :::@::::::@:::::   
     |    :@@@::@::# @: :::@:::::::::      . ::::::::: :@: :::@::::::@::::::  
     |    :@@@::@::# @: :::@:::::::::.     : ::::::::: :@: :::@::::::@:::::.  
     |   ::@@@::@::# @: :::@::::::::::     : ::::::::: :@: :::@::::::@::::::, 
     |  .::@@@::@::# @: :::@::::::::::    :: ::::::::: :@: :::@::::::@::::::@ 
     |  :::@@@::@::# @: :::@:::::::::::  .:: ::::::::: :@: :::@::::::@::::::@:
     | ,:::@@@::@::# @: :::@:::::::::::. ::: ::::::::: :@: :::@::::::@::::::@.
   0 +----------------------------------------------------------------------->MB
     0                                                                   94.44

Number of snapshots: 76
 Detailed snapshots: [1, 5, 6, 7, 10, 13 (peak), 14, 19, 32, 47, 53, 63, 73]

Code cleanup in default-applications capplet

I’ve just committed a patch to the default-applications capplet that converts it to use GConfPropertyEditor. This removes a lot of duplicated code within default-applications:

$ svn diff -rPREV gnome-da-capplet.c | diffstat gnome-da-capplet.c | 1029 ++++++++++++++--------------------------------------- 1 file changed, 277 insertions(+), 752 deletions(-)

If anyone is currently running gnome-control-center from SVN, I would appreciate any extra testing on the default-applications capplet to ensure than no unexpected behaviour has been introduced.

Applying the GPL to Artwork

As art.gnome.org contact, I often get questions about whether someone can use GNOME some icons in their project. Most of the time I have said please contact the author, but I would like to try and work out an agreed interpretation of the GPL for artwork.

I’ve started a thread on gnome-themes-list, and would be grateful if people (especially any lawyer types) could give any more insight.

N800 + 160GB hard drive

My bother recently told me he had connected his 160GB external hard drive to his N800, and now he’s written a short tutorial on how to do it.

I’ve always wanted to try a USB keyboard on my n800, so looks like I need to get him to make me one of those cables. Yes, I’m sure you can buy them somewhere, but I love Heath Robinson style electronics

OpenMoko Wifi Driver

I totally missed this until now, but my colleague, Samuel Ortiz, wrote up some information about implementing the Wifi driver for OpenMoko:

http://labs.o-hand.com/2008/02/05/openmoko-wifi-driver/

I’m pleased to say that during my own testing I had no problems and it even works with WPA encryption. Good job Samuel!

New Wallpapers for GNOME 2.24

I was hoping to refresh the set of wallpapers in gnome-backgrounds for GNOME 2.24. Cimi thought this was such an excellent idea, he jumped the gun and set up a contest: http://www.cimitan.com/contest/. I’m not such a big fan of contests, since the “issues” we had with the splash screen contests in the past. However, I think this time we may have hit on a good solution to the past issues.

I want to keep the quality and usability of gnome-backgrounds high, so please do read the style rules if you are thinking of submitting an entry. We’ve had some great submissions so far, but definitely could do with more options!

The runners up will take pride of place on the new art-hub, which will replace art.gnome.org.

OpenMoko FreeRunner LEDs, etc.

Before I took my FreeRunner prototype along to Ole’s OpenMoko talk in London yesterday, I hacked up a little demo application in python/pygtk to display various new features in the FreeRunner (Wifi, accellerometers, LEDs). If you where there yesterday, you probably saw this live in action:

On my previous post OpenMoko post, someone asked about the LEDs on the FreeRunner. Obviously, you can’t see any proof of the LEDs in screenshots, so I took some very quick photographs:

Author: thos