I'm seeing a consistent fvwm2 crash on OpenBSD 6.7 GENERIC.MP#182
amd64 when i run conky (light-weight system monitor) then close conky's
window using the close button in the titlebar.

I have a small amount of information from attaching egdb to fvwm2 in a
console, which i think suggests that fvwm2 is trying to access freed
memory:

    GNU gdb (GDB) 7.12.1
    Copyright (C) 2017 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later
    <http://gnu.org/licenses/gpl.html> This is free software: you are
    free to change and redistribute it. There is NO WARRANTY, to the
    extent permitted by law.  Type "show copying" and "show warranty"
    for details. This GDB was configured as "x86_64-unknown-openbsd6.7".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.
    For help, type "help".
    Type "apropos word" to search for commands related to "word".
    Attaching to process 60515

    warning: No executable has been specified and target does not
    support determining executable automatically.  Try using the "file"
    command. [Switching to thread 228955]
    0x53b3f43a in ?? ()
    (gdb) !which fvwm2
    /usr/local/bin/fvwm2
    (gdb) file /usr/local/bin/fvwm2
    A program is being debugged already.
    Are you sure you want to change the file? (y or n) y
    Reading symbols from /usr/local/bin/fvwm2...(no debugging symbols
    found)...done. (gdb) c
    Continuing.

    Program received signal SIGBUS, Bus error.
    0x00000a10ed98ff1d in ?? ()
    (gdb) bt
    #0  0x00000a10ed98ff1d in ?? ()
    #1  0x0000000000000000 in ?? ()
    (gdb) disassemble $pc,$pc+30
    Dump of assembler code from 0xa10ed98ff1d to 0xa10ed98ff3b:
    => 0x00000a10ed98ff1d:      mov    0x3dc(%rax),%eax
       0x00000a10ed98ff23:      cmp    0x3dc(%r14),%eax
       0x00000a10ed98ff2a:      jne    0xa10ed98fc0f
       0x00000a10ed98ff30:      mov    %ecx,-0x38(%rbp)
       0x00000a10ed98ff33:      mov    %r13d,-0x34(%rbp)
       0x00000a10ed98ff37:      mov    %r14,%rdi
       0x00000a10ed98ff3a:      mov    %r11d,%ebx
    End of assembler dump.
    (gdb) info reg
    rax            0xdfdfdfdfdfdfdfdf   -2314885530818453537
    rbx            0x4  4
    rcx            0x0  0
    rdx            0xa10ed9e80f8        11067822342392
    rsi            0x0  0
    rdi            0xa13c47a9000        11080017022976
    rbp            0x7f7fffff6f00       0x7f7fffff6f00
    rsp            0x7f7fffff69a0       0x7f7fffff69a0
    r8             0x0  0
    r9             0x0  0
    r10            0x0  0
    r11            0x0  0
    r12            0x0  0
    r13            0x0  0
    r14            0xa13c47a9000        11080017022976
    r15            0x0  0
    rip            0xa10ed98ff1d        0xa10ed98ff1d
    eflags         0x10286      [ PF SF IF RF ]
    cs             0x2b 43
    ss             0x23 35
    ds             0x23 35
    es             0x23 35
    fs             0x23 35
    gs             0x23 35
    (gdb) q
    A debugging session is active.

            Inferior 1 [process 60515] will be detached.

    Quit anyway? (y or n) y
    Detaching from program: /usr/local/bin/fvwm2, process 60515


I'm running fvwm from ports: Fvwm Version 2.6.5

I've also seen a similar problem when running ghostscript with no
args and closing its window.

The problem also occurs in a vncserver session, and also with a local
build of the latest fvwm-2.6.9, and a minimal .fvwm2rc file.


== Reproducing with vnc

.vnc/xstartup
====
#!/bin/sh
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
fvwm2 -f .fvwm2rc_test
exit
====


.fvwm2rc_test
====
AddButtonStyle 1 ActiveDown (5 01x01@0 99x01@0 99x99@1 01x99@1 01x01@0)
Mouse   1   1   A   Close
AddToMenu Window-Ops    "Window Ops"    Title           
+                       "Close%mini.cut.xpm%"               Close
+                       "Destroy%mini.destroy.xpm%"         Destroy
Mouse   2   R   A   Menu Window-Ops Nop
====

In one xterm:
    vncserver -fg -xstartup .vnc/xstartup

In second xterm:
    vncviewer.tigervnc -passwd .vnc/passwd :1


Curiously, closing the conky window using a separate WindowOps
menu does't cause the crash.



uname is:
    OpenBSD jules-obsd.my.domain 6.7 GENERIC.MP#182 amd64

I've attached the output from dmesg.

Does anyone have any suggestions on how to debug this? Even when
building fvwm-2.6.9 with -g, i'm not seeing any symbols in the
backtrace.

I couldn't find a bug submit form on fvwm.org.

Thanks,

- Jules

-- 
http://op59.net

Attachment: dmesg
Description: Binary data

Reply via email to