Subject: [Chung-chieh Shan <[email-masked]>] Bug#161282: fvwm: core dumped by ssh-askpass

From: Alexander Kotelnikov <[email-masked]>
Date: Wed, 18 Sep 2002 20:37:22 +0400

Hi.

And this is true :( Just ssh-askpass run makes fvwm cash.

Subject: Bug#161282: fvwm: core dumped by ssh-askpass
From: Chung-chieh Shan <[email-masked]>
To: Debian Bug Tracking System <[email-masked]>
Date: Tue, 17 Sep 2002 23:00:38 -0400

Package: fvwm
Version: 2.4.10-1
Severity: important

When I run ssh-askpass, fvwm crashes.  This did not use to happen with
the previous version of fvwm (2.4.9-1).  My ssh-askpass package is at
version 1:1.2.0-2.1.  For now, I have switched to ssh-askpass-gnome,
which does not crash fvwm.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux proper 2.4.19 #2 Wed Aug 28 01:32:40 EDT 2002 i686
Locale: LANG=C, LC_CTYPE=en_US

Versions of packages fvwm depends on:
ii  libc6                    2.2.5-14.2      GNU C Library: Shared libraries an
ii  libglib1.2               1.2.10-6        The GLib library of C routines
ii  libgtk1.2                1.2.10-14       The GIMP Toolkit set of widgets fo
ii  libncurses5              5.2.20020112a-8 Shared libraries for terminal hand
ii  libreadline4             4.3-4           GNU readline and history libraries
ii  libstroke0               0.5.1-2         support for mouse strokes like tho
ii  xlibs                    4.2.1-0pre1v1   X Window System client libraries

-- no debconf information

-- 
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
Please don't misrepresent my identity or violate any copyrights
or applicable legal restrictions, but otherwise, have fun.

-- 
Alexander Kotelnikov
Saint-Petersburg, Russia

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 18 Sep 2002 18:47:19 +0200

> which does not crash fvwm.

Is there a core file?  Please fetch us a stack trace:

  $ gdb fvwm core
  (gdb) where

> -- no debconf information

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Alexander Kotelnikov <[email-masked]>
Date: Wed, 18 Sep 2002 22:43:53 +0400

>>>>> On Wed, 18 Sep 2002 18:47:19 +0200
>>>>> "DV" == Dominik Vogt <[email-masked]> wrote:
DV> 
>> which does not crash fvwm.
DV> 
DV> Is there a core file?  Please fetch us a stack trace:
DV> 

Hmm. Rather simple to generate.

The stack is rather monotonous, even funny:

(gdb) bt 10
#0  0x08065292 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:632
#1  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#2  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#3  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#4  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#5  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#6  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#7  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#8  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#9  0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
(More stack frames follow...)
(gdb) bt -20
#174670 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#174671 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#174672 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#174673 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#174674 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#174675 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#174676 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#174677 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#174678 0x08065315 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:682
#174679 0x08065425 in RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:772
#174680 0x08065250 in __restack_window (t=0x80ec730, do_lower=0, 
    do_restack_transients=0, is_new_window=1) at stack.c:613
#174681 0x0806537f in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
---Type <return> to continue, or q <return> to quit---
    allow_recursion=0, is_new_window=1) at stack.c:702
#174682 0x08065425 in RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=0, is_new_window=1) at stack.c:772
#174683 0x08064d17 in position_new_window_in_stack_ring (t=0x80ec730, 
    do_lower=0) at stack.c:281
#174684 0x08081795 in AddWindow (w=25165833, ReuseWin=0x0) at add_window.c:1573
#174685 0x08067adf in HandleMapRequestKeepRaised (KeepRaised=0, ReuseWin=0x0)
    at events.c:1158
#174686 0x08067a3d in HandleMapRequest () at events.c:1117
#174687 0x08069e3e in DispatchEvent (preserve_Tmp_win=0) at events.c:2991
#174688 0x08069ed8 in HandleEvents () at events.c:3044
#174689 0x08087e6f in main (argc=3, argv=0xbffffa44) at fvwm.c:734

The crash point is

Program received signal SIGSEGV, Segmentation fault.
0x08065292 in __RaiseOrLowerWindow (t=0x80ec730, do_lower=0, 
    allow_recursion=1, is_new_window=0) at stack.c:632
632     {

DV>   $ gdb fvwm core
DV>   (gdb) where
DV> 
>> -- no debconf information
DV> 
DV> Bye
DV> 
DV> Dominik ^_^  ^_^
DV> 
DV>  --
DV> Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
DV> Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
DV> --
DV> Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
DV> To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
DV> body of a message to [email-masked].
DV> To report problems, send mail to [email-masked]
DV> 
-- 
Alexander Kotelnikov
Saint-Petersburg, Russia
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 19 Sep 2002 11:00:47 +0200

> The stack is rather monotonous, even funny:

F...!  I guess there is nothing that some applications don't do.
The window has set itself as its transientfor window.  Hence the
infinite recursion.  Please add

      for (t2 = Scr.FvwmRoot.stack_next; t2 != &Scr.FvwmRoot;
	   t2 = t2->stack_next)
      {
+	if (t2 == t)
+	{
+	  break;
+	}
        if (t2->w == t->transientfor)
        {
	  if (IS_ICONIFIED(t2) || t->layer != t2->layer)

add line 664 of fvwm/stack.c and try again.  As far as I can see
it should work, but I don't want to release 2.4.11 without trying
first.

>     allow_recursion=1, is_new_window=0) at stack.c:682
...

Bye

Dominik ^_^  ^_^

---

From: Alexander Kotelnikov <[email-masked]>
Date: Thu, 19 Sep 2002 22:35:57 +0400

>>>>> On Thu, 19 Sep 2002 11:00:47 +0200
DV> 

Really helps.

DV> 
DV> 
>> The stack is rather monotonous, even funny:
DV> 
DV> F...!  I guess there is nothing that some applications don't do.
DV> The window has set itself as its transientfor window.  Hence the
DV> infinite recursion.  Please add
DV> 
DV>       for (t2 = Scr.FvwmRoot.stack_next; t2 != &Scr.FvwmRoot;
DV> 	   t2 = t2->stack_next)
DV>       {
DV> +	if (t2 == t)
DV> +	{
DV> +	  break;
DV> +	}
DV>         if (t2->w == t->transientfor)
DV>         {
DV> 	  if (IS_ICONIFIED(t2) || t->layer != t2->layer)
DV> 
DV> add line 664 of fvwm/stack.c and try again.  As far as I can see
DV> it should work, but I don't want to release 2.4.11 without trying
DV> first.