I wanted to do this for a long time but only now I had the time and
a destop beefy enough to try this. Basically I replaced /usr/bin/gnome-session
by a shell script :
/usr/bin/valgrind --trace-children=yes --log-file=/tmp/valgrind /usr/bin/gnome-session.orig $*
Then logged on in gdm , and checked what happened from an ssh connection
top the box.
The good news:
- logging went through, but it took a few minutes
- everything looked functional though extremely slow
- there wasn't many logs reported by valgrind
The bad news:
- I had to stop the session shortly after the login fully complete
the VM was full (1G of Ram + 500M of swap)
- reports from the logs are a pain to try to analyze.
- one python (rhn applet I suspect) generated a huge log, python-2.3
doesn't seems valgrindable.
I them eliminated all the empty /tmp/valgrind.pid* files, I was left with
reports from oly 25 processes.
First a word of warning, I used the normal optimized code as shipped as
part of Fedora devel (fully up-to-date box for todays version), some
of the optimizations sometimes defeat valgrind so there may be false positive.
I have tried to sort all the reports to gather together what was frequently
reported because all apps went through the same code path, for example
there is an error reported when opening gdk display which is reported like
30 times by various apps. So what I saw most:
- gdk_display_open leading to write(buf) contains uninitialised or
unaddressable byte in __write_nocancel though _X11TransWrite
hard to tell without a debugging lib if the error is a false positive
a lack of initialization gdk_display_open() or within X. Strange thing
is that valgrind report the block as being alloc'ed with calloc()
offending address is 128 bytes inside a block of size 16384
- giop_send_buffer_write in libORBit-2 leading to
Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s)
that time the uninitialized data is 10 bytes inside a block of size 2048
allocated within orbit itself.
- pango read_line raises a strange pthread mutex error:
pthread_mutex_lock/trylock: mutex has invalid owner
in pthread_mutex_lock called by pango_read_line from pango_find_map
Apparently the GStreamer code detects it's running under valgrind and
manage to shut it up :-)
Except those 3 repeated all other the place and consisting of the bulk of
the reports, I have seen errors in:
- /usr/bin/gnome-session: invalid file descriptors,
pango_attr_list_get_iterator uninitialized value.
- /usr/bin/pam-panel-icon: 2 invalid file descriptor, seems the same
as for gnome-session with value 828 too.
- /usr/lib/libwnck: uninitialized values in _wnck_read_icons
- /usr/libexec/gconfd-2: repeated g_strdup of initialized values
from gconf_set_daemon_ior, gconf_get_lock, gconf_object_to_string,
gconf_quote_string, and an fprintf
- /usr/libexec/bonobo-activation-server: uninitialized values in
- gam_server : I got one too :-)
- metacity: uninitialized values in gdk_window_new, gdk_window_resize,
gdk_region_rectangle, gdk_region_subtract, a couple of strange
g_int_equal bugs, meta_display_begin_grab_op, meta_display_end_grab_op
- gnome-terminal: terminal_profile_update and _vte_pty_open
The best way to double check is to do the same trick as I did for
gnome-session, move the original somewhere else, replace it by a script
calling valgrind but without recursion to child on a local copy of the
program in debugging mode.
Enclosed are the data as sorted and recouped for more informations.
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
The "Preferences" menu used to have an icon to launch this application,
but it is missing now. Any ideas what happened?
I'm running KDE 3.2.2 on Fedora Core 2 and have a problem with my menu
items. When I first installed Fedora everything had its icon just in the
right place, but after some upgrading I don't have any icons for
openoffice.org (I reinstalled, but to no avail), KEdit and KWrite are no
longer under Editors, etc. etc.
This is only true for my user account, when I log in to X as root, the
menu is fine.
I already googled around and found that menu items for all users are
stored in /usr/share/applications(/kde)/ and that user specific items
are stored in ~/.kde/share/applnk/, but somehow it seems like there are
some more locations/factors in play, because I still can't seem to find
the openoffice.org items.
Is there maybe a way to have (all) your rpm's recreate the icons they
create at install time? I know I can manually add items, but I would
really like to just have the default items created by the rpm's.
"I got a funny feeling they got plastic in the afterlife" - Beck
I propose that a system/application (which I've chosen to call Critical
Defense Daemon) be developed and integrated into Pfc.
Such a system have the following properties:
- be installed by default, but could be disabled during Anaconda
- kick into action as soon as the presence of Internet connectivity
- reference a central server (group of servers) sending it's distro
- accept of packages vulnerable to attack over the Internet
- check this list against installed package list
- request iptable rules to block such an attack(s) if any installed
packages are vulnerable
- alert the user that said rules were about to be entered into their
firewall, giving the user an opportunity to Cancel
- implement said rules
- if rule implementation failed alert user of failure and give user
option to block all packets except packets outgoing to port 80
- forward user to a detailed or simplified advisory online which
would, among other things give instructions on how to prevent attack, etc.
- would reverse rules once package version has been upgrade to a non
affected version, or user requests that rules be reversed
- check for update advisories at user defined intervals for users
permanently connected to the Internet, and for dial up users do check on
The reason I propose such a system is because over the past up I've
installed a few fresh installs of Windows, and without service packs
installed from cdrom, the machines last approx 20 mins on the net before
they are bogged down my malaware. Such a system would serve as a simple
preemptive move that would protect a Linux desktop from such problems
now, and in the future.
Just an idea
I just had an incident - or almost had - which reminded me that AFAIK
there's no way to receive wall-messages on GNOME (or KDE) unless you
happen to have a terminal open. Developers probably always have a terminal
or a dozen open at any given time but the casual user might not and thus
simply miss a broadcast from root about system going down in 15min (for
example) which could be nasty.
Maybe a job for dbus? Hmm.. I see there are some plans for ACPI-dbus
daemon: http://www.cs.bath.ac.uk/~occ/cgi-bin/ideas#acpi_dbus_daemon but
that's a very special purpose thing and wont help the wall-case (I'm sure
there are other similar cases as well).
- Panu -
I've occasionally run into a situation where I mistake an unfocused
Nautilus window in the background as the focused foreground window. The
window title bar with Bluecurve makes a strong distinction between
focused and unfocused windows, which is great.
However, if you have icons selected in the *unfocused* window, you may
notice that the unfocused icon selection color (that masks the icons,
and becomes the background color of the icon title text) is very close
to the icon selection color in *focused* windows.
The two colors are different, but not by much. I would like to suggest
making the unfocused icon selection color more significantly different
than the focused icon selection color. Perhaps a bit lighter, and gray
instead of blue (like the window title bar change).
I've put together a screenshot illustrating focused and unfocused
Nautilus windows and example swatches of the two colors in question:
I haven't worked on Gnome themes before, but some help and digging
around turned up that this color is easy to change. In my Fedora Core 2
install, the color is on line #36 of the file
I'm experimenting using a gray color (#b5b5b5) for a few days on my own
Depending on feedback to this post (welcome and encouraged), I'll file a
bug (and maybe a patch).
What happened to the package manager, that the first test release of fedora had?
Despite some of the features that weren't working it was a excellent tool, because currently the only tool to deal with the packages is quite limited.
Some features like installing new packages, and being associated with the .rpm in nautilus, the possibility to see the dependencies, or even the files that it brings. Are all thing that can't be done.
Was it totally remove from the plan?
This morning I decided to experiment with the fonts on my FC2 laptop. A
few minutes later, Thunderbird, Firefox, and my desktop look immensely
better by simply switching to Bitstream Vera. Now, I don't want to start
a which-font-looks-better-war, but the default of the generic "Sans" and
"Sans Serif" fonts are pretty terrible and I think that there is no
question that the defaults could be changed to something better.
I had to change the default fonts in three places:
o Preferences/Fonts in GNOME
Is it possible to change the defaults for these apps?
I searched through the archives and there has been some discussion,
although it seemed to center around which font looks best:
Honestly, I don't care, as long as it isn't Sans and Sans Serif ;-).
> Date: Mon, 20 Sep 2004 13:55:09 -0400
> From: Havoc Pennington <hp(a)redhat.com>
> Subject: Re: Changing Gnone desktop font color.
> To: Discussions about development for the Fedora desktop
> Message-ID: <1095702909.28058.23.camel(a)localhost.localdomain>
> Content-Type: text/plain
> On Mon, 2004-09-20 at 00:21 +0100, Fernando Morais wrote:
> > Your program seems very good.
> > I'm going to try it for sure...
> > Regarding the so called wishlist queues, i think that is causing some slow
> > evolution of fedora. The blocking of some basic and really needed features,
> > like the gnome menu editing, is putting fedora some steps behind. If testing
> > versions are always being released why not activate those features, those
> > that are really needed. Everyone knows that they aren't expected to work at
> > 100%.
> Our general policy (for final releases, not test releases) is that if
> something is totally busted it's better to just turn it off. It looks
> worse to have broken functionality than to have missing functionality.
I know - that s why i wonder what up2date is still doing in core...
An option could ofcource be (if it dont have to be compiled out/in) to
make it possible to turn it on (through preferences - or maybe even just
gconf) - and attach a big, fat, and generally ugly warning to the