Re: CVS dane: * fvwm/events.c (HandlePropertyNotify): Disable prior fix suspected of causing
Sorry about the inadvertent reply all. Thanks for your responsiveness. Upstream FVWM has reverted the fix that causes the MR gimp crash.
Re: CVS dane: * fvwm/events.c (HandlePropertyNotify): Disable prior fix suspected of causing
Upstream FVWM has reverted the fix that causes the MR gimp crash. Jonathan -Original Message- From: c...@math.uh.edu [mailto:c...@math.uh.edu] Sent: Saturday, November 09, 2013 11:21 AM To: fvwm-workers@fvwm.org Subject: CVS dane: * fvwm/events.c (HandlePropertyNotify): Disable prior fix suspected of causing CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: dane13/11/09 11:20:50 Modified files: . : Tag: branch-2_6 ChangeLog fvwm : Tag: branch-2_6 events.c Log message: * fvwm/events.c (HandlePropertyNotify): Disable prior fix suspected of causing problems.
Re: fvwm frees invalid pointer
I'm prone to think that all my recent crashes are caused by the same single problem. Playing the binary search game suggests an issue came in sometime between 2.6.3 and 2.6.4. Then again, my reproduction procedure is a little shaky, so that might be a bad datapoint. Valgrind has been exceptionally unhelpful for me, except to say that the same pointer was freed twice. Based on my binary search, right now I'm eying a change in events.c between 2.6.3 and 2.6.4. Jonathan
Re: fvwm frees invalid pointer
Repeat-By: I am not sure, but the problem seems to appear after I have switched my locale from ru_RU.KOI8-R to ru_RU.UTF-8. I can reproduce this problem using GIMP (which also changes the titlebar content after you save the file). I agree that the locale seems to have something to do with the issue -- I wasn't able to reproduce the issue until I set the LC_CTYPE variable. In addition to Russian, using ja_JP.UTF-8 also causes the issue. Jonathan
Unexplained FVWM exit
Hello everyone - have any of you seen this exit of FVWM? #0 0x0083d066 in exit (status=1) at exit.c:99 #1 0x0808e768 in CatchFatal (dpy=0x8315740) at fvwm.c:1482 #2 0x00b1f797 in _XIOError (dpy=0x8315740) at XlibInt.c:1618 #3 0x00b1e055 in _XReply (dpy=0x8315740, rep=0xffa515f0, extra=0, discard=1) at xcb_io.c:707 #4 0x00b1982d in XSync (dpy=0x8315740, discard=0) at Sync.c:44 #5 0x080ec3ef in MyXUngrabServer (disp=0x8315740) at Grab.c:51 #6 0x0807062a in HandleMapNotify (ea=0xffa516e8) at events.c:2849 #7 0x0806ca2c in dispatch_event (e=0xffa5172c) at events.c:4124 #8 0x0806d208 in HandleEvents () at events.c:4168 #9 0x08091c2b in main (argc=value optimized out, argv=0xffa520c4) at fvwm.c:2591 I have a feeling this is actually an issue buried deep within libX11 or the X-server itself, but I thought I'd ask to see if anyone else had seen it. Thanks in advance for any thoughts/advice. Jonathan
Re: Unexplained FVWM exit
Give more information about what you were doing, and how to reproduce the crash, etc. Unfortunately, “how to reproduce” involves 10 computers sitting around running an test suite for an entire week. If you're interested, I could share the test suite, but let's just say that reproduction is painful. I've been hunting for this for a while, and finally got it to happen while gdb was attached with a breakpoint on exit. The quick explanation of the test suite is that a LOT of windows are being mapped and unmapped, while the CPU is under heavy load. I do have a core file, so if there are any specific variables of interest, let me know. Thanks, Jonathan
Re: FVWM Patch for Interaction problem with Java 7
I'm happy to commit, providing I understand what it was for and why I suggested the change; it was almost a year ago, after all. Yeah, I am pulling this topic out of cold storage. Sorry about that. Besides the link that I just sent out, the other key piece of the conversation is probably this email: http://www.mail-archive.com/fvwm-workers@lists.math.uh.edu/msg15641.html It was a pretty short e-mail chain; I suggested just commenting out/deleting a chunk of code (which is understandably less than ideal), and based on feedback I converted the patch to a bug opt. The third iteration is the patch involving FP_IS_LENIENT that you (Thomas) suggested. Let me know what you think. Thanks, Jonathan
FVWM Patch for Interaction problem with Java 7
Greetings,
I've spent the past few days hunting down a bug that involves an
interaction between FVWM and Java 7.
I can provide more detail for anyone who is curious, but here are the
key points:
a)Java version 7 creates a special FocusProxy window to get
keyboard input. See
http://www.docjar.com/html/api/sun/awt/X11/XFocusProxyWindow.java.html
b)frame.c contains a work around and a comment that begins with the
fated phrase For some reason.
It seems like there was a bug in a ~1999 X server that doesn't
exist in 2012 era Xorg.
c)The code in frame.c takes focus away from java's Focus Proxy
window and gives it to a java window
that doesn't know what to do with keyboard input.
I'm including a proposed patch (very simple - comment out the hack from
1999) as well as java code that can be used to reproduce the issue.
Let me know if you have any thoughts.
Thanks and best regards,
Jonathan
=
diff -urNp fvwm-2.6.4/fvwm/frame.c fvwm-2.6.4-javafix/fvwm/frame.c
--- fvwm-2.6.4/fvwm/frame.c 2011-10-15 05:34:28.0 -0500
+++ fvwm-2.6.4-javafix/fvwm/frame.c 2012-04-11 16:54:25.090804806
-0500
@@ -1938,14 +1938,25 @@ void frame_free_move_resize_args(
}
update_absolute_geometry(fw);
frame_reparent_hide_windows(Scr.NoFocusWin);
- if (mra-w_with_focus != None)
- {
- /* domivogt (28-Dec-1999): For some reason the
XMoveResize() on
-* the frame window removes the input focus from the
client
-* window. I have no idea why, but if we explicitly
restore
-* the focus here everything works fine. */
- FOCUS_SET(mra-w_with_focus);
- }
+
+ /* JPS: 11-Apr-2012: The code which is now commented out was
introduced
+* in 1999 with the following comment:
+*
+* For some reason the XMoveResize() on the frame window
removes
+* the input focus from the client window. I have no idea
why,
+* but if we explicitly restore the focus here everything
works
+* fine.
+*
+* if (mra-w_with_focus != None)
+* {
+* FOCUS_SET(mra-w_with_focus);
+* }
+*
+* Unfortunately, the code doesn't work fine with Java 7's
FocusProxy
+* and has been commented out since it doesn't seem to be
necessary
+* when using modern Xorg.
+*/
+
if (mra-flags.do_update_shape)
{
/* unset shape */
=
/* simpleproblem.java
*
* Install java 7 (either oracle or openjdk)
* Run FVWM
* compile with: javac simpleproblem.java
* run with: java -cp . simpleproblem
*
* You will see that after resizing the window
* text entry into the java app is impossible.
*/
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JTextField;
import java.awt.FlowLayout;
public class simpleproblem extends JFrame
{
private JLabel explanation;
private JTextField entrybox;
private FlowLayout thelayout;
public simpleproblem()
{
explanation = new JLabel(Resize the window then enter text:);
entrybox = new JTextField(15);
thelayout = new FlowLayout();
setLayout(thelayout);
add(explanation);
add(entrybox);
}
public static void main( String args[] ) {
simpleproblem entertext = new simpleproblem();
entertext.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
entertext.setSize( 400,200 );
entertext.setVisible( true );
}
}
