After upgrading xfwm4 to revission 27744 startxfce4 goes into an endless loop which only stops after restarting X. Reverting to a previous version of xfwm4 doesn't cause this bug. I am using Debian/Sid and xfce4 from svn. On my system the bug is reproducible.
startxfce4 is a script, I don't understand what goes into an endless loop. Can you clarify and be more precise please?
...not to mention that 27744 is an update of the PU_BR locale in Thunar: Date: 2008-09-08 00:52:35 +0000 (Mon, 08 Sep 2008) New Revision: 27744 Modified: thunar/trunk/po/ChangeLog thunar/trunk/po/pt_BR.po Log: Updated Brazilian Portuguese translation.
(In reply to comment #0) > After upgrading xfwm4 to revission 27744 startxfce4 goes into an endless loop > which only stops after restarting X. > Reverting to a previous version of xfwm4 doesn't cause this bug. Define "previous version" please. Try different revisions between 27744 and the one that works to find out in which revision the bug was introduced. That would really help.
(In reply to comment #1) > startxfce4 is a script, I don't understand what goes into an endless loop. Can > you clarify and be more precise please? when using the last revision of xfwm4 (r27740), startxfce4 doesn't end with a useful desktop. One of the components of the script keeps reading the disk continuously,preventing running any other program. The panel doesn't apprear. Because I cannot use ksysguard I can't check which is continuously busy. I assume it could be due to xfwm4 because this does't happen when I use xfwm4 revision 27141 (from daily snapshots).
(In reply to comment #3) > (In reply to comment #0) > Define "previous version" please. Try different revisions between 27744 and the > one that works to find out in which revision the bug was introduced. That would > really help. The problem happens when using your last revision 27740. All previous versions didn't show that problem. Now I am using r27141 without problems. Somewhere in the startup the disk is continuously read and has to be stopped by restarting X.
(In reply to comment #5) > (In reply to comment #3) > > (In reply to comment #0) > > > Define "previous version" please. Try different revisions between 27744 and the > > one that works to find out in which revision the bug was introduced. That would > > really help. > > The problem happens when using your last revision 27740. All previous versions > didn't show that problem. Now I am using r27141 without problems. > Somewhere in the startup the disk is continuously read and has to be stopped > by restarting X. Thm, that's weird. Can you try to switch to one of the other virtual terminals and run top or something to see which process eats all the CPU power? I can hardly believe that it's xfwm4 because in 27440 I only merged a few strings and changed the main settings dialog (which normally shouldn't popup when running startxfce4).
> Thm, that's weird. Can you try to switch to one of the other virtual terminals > and run top or something to see which process eats all the CPU power? Top shows a big memory leak: xfwm4 uses almost all available memory (1000MB). After a while the swap disk is also full and then the whole system stops. Very weird indeed!
Have you compiled xfwm4 with --enable-debug=full or something? If so, would you mind to recompile it with --enable-debug=no and try again?
(In reply to comment #8) > Have you compiled xfwm4 with --enable-debug=full or something? If so, would you > mind to recompile it with --enable-debug=no and try again? I compiled with ./autogen.sh --prefix=/usr --enable-debug=no, make, sudo make install using gcc-4.3 (Debian v.4.3.2-1). I downloaded and compiled two times with the same result!
(In reply to comment #8) Now the last version is r27767. I also tried compiling with gcc-4.1, same memory leak. Before revision 27740 there was no such problem, I update svn almost every day! Revision 27141 (from daily snapshots) runs without memory leak.
Can you run xfwm4 from valgrind? You may have to run it from a console and not from within the X session itself (ie switch to a console, kill xfwm4, export DISPLAY and run xfwm4 from valgrind). If something is leaking (and apparently a huge one) you should be able to spot it from valgrind fairly easily. Also, you may try to attach gdb, if the process is looping a backtrace should give an idea of where it's stuck in the code.
(In reply to comment #11) > Can you run xfwm4 from valgrind? > > Also, you may try to attach gdb, if the process is looping a backtrace should > give an idea of where it's stuck in the code. I tried running from valgrind but it didn't give any clue about a mem leak. Meanwhile I have found when things go wrong. I discovered that replacing xfwm4 v.27141 by v.27744 (xfwm --replace) didn't produce the mem leak. Then I killed the running kio_uiserver and closed all programs before exiting the xfce4 session to prevent a new session starting any other program than xfce4. When I restarted the session the kio server was no longer started and xfwm4 did no longer produce the mem leak. But when I start the kio server, then immediately the mem leak appears and top shows xfwm4 using almost all memory. The mem leak also starts when I save a text file from kedit but not from gedit. Somehow the mem leak is caused by the combination of this version of xfwm4 and some K programs.
Humm, I am sorry, that does not make much sense to me. xfwm4 has no relationship with KIO. I would really need valgrind log and and a few gdb bt of the running process.
Created attachment 1809 valgrind xfwm4 log
(In reply to comment #13) > Humm, I am sorry, that does not make much sense to me. xfwm4 has no > relationship with KIO. It is not only about kio, but everytime a file is saved from kedit or copy with krusader etc., xfwm4 starts a mem leak. > > I would really need valgrind log and and a few gdb bt of the running process. I am sorry but I don't know about gdb bt, what's that? I have sent a valgrind log but I can only run valgrind when there is no mem leak.
(In reply to comment #15) > I am sorry but I don't know about gdb bt, what's that? You can attach gdb to a running process, for example: gdb $(which xfwm4) -p $(pidof xfwm4) ... attaching to running process xxxx ... (gdb) bt => That will generate a backtrace, showing what xfwm4 is doing at the time. With a bit of chance, we might be able to spot what is teh code path used. > I have sent a valgrind log but I can only run valgrind when there is no mem > leak. Indeed, the valgrind log shows no real leak. You need to run these tests from a console, and not from X otherwise your environment will freeze and you will not be able to enter any command.
Created attachment 1810 valgrind xfwm4 log I managed to run valgrind in a console during mem leak.
I do not see anything suspicious in that log.
(In reply to comment #18) > I do not see anything suspicious in that log. But there was definitely a memory leak! The memory leak occurs only when the compositor is on. Tomorrow I will try gdb. (As I am in China, it's already very late now!) Is there a log file from gdb? I never have used this program.
Created attachment 1811 gdb bt output This is the gdb bt output from xfwm4 (with compositor on) running without mem leak.
Created attachment 1812 gdb bt output This is the gdb bt output of xfwm4 (compositor on) running with memoriry leak
Is there enough information in the gdb logs? If you need more I can compile xfwm4 with debug=yes and try gdb again.
I appreciate your help and the time you spend with this. Unfortunately the binary is stripped, ie the debugging symbols have been removed from the executable thus the backtrace gives just addresses and no function name (which is not usable as is). Compiling with "debug=full" will produce a *lot* (and I really mean a *lot*) of debugging info. What I would suggest first is to try without stripping the binary (ie make install, not make install-strip) and if that does not help, then try with debug=full.
So just to make it sure, the issue arises only with - kde apps running - with the compositor enabled What version of kde are you using? (that would really help if I could reproduce this).
(In reply to comment #23) > Compiling with "debug=full" will produce a *lot* (and I really mean a *lot*) of > debugging info. What I would suggest first is to try without stripping the > binary (ie make install, not make install-strip) and if that does not help, > then try with debug=full. I never use make install-strip! I compile using autogen.sh --prefix=/usr --enable-debug=no (yes or full) && make && make install. Now I have tried gdp xfwm4 after having compiled with --enable-debug=yes and also with --enable-debug=full but I always get the same stripped backtrace. How to disable stripping? I am not used debugging, maybe I am missing something.
No worries, I understand what is going on, the latest backtrace shows the event received had a size of 32767x32767.
(In reply to comment #24) > So just to make it sure, the issue arises only with > > - kde apps running > - with the compositor enabled > > What version of kde are you using? (that would really help if I could reproduce > this). Up to now the issue only arises with the compositor enabled and writing to disk with some KDE apps. I am using Debian/sid KDE v.4:3.5.9.dfsg.1-5, Launch KDE and Gnome services on startup enabled, and save session on logout. Everytime a file is saved from kedit, kwrite, or copy some file with krusader file manager, xfwm4 starts a mem leak. When kio_uiserver (which is started by KDE apps) is started at login, then it also happens at startup. On my system it is reproducible. I checked this by using gedit, mousepad and thunar and it never went wrong.
Just for clarification, this is not a memory leak. Technically, a memleak is when an application continuously allocate new memory as it needs it, w/out never releasing it. Here, it's simply an application that sets it size to the maximum value applicable and the window manager tries to build an image will be too large for the system to handle. Can you update to the latest svn trunk (rev. 27803 at least) at try if it works?
(In reply to comment #28) > Just for clarification, this is not a memory leak. Technically, a memleak is > when an application continuously allocate new memory as it needs it, w/out > never releasing it. > > Here, it's simply an application that sets it size to the maximum value > applicable and the window manager tries to build an image will be too large for > the system to handle. > > Can you update to the latest svn trunk (rev. 27803 at least) at try if it > works? I just updated to r27803 and performed some tests. No more problems, it works as it should work! Thank you very much.