ratpoison-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RP] Window number bug [with patch]


From: Martin Samuelsson
Subject: [RP] Window number bug [with patch]
Date: Sat, 16 Apr 2005 17:59:44 +0200
User-agent: Mutt/1.5.6+20040907i

On Thu, Apr 14, 2005 at 06:10:27PM +0200, Martin Samuelsson wrote:
> The next thing to fix for ratpoison on my list is that sometimes raise
> request messages for transients tells another window number than what's
> actually true. For me it's a long time bug, but it does not occur every
> time. Have anyone else experienced it?

Now I have found out howto reliably reproduce it. Try for example this:
(After understanding the problem I could think of easier cases)

1. Set your rudeness to something sane.             C-t :rudeness 8
2. In an empty group start a firefox.               C-t :exec mozilla-firefox 

        A browser window appears

3. Check the window list.                           C-t :windows

        0*Mozilla Firefox

4. Tell ratpoison to move it to window 2.           C-t :number 2 
5. Check the window list.                           C-t :windows

        2*Mozilla Firefox

6. Bring up a transient. (e.g. preferences)         A-e n

        New transient window 1 (Preferences)

7. Switch to it.                                    C-t :select 1

        0+Preferences
        2*Mozilla Firefox



Hey! Why did it show up as window 1 when in fact it was window 0?

Trying to debug starts at map_window() where it's easy to realize
win->number gets an incorrect value from numset_request(). In the case
above it recieves 1 instead of 0. Is this because numbers_taken in
rp_window_numset is corrupt?

Or is it perhaps simply because that structure never became group aware
when the rest of the application evolved? I can only find one
rp_window_numset variable declared and set_current_group() doesn̈́'t seem
to change where that pointer aims.

Adding a few lines to the function makes it actually check for what
number the window got in it's group instead of in the global window
list. A patch is applied, which makes the problem go away. Maybe there
is a smarter way to solve it? I still have not yet learnt how ratpoison
really works internally.

Comments on this?

Or to wander off topic, has anyone here tried mutt-ng at all?
--
/Martin


I also realized that after applying the JNPatch the following occurs
when trying to debug ratpoison. Why is that?


leka% file =ratpoison
/usr/bin/ratpoison: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped
leka% gdb =ratpoison 
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...Using host libthread_db library 
"/lib/tls/libthread_db.so.1".

(gdb) list
1       ../sysdeps/i386/elf/start.S: No such file or directory.
        in ../sysdeps/i386/elf/start.S
(gdb) list cmd_abort 
No line number known for cmd_abort.
(gdb) 

Attachment: ratpoison-map_window-bug-fixed.diff
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]