maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)
-   -   [ANNOUNCE]Alarm UI replacement (https://talk.maemo.org/showthread.php?t=87823)

freemangordon 2012-11-16 13:38

Re: [ANNOUNCE]Alarm UI replacement
 
Quote:

Originally Posted by reinob (Post 1294928)
in size_request_cb()

according to http://developer.gnome.org/pango/sta...rocessing.html, the object returned by pango_context_get_metrics has to be freed by the caller (pango_font_metrics_unref).

This is not the case. You can do it right after calculating "height".

Nice catch, thanks. Will fix that ASAP and will upload the new version in -devel repo.

Meh, I wonder how is that possible, less than 1000 lines of code and so much bugs :(

reinob 2012-11-16 14:00

Re: [ANNOUNCE]Alarm UI replacement
 
Quote:

Originally Posted by freemangordon (Post 1294938)
Meh, I wonder how is that possible, less than 1000 lines of code and so much bugs :(

Well, that's what you get with code using thousands of libraries, where each function uses (directly or indirectly) malloc() all over the place. Freeing unnecessary memory *at the time when it makes sense* it extremely hard.

People using java or such languages just ignore the problem, generally causing memory bloat but with a not-my-problem-just-buy-more-RAM-attitude.

People using C have to know exactly what they're doing *when they are writing the program*. If you debug something afterwards you end up like you (and me now) trying to figure out possible/plausible memory leaks, without really having the "static" overview that one would have (had) while writing the program.

I'll see if I can find other stuff, but you'll never achieve that 100%-certainty feeling that the program has no leaks (not to speak about the various libraries it uses..)

reinob 2012-11-16 14:03

Re: [ANNOUNCE]Alarm UI replacement
 
another one (not a leak but a source of getting a segmentation fault).

In gboolean alarm_snooze() you have

Code:

struct alarm *a;

a->snooze_timeout_tag = 0;

do I need to make it more explicit? :)

freemangordon 2012-11-16 14:11

Re: [ANNOUNCE]Alarm UI replacement
 
@reinob - I know pretty well what you mean. Though my question was more something like "Who TF has allowed that guy to write code in such important OS daemon? Who and how reviewed and tested that?" :)

Well, there is a way, I am going to use some heavy weaponry today. I hope valgrind works on n900 as it is supposed to ;).

BTW I have the feeling that alamUI is not the only systemui plugin to leak memory. And that systemUI is not the only daemon to leak. Otherwise I can't explain to myself increasing swap usage (at least here) over the time.

freemangordon 2012-11-16 14:16

Re: [ANNOUNCE]Alarm UI replacement
 
Quote:

Originally Posted by reinob (Post 1294948)
another one (not a leak but a source of getting a segmentation fault).

In gboolean alarm_snooze() you have

Code:

struct alarm *a;

a->snooze_timeout_tag = 0;

do I need to make it more explicit? :)

LOL!!! Now, who allowed me to write code in such important daemon :D

peterleinchen 2012-11-16 14:21

Re: [ANNOUNCE]Alarm UI replacement
 
Quote:

Originally Posted by freemangordon (Post 1294951)
BTW I have the feeling that alamUI is not the only systemui plugin to leak memory. And that systemUI is not the only daemon to leak. Otherwise I can't explain to myself increasing swap usage (at least here) over the time.

Yes, mee too.
My swap usage is increasing day by day. If I would not have extended size of swap on SD it would fill up completely (almost ;)).
Thanks for investigating!

freemangordon 2012-11-16 14:42

Re: [ANNOUNCE]Alarm UI replacement
 
New version pushed in CSSU-devel repo with fixes for the last spotted bugs.

@reinob - lots of thanks pal.

reinob 2012-11-16 17:32

Re: [ANNOUNCE]Alarm UI replacement
 
Quote:

Originally Posted by peterleinchen (Post 1294957)
Yes, mee too.
My swap usage is increasing day by day. If I would not have extended size of swap on SD it would fill up completely (almost ;)).
Thanks for investigating!

Just coded this (perl) on the way home. It checks every $INTERVAL seconds and reports changes (positive or negative, above $THRESHOLD) in the memory use (VSZ output from ps) of a list of daemons (edit the file to add/delete some more).

Initial version, it works, but there's a lot we can do starting from this:

Code:

#!/usr/bin/perl

use strict;
use warnings;

my @watch = (
    "/sbin/dsme",
    "/sbin/dsme-server",
    "/usr/bin/pulseaudio",
    "/usr/bin/Xorg",
    "/usr/bin/dbus-daemon",
    "/usr/bin/systemui",
    "/usr/bin/hildon-status-menu",
    "/usr/bin/hildon-home",
    "/usr/bin/hildon-desktop",
    "/usr/sbin/browserd"
);

my %initial = ();

# percentage VSZ has to change to report
my $THRESHOLD = 0.0;

# will check once every $INTERVAL seconds
my $INTERVAL = 4;

while(1) {
    my %current = ();

    open(FH, "ps -eo vsz,command |");

    while(<FH>) {
        chomp;
        my @fields = split;
        my $vsz = $fields[0];
        my $cmd = $fields[1];
   
        # print "vsz($vsz) cmd($cmd)\n";

        foreach my $daemon (@watch) {
            if($daemon eq $cmd) {
                    $current{$cmd} += $vsz;
                }
        }
    }

    if(%initial) {
        foreach my $daemon (keys %current) {
            my $vsz0 = $initial{$daemon};
            my $vsz1 = $current{$daemon};

            my $mvar = (100.0 *($vsz1 - $vsz0)) / $vsz0;

            if(abs($mvar) > $THRESHOLD) {
                    my $sign = "+";
                   
                    if($vsz1 < $vsz0) {
                        $sign = "-";
                    }
                   
                    my $now = localtime;
                    print "[$now] $daemon, $vsz0 -> $vsz1 ($sign)\n";
            }
        }
       
        # remove next line if absolute (from start) values are wanted
        %initial = %current;
    } else {
        print "Initializing..\n";
        %initial = %current;
    }

    close(FH);
    sleep($INTERVAL);
}


freemangordon 2012-11-16 19:30

Re: [ANNOUNCE]Alarm UI replacement
 
@reinob - this script need busybox-power, ain't?

However, I would say that for now it seems alarmui does not leak anymore. On the other hand swipe unlock (aka tklock) systemui plugin seems to leak 48k on 2-3 unlocks :(

Unfortunately there is no x86 binary, only ARM, so I am not sure I want to start REing that. A rewrite might be much easier to be done than RE.


EDIT:
Code:

apt-cache show osso-systemui-tklock
Package: osso-systemui-tklock
Priority: optional
Section: misc
Installed-Size: 76

Please someone with better english/soft skills than mine send her an email asking for some help. Lets hope email is still valid

EDIT2:
I removed the email, google is watching us :). Get it by executing apt-cache show on your device

reinob 2012-11-16 19:56

Re: [ANNOUNCE]Alarm UI replacement
 
Quote:

Originally Posted by freemangordon (Post 1295049)
@reinob - this script need busybox-power, ain't?

Don't know. Didn't check if ps -e -o field1,field2 works on stock busybox. Anyway, it's not like I plan to put it in extras or something :)

Quote:

However, I would say that for now it seems alarmui does not leak anymore. On the other hand swipe unlock (aka tklock) systemui plugin seems to leak 48k on 2-3 unlocks :(

Unfortunately there is no x86 binary, only ARM, so I am not sure I want to start REing that. A rewrite might be much easier to be done than RE.
I have no experience with RE on ARM (maybe it's about time! :), and 48k doesn't sound like much. I think hildon-desktop and hildon-home may be better targets. If I ever have a whole week off (no work, no family :) I'll see what I can do..


All times are GMT. The time now is 11:45.

vBulletin® Version 3.8.8