Re: Fvwm hangs completely
Hello Dominik, I'm not sure I agree with your conclusion. In my opinion an application, no matter how broken, should never be able to compromise the window manager like this - just like it never should be able to freeze the Kernel itself. The window manager must be able to deal with freaked-out applications. And, in this case, Fvwm seems to be the only one that doesn't. To make sure, I just tried the Awesome WM, and didn't experience any problems with Eclipse at all. I know Eclipse is (and always was) buggy as hell, but Fvwm is badly in need of some fix nevertheless. Regards, Tobias On Tue, Aug 12, 2014, at 21:45, Dominik Vogt wrote: On Sun, Aug 10, 2014 at 10:42:12AM +0200, Tobias Landes wrote: For some time I thought it was a bug in Eclipse, but now I noticed that using no window manager at all makes the problem disappear, Of course this proves nothing. Applications can behave totally differently under different window managers or plain X. Just download any recent version of Eclipse, extract, and start it. Then try dragging a view tab from one place to another inside Eclipse. Fvwm will hang completely, one CPU core running at 100%; I have to switch to a console and kill the Java VM to make things work again. I have a better test that proves that there is a bad bug in Eclipse: * With the recent Java VM and Eclipse downloaded today and the current fvwm from CVS (all Linux, i586, 32 bit, Debian stable). * Use an almost empty config file for fvwm with just this line: destroyfunc ewmhactivatewindowfunc * Start fvwm on some X server. It may be useful to start a separate X server (e.g. :1) for this and run fvwm with something like $ fvwm -d :1 -f configfile * Attach a debugger to fvwm (from a console): $ gdb fvwm fvwm's pid ctrl-c (gdb) continue * Then start eclipse and drag as you described. Fvwm will freeze. * Switch to a console and run top: Eclipse is using 100% cpu. * Now go back to the gdb session and Interrupt fvwm. You'll see that fvwm is waiting for events in its main loop: (gdb) bt #0 0xb70b8458 in select () from /lib/i386-linux-gnu/libc.so.6 #1 0x080eb57c in fvwmSelect (nfds=1024, readfds=readfds@entry=0xbfffce40, writefds=writefds@entry=0xbfffcec0, exceptfds=exceptfds@entry=0x0, timeout=0x0) at fvwmsignal.c:216 #2 0x08072d25 in My_XNextEvent (dpy=0x8a7d7d8, event=event@entry=0xbfffcf70) at events.c:4359 #3 0x08073302 in HandleEvents () at events.c:4220 #4 0x08050f85 in main (argc=optimized out, argv=0xbfffd654) at fvwm.c:2591 Enter (gdb) next to let fvwm wait for the next event. You'll see that no event ever arrives. Conclusion: Eclipse has grabbed the X server or keyboard or mouse and frozen all other X clients (including fvwm). But instead of doing something, it just burns cpu and never releases the grab. I think the whole situation might be related to Eclipse grabbing the X server and then trying to communicate with the window manager under the grab. Of course this won't work because the window manager does not receive any events during the grab. Sample stack trace from Eclipse: -- snip -- #0 0xb77381d4 in __pthread_mutex_unlock_usercnt () from /lib/i386-linux-gnu/libpthread.so.0 #1 0xb6b82980 in g_mutex_unlock () from /lib/i386-linux-gnu/libglib-2.0.so.0 #2 0xb6b428df in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #3 0xb6b42b51 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #4 0x823b7962 in Java_org_eclipse_swt_internal_gtk_OS__1g_1main_1context_1iteration () from /home/luthien/tmp/eclipse/configuration/org.eclipse.osgi/211/0/.cp/libswt-pi3-gtk-4427.so #5 0xb3d7ac66 in ?? () #6 0xb3ddde9c in ?? () #7 0xb3932207 in ?? () #8 0xb3932207 in ?? () #9 0xb3932207 in ?? () #10 0xb393247b in ?? () #11 0xb3932207 in ?? () #12 0xb3932207 in ?? () #13 0xb3d31564 in ?? () #14 0xb3932207 in ?? () #15 0xb3932207 in ?? () #16 0xb3d1f4b0 in ?? () #17 0xb3932207 in ?? () #18 0xb393234f in ?? () #19 0xb3d9ae64 in ?? () #20 0xb5c2d025 in JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () from /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so #21 0xb5d820b9 in os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*) () from /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so #22 0xb5c2bc9f in JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) () from /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so #23 0xb5c69715 in jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) () from /home/luthien/jre1.7.0_67/bin/../lib/i386/client/libjvm.so #24 0xb5c6ffac in jni_CallIntMethodV ()
Last thought
Just one more thing. I'd have no problem in investing my time in discussing in autoconf or automake mailing lists about the changes in man pages paths. But, seriously, what kind of communication can I stablish, for example, with someone that blindly uses right, wrong or new like adjectives for standard? Or with who think standards are about personal taste? Sorry but I won't. I'll start to value my time.
Re: Fvwm hangs completely
Please don't top post on this list and always strip down quoted messages to the required, reasonable context. I'm not sure I agree with your conclusion. In my opinion an application, no matter how broken, should never be able to compromise the window manager like this just like it never should be able to freeze the Kernel itself. The window manager must be able to deal with freaked-out applications. Fvwm *cannot* do anything about it. The X protocol allows applications to freeze the server and does not allow any other clients, including the window manager, to do anything about it. The X protocol also allows applications to flood the window manager with requests so that it cannot do any more reasonable work. I have already spent many hours to make fvwm's event reaction times so low that it can handle events faster than any application can generate them. And, in this case, Fvwm seems to be the only one that doesn't. To make sure, I just tried the Awesome WM, and didn't experience any problems with Eclipse at all. I know Eclipse is (and always was) buggy as hell, I've heard this reasoning *so* many times. So, because Eclipse doesn't run amok on a few other WMs you tried (there are dozens if not hundreds), it must be fvwm's fault? I do not agree. With the same reasoning I could say fvwm works fine with every application except Eclipse, so it's Eclipse's fault. The truth is that one has to analyse what's happening internally, and after I've done that analysis I say: Fvwm does everything right, and Eclipse freezes itself and the X server for unknown reasons. but Fvwm is badly in need of some fix nevertheless. It might be possible to change the events fvwm generates in a way that Eclipse might not freak out anymore, but in the end a window manager cannot code workarounds for each application that does something wrong because there are many, many slightly broken or really broken applications. Sometimes, the application just needs to be fixed. I've spent several hours looking into the problem and could not find anything wrong in fvwm. If you don't believe my analysis, please read up on the internals of the X protocol, or get a second expertise elsewhere. What do you expect me to do now? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Last thought
I'd have no problem in investing my time in discussing in autoconf or automake mailing lists about the changes in man pages paths. But, seriously, what kind of communication can I stablish, for example, with someone that blindly uses right, wrong or new like adjectives for standard? Or with who think standards are about personal taste? The filesystem hierarchy standard is no matter of personal taste of any of the fvwm developers. Please read the current standard and you'll see that man pages (along with other architecture independent data files) have to be installed under .../share. Fvwm does not choose the installation path of its man pages; the default path is set by the version of autoconf used. If you build fvwm with an old version of autoconf, the man pages will be installed in .../man. With a new version they are installed in .../share/man. The documentation in INSTALL.fvwm reflects this. Insofar, any discussion about the man page installation path is off topic on the fvwm mailing lists. I have no opinion on which path is better, but if you do, and you think the path needs to be changend, then the right people to discuss that with are the autotools developers and/or the people maintaining the FHS. If there are mistakes in the documentation or sources of fvwm, I'm happy to take a look and fix anything that needs fixing. But I kindly ask you to stop pointing fingers at people, thus consuming time that could be spent to make fvwm better. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Last thought
On Wed, Aug 13, 2014 at 02:19:11PM +0200, Dominik Vogt wrote: I'd have no problem in investing my time in discussing in autoconf or automake mailing lists about the changes in man pages paths. But, seriously, what kind of communication can I stablish, for example, with someone that blindly uses right, wrong or new like adjectives for standard? Or with who think standards are about personal taste? The filesystem hierarchy standard is no matter of personal taste of any of the fvwm developers. Please read the current standard and you'll see that man pages (along with other architecture independent data files) have to be installed under .../share. Fvwm does not choose the installation path of its man pages; the default path is set by the version of autoconf used. If you build fvwm with an old version of autoconf, the man pages will be installed in .../man. With a new version they are installed in .../share/man. The documentation in INSTALL.fvwm reflects this. Insofar, any discussion about the man page installation path is off topic on the fvwm mailing lists. I have no opinion on which path is better, but if you do, and you think the path needs to be changend, then the right people to discuss that with are the autotools developers and/or the people maintaining the FHS. If there are mistakes in the documentation or sources of fvwm, I'm happy to take a look and fix anything that needs fixing. But I kindly ask you to stop pointing fingers at people, thus consuming time that could be spent to make fvwm better. All what you explain here is intrinsic in what I said, and it was clear from my first post. Are you explaining it to yourself? Don't you have time to read?, don't answer, don't you have time to maintain FVWM?, don't do it, nobody will blame you. The only off topic comment I did here was about the personal mail I've sent you, and *you* forced me to talk here about it. So I kindly ask you to stop blaming others when its all your fault. Again read what others post and think about what you write to not contradict yourself all the time. Nobody should hear in this lists about how you organize your time, your work, your personal email. That's off topic. And remember, two bugs were fixed thanks to your work but principally thanks to *I* reported them and I was very patient with your lack of time to read more than one line per paragraph. Was INSTALL.fvwm bad explained too? Walter PD. You complained about other user here Cc you. Well you've Cc me a lot of times and I didn't complain. Stop considering yourself a victim.
Re: Last thought
On Wed, Aug 13, 2014 at 05:23:59PM +0200, Walter A. Iglesias wrote: don't answer, don't you have time to maintain FVWM?, don't do it, nobody will blame you. Afraid to disagree with you, but actually I've spent more time writing and improving fvwm than you can imagine. Fvwm is by far more my baby than of the original author, Rob Nation, or anybody else; chances are that half of the code you use every day when you use fvwm has been written by me. So, please do not tell me whether I am able to maintain fvwm or not. (My apologies for this showing off to Mikhael, Olivier, Dan, Thomas and all the other people who have contributed to fvwm over the years - there's no intention to belittle your work.) And remember, two bugs were fixed thanks to your work but principally thanks to *I* reported them I do remember that and would prefer to keep any further discussions on a purely technical level: Was INSTALL.fvwm bad explained too? I have still not understood what you think should be changed on top of the changes that are already in CVS. PD. You complained about other user here Cc you. Well you've Cc me a lot of times and I didn't complain. Stop considering yourself a victim. Actually, the fvwm mailing lists have certain unwritten rules that people who have been around here for a while know. One of these rules is to use electronic mail properly. This involves: * Honouring other people's mail headers (reply-to etc.), * not top posting replies, * stripping quoted portions of unnecessary context. Personally, I try to be polite, patient with writers who I find hard to understand, and to stay on topic. While I do not really care if people I hardly know get personal with me or other here whom I know well and with whom I have worked a lot in the past, discussions that focus on pointing fingers eventually do not help to improve fvwm and absorb time that could be spent elsewhere. There has only been very little moderation necessary on the fvwm lists, and the fvwm maintainers would like to keep it that way. This requires that new posters to the list stick to these rules, which are meant for keeping the necessary effort to maintain fvwm as low as possible. I hope you understand this (more or less) subtle hint about the possible consequences of future postings, and kindly ask you again to limit future postings to technical discussions or questions and refrain from getting personal. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
CVS domivogt: * New extended wariables $[wa.x/y/width/heigt] and $[dwa.x/y/width/height]
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt14/08/13 14:59:34 Modified files: . : Tag: branch-2_6 ChangeLog NEWS doc: Tag: branch-2_6 ChangeLog doc/fvwm : Tag: branch-2_6 expansion.xml fvwm : Tag: branch-2_6 expand.c Log message: * New extended wariables $[wa.x/y/width/heigt] and $[dwa.x/y/width/height] They expand to the geometry of the ewmh working area or ewmh dynamic working area.
CVS domivogt: * Clean up NEWS file.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt14/08/13 15:00:36 Modified files: . : Tag: branch-2_6 NEWS Log message: * Clean up NEWS file.
CVS domivogt: * New Resize argument suffixes wa and da.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt14/08/13 15:42:14 Modified files: . : Tag: branch-2_6 ChangeLog NEWS doc: Tag: branch-2_6 ChangeLog doc/commands : Tag: branch-2_6 Resize.xml fvwm : Tag: branch-2_6 move_resize.c Log message: * New Resize argument suffixes wa and da. They refer to the widht/heigt of the EWMH working area and the EWMH dynamic working area.
Re: Last thought
In case there is something on topic (i.e. fvwm) in that message, please please put it in a separate message without any personal comments. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Last thought
Walter A. Iglesias e...@roquesor.com [2014-08-13 22:31:01 +0200]: I will remove myself from this lists right now, Excellent decision Mr. Iglesias. Hope you'll stick by it. Dominik: Thanks again for maintaining and improving fvwm. I suspect I speak for most here in saying that your efforts are greatly appreciated, and hope that experiences like the one you've just been through won't deter you from continuing. Regards, Glenn
Re: Last thought
Hey, time to take this to personal email. Doesn't belong here. This list is public, anything you say here will follow you around. I'm sure you both have good intentions.
Re: Last thought
On Wed, Aug 13, 2014 at 03:53:54PM -0500, des...@verizon.net wrote: Hey, time to take this to personal email. Doesn't belong here. This list is public, anything you say here will follow you around. I'm sure you both have good intentions. Of course you're right, Dan. Walter, if anything I have written has hurt or antagonised you, I want to apologise for that. It is not my intention to embarass you or make you feel bad. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
