Could this be caused by the same issue haunting OpenOffice. Where OO is launching and then receiving a shutdown from the session-manager, probably because OO takes too long to launch for the liking of the session-manager. This looks like a crash since OO comes up and disappears right away again, but it actually isn't. OO is just doing what the session-manager is asking it to do. There is a bug (issue?!?) in the OO-bugzilla about this: http://www.openoffice.org/issues/show_bug.cgi?id=4494 I solved my OO problem by adding 'unset SESSION_MANAGER' to the OO-launch-script. Hope this helps, -A. su, 18-08-2002 kello 20:04, Ali Akcaagac kirjoitti: > > hi, > > today i have detected some more or less strange behaves with gnome in > general that should not happen. let's have this scenario here. i am > running gnome 2.0 normally without any serious problems and trying to > compile kde 3 cvs head in a console with the --enable-final configure > parameter. the --enable-final parameter is known to merge all the > sources into one big source file and compile that one. it's also a > known fact that it eats much memory. now my system has 256 mb physical > ram and 256 mb swap mem. now while gcc is working to get the kde stuff > compiled in the background i see how the memory getting filled and the > swap memory is beeing used. i wanted to clearify this only to let you > know that this is no memoryleak. it's a forced and correct behaviour. > kde was choosen here because of an example only. i need it for testing > issues etc. > > now what has this to do with gnome after all ? > > the problem is as soon as the swap memory starts to fill (the compile in > the background continues without any problems) and the harddisk where > the swap is located starts to scratch then nautilus kills itself and > restarts (i think you call it respawning). i also detected while trying > to rescue me from this beeing to happen that sometimes even gnome- > terminal or the panel shut down. the compile in the background continues > normally because there is still a lot of memory free (over 100mb mixed > in swap or physical). my question here is i don't see the point for > nautilus to shutdown and restart everytime. > > nautilus was started already and the memory was allocated and i don't > see the point why it does this. there is also no dialog that tells me > about a serious crash (segfault) or something it only quits and starts > again. now you can imagine that having a heavy compile in the background > and having the swap activity of the hardisk and having nautilus > respawning all the time that this is slowing the system down totally. > > i also don't see the point for the panel to shut down or the terminal to > close since all their memory is allocated already. nongnome applications > like gkrellm or some other stuff still works like a charm. the only > solution i found myself from the annoying and really harddisk scratching > behave of natilus' respawning was to shut down gnome completely. after > this was done the system worked again in full speed not because of the > free'd memory. it's because of getting rid of the restarting tries of > nautilus. > > it loads, the nautilus window comes up, then it kills itself again and > restarts, the dialog comes up and it kills itself again... and so on. > > now after i switched to console and killed gnome i restarted it again > normally and realized that all my preferences got killed. i had the > default nautilus icons on my desktop, the panel was empty etc. > > this seriously should not happen. i doubt that gnome was ever tested > under heavy systemload and heavy activities of the disk. since i don't > know if this is a general nautilus issue or if this is a gconf specific > issue (by signaling some stuff to the app) i don't know where to report > this kind of behaviour and choosed the mailinglist for this. generally > there is a need to test the applications under heavy systemload. > > summarized again only for reminding: > - 256 mb physical ram. > - 256 mb swap ram. > - system starts to map the ram to the swap space due to some background > tasks. > - still enough memory free (100 mb for swap and physical differently > spread) > - nautilus shuts down and respawns, window pops up kills itself again > pop up again kills itself etc. without error without segfault etc. > (sometimes rarely even gnome-terminal and gnome-panel shuts down) > - this behaviour slows the system down totally because by reloading > nautilus all time again (and having background compile and having > swap activity of the disk in general) > - a kill of gnome was the only solution after restart all prefs gone. > > oki there are several ways to solve this issue some of you would > probably reply: > > - don't compile kde. > - get more ram. > - don't start nautilus. > - start nautilus without respawning. > - .... > > but the point here is first, why does the apps shut down at all, > nautilus wasn't used during that time not even started only the > desktoppainter, no activty on the panel or in the gnome-terminal. a > stable system that has all it's apps running but in 'idle' state should > not shut down, specially not if there is still ram free. the correct > behaviour of these apps would be trying to map the ram to the swapspace > if it goes in critic conditions and swap around (on worst case for many > minutes) but should not fail. only if the ram really exceeds then it > should crash or exit correctly. > > -- > Name....: Ali Akcaagac > Status..: Student Of Computer & Economic Science > E-Mail..: mailto:ali akcaagac stud fh-wilhelmshaven de > WWW.....: http://www.fh-wilhelmshaven.de/~akcaagaa > > _______________________________________________ > gnome-devel-list mailing list > gnome-devel-list gnome org > http://mail.gnome.org/mailman/listinfo/gnome-devel-list -- Aschwin van der Woude Open Source Specialist Creanor Oy (www.creanor.com) Mob. +358 50 5676665 Tel. +358 9 8567 6400 "Good management with crappy products will beat crappy management with good products every time" -- Bob Young PGP Fingerprint: 55AB 3F70 6C6F C345 A3AC D7A1 F2FF C586 EB04 ABDE Public key ID: 1024D/EB04ABDE Keyserver download: http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xEB04ABDE
Attachment:
signature.asc
Description: PGP signature