Opened 7 months ago

Closed 7 weeks ago

#13707 closed bug (fixed)

xmobar crashes with segmentation faults?

Reported by: bgamari Owned by:
Priority: highest Milestone: 8.2.1
Component: Compiler Version: 8.2.1-rc2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash or panic Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by bgamari)

Markus Trippelsdorf on ghc-devs reports that 8.2.1-rc2 produces crashing xmobar executables.

Program received signal SIGSEGV, Segmentation fault.
 0x0000000000873aa8 in ghczmprim_GHCziClasses_eqChar_info ()

or:

 Program received signal SIGSEGV, Segmentation fault.
 0x0000000000873f98 in ghczmprim_GHCziClasses_zdfEqModulezuzdszdczeze_info ()
 (gdb) bt
 #0  0x0000000000873f98 in ghczmprim_GHCziClasses_zdfEqModulezuzdszdczeze_info ()
 #1  0x0000000000000000 in ?? ()

Attachments (1)

xmobar.coredump.xz (59.1 KB) - added by rezb1t 3 months ago.
xmobar coredump after segfault, with GHC 8.2.1

Download all attachments as: .zip

Change History (26)

comment:1 Changed 7 months ago by bgamari

Description: modified (diff)

comment:2 Changed 7 months ago by bgamari

Description: modified (diff)

comment:3 Changed 7 months ago by trippels

Not sure if it matters, but I built the latest xmobar git tree with -O2.

                                                                                                                                   
                                                                                                                                                                       
 ~ % cat .xmobarrc                                                                                                                                                                 
Config { font = "xft:Consolas:size=8"                                                                                                                                              
       , bgColor = "#fafafa"                                                                                                                                                       
       , fgColor = "#606060"                                                                                                                                                       
       , position =  BottomSize C 100 0                                                                                                                                            
       , lowerOnStart = True                                                                                                                                                       
       , hideOnStart = False                                                                                                                                                       
       , persistent = False                                                                                                                                                        
       , commands = [ Run Weather "EDDT" ["-t","<tempC>°C <rh>%"] 18000                                                                                                            
                    , Run Network "eth0" ["-t","<rx> <tx>","-w","4"] 10                                                                                                            
                    , Run Cpu ["-t","<total>%","-L","3","-H","50","--normal","blue","--high","red"] 10                                                                             
                    , Run Date "%a %b %_d %H:%M" "date" 10                                                                                                                         
                    , Run Com "/home/markus/cputemp" [] "temp" 100                                                                                                                 
                    , Run Com "/home/markus/loadav" [] "loadav" 100                                                                                                                
                    , Run StdinReader                                                                                                                                              
                    ]                                                                                                                                                              
       , sepChar = "%"                                                                                                                                                             
       , alignSep = "}{"                                                                                                                                                           
       , template = "%StdinReader% }{%cpu% | %loadav% | %temp%°C | %eth0% | %EDDT% | %date%"                                                                                       
       } 

comment:4 Changed 7 months ago by trippels

markus@x4 xmobar % cat /home/markus/cputemp
cat /sys/bus/pci/drivers/k10temp/0000:00:18.3/hwmon/hwmon1/temp1_input | awk '{printf "%.1f", $1/1000}'                                                                            

markus@x4 xmobar % cat /home/markus/loadav
cat /proc/loadavg | cut -d " " -f 1,2,3

markus@x4 xmobar % cabal install --flags="with_xft with_utf8"

comment:5 Changed 7 months ago by trippels

Also happens when build with -O1. Unfortunately, it can take several hours to hit the crash.

comment:6 Changed 7 months ago by bgamari

I left your xmobar configuration (build with -O1 from git) running under gdb for around 24 hours and I never observed a crash. Perhaps you could cite the dependency versions you are using?

comment:7 Changed 7 months ago by trippels

These were all built with "optimization: 2"

markus@x4 xmobar % cabal install --flags="with_xft with_utf8" --dry-run --allow-newer
Resolving dependencies...                   
In order, the following would be installed (use -v for more details):                    
data-default-class-0.1.2.0                  
data-default-instances-containers-0.0.1     
dlist-0.8.0.2                               
data-default-instances-dlist-0.0.1          
mtl-2.2.1                                   
network-2.6.3.1                             
old-locale-1.0.0.7                          
data-default-instances-old-locale-0.0.1     
data-default-0.7.1.1                        
X11-1.8                                     
regex-base-0.93.2                           
regex-posix-0.95.2                          
regex-compat-0.95.1                         
stm-2.4.4.1                                 
text-1.2.2.1                                
parsec-3.1.11                               
network-uri-2.6.1.0                         
HTTP-4000.3.6                               
utf8-string-1.0.1.1                         
X11-xft-0.3.1                               
xmobar-0.24.4 
Last edited 7 months ago by trippels (previous) (diff)

comment:8 Changed 7 months ago by bgamari

trippels, I've tried building against the libraries that you cite with -O2 but sadly I'm still not seeing the crashes. What distribution are you using? Perhaps you could provide your binary?

comment:9 Changed 7 months ago by trippels

Sorry, but I've switched back to 8.0.2 and everything works fine again. The xmobar binary is too big to attach (even compressed).

comment:10 Changed 6 months ago by bgamari

Status: newinfoneeded

Hmm, alright. Sorry for the crashes.

I would love to look at a core dump of your crashing executable (and perhaps the executable itself) if you get a chance.

comment:11 Changed 6 months ago by trippels

Core dumps are disabled on my machine. And I have deleted the old crashing xmobar binary.

Sorry, but I will not debug this any further and will just stay on 8.0.2 for the future.

Changed 3 months ago by rezb1t

Attachment: xmobar.coredump.xz added

xmobar coredump after segfault, with GHC 8.2.1

comment:13 Changed 3 months ago by rezb1t

EDIT: Going to have to get another coredump, as I realized Nix had stripped out the debug symbols from xmobar, so I don't think the above coredump would help much unfortunately.

Will update as soon as I can do that.

Last edited 3 months ago by rezb1t (previous) (diff)

comment:14 Changed 3 months ago by Emantor

Hello,

I just produced an unstripped version of xmobar, here is the coredump from coredumpctl. Unfortunately it is bigger than the allowed upload limit, you can download it here.

I also built a version with the configure option --with-debug-info=1, weirdly I could not reproduce the crashes with that binary.

comment:15 Changed 3 months ago by Emantor

Status: infoneedednew

comment:16 Changed 3 months ago by bgamari

Do you think you could include the executable as well? Unfortunately it's hard to do much with the coredump without at least the symbol table.

comment:17 Changed 3 months ago by Emantor

Sure, here is a new dump from a newly compiled executable which shows the same error. The executable is included in the archive as well. Download link

Coredumpctl output:

           PID: 8772 (xmobar)
           UID: 1000 (phoenix)
           GID: 1000 (phoenix)
        Signal: 11 (SEGV)
     Timestamp: Sun 2017-09-24 21:10:11 CEST (1min 7s ago)
  Command Line: /usr/bin/xmobar /home/phoenix/.xmobarrc
    Executable: /usr/bin/xmobar
 Control Group: /user.slice/user-1000.slice/user@1000.service/xmobar-top.service
          Unit: user@1000.service
     User Unit: xmobar-top.service
         Slice: user-1000.slice
     Owner UID: 1000 (phoenix)
       Boot ID: 1c1d572b68cd460fbbf226a6a829db85
    Machine ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
      Hostname: dibooki
       Storage: /var/lib/systemd/coredump/core.xmobar.1000.1c1d572b68cd460fbbf226a6a829db85.8772.1506280211000000.lz4
       Message: Process 8772 (xmobar) of user 1000 dumped core.

                Stack trace of thread 8772:
                #0  0x00007f59f5b58f64 ghczmprim_GHCziClasses_zdfEqModulezuzdszdczeze_info (libHSghc-prim-0.5.1.0-ghc8.2.1.so)
Last edited 3 months ago by Emantor (previous) (diff)

comment:18 Changed 3 months ago by Rufflewind

The crash is quite rare and sporadic. I've had it run for 1-3 days without crashing.

GDB:

    0x7ffff55ffcdd <evacuate+93>    or     rdx,rcx
  > 0x7ffff55ffce0 <evacuate+96>    movzx  ecx,WORD PTR [rdx+0x2e]
    0x7ffff55ffce4 <evacuate+100>   test   cx,0x20b

> print/x $rdx  # variable "bd"
0x6300000000

> backtrace
#0  evacuate (p=p@entry=0x4200266b98) at rts/sm/Evac.c:583
#1  0x00007ffff55ff155 in scavenge_block (bd=0x4200201980) at rts/sm/Scav.c:548
#2  0x00007ffff561495e in scavenge_find_work () at rts/sm/Scav.c:2132
#3  scavenge_loop () at rts/sm/Scav.c:2195
#4  0x00007ffff561b08f in scavenge_until_all_done () at rts/sm/GC.c:1020
#5  GarbageCollect (collect_gen=collect_gen@entry=1, 
    do_heap_census=do_heap_census@entry=false, gc_type=gc_type@entry=0, 
    cap=cap@entry=0x7ffff5648a00 <MainCapability>, idle_cap=idle_cap@entry=0x0)
    at rts/sm/GC.c:406
#6  0x00007ffff560da3d in scheduleDoGC (pcap=pcap@entry=0x7fffffffdba8, 
    task=task@entry=0x5c28d0, force_major=force_major@entry=false)
    at rts/Schedule.c:1822
#7  0x00007ffff560e6fb in schedule (task=0x5c28d0, initialCapability=<optimized out>)
    at rts/Schedule.c:558
#8  scheduleWaitThread (tso=<optimized out>, ret=ret@entry=0x0, 
    pcap=pcap@entry=0x7fffffffdc08) at rts/Schedule.c:2551
#9  0x00007ffff560fed8 in rts_evalLazyIO (cap=cap@entry=0x7fffffffdc08, 
    p=p@entry=0x5ad4a0, ret=ret@entry=0x0) at rts/RtsAPI.c:530
#10 0x00007ffff561086e in hs_main (argc=1, argv=0x7fffffffddd8, 
    main_closure=0x5ad4a0, rts_config=...) at rts/RtsMain.c:64
#11 0x0000000000578fe1 in main ()

Built using GHC from https://downloads.haskell.org/~ghc/8.2.1/ghc-8.2.1-x86_64-deb8-linux.tar.xz installed on Arch Linux with ncurses5-compat-libs. xmobar was built with:

cabal install --disable-executable-stripping --with-ghc=/opt/ghc-8.2.1/bin/ghc \
    -f 'with_utf8 with_xft with_iwlib with_xpm with_inotify'

constraints: HTTP ==4000.3.7,
             X11 ==1.8,
             array ==0.5.2.0,
             base ==4.10.0.0,
             binary ==0.8.5.1,
             bytestring ==0.10.8.2,
             containers ==0.5.10.2,
             data-default ==0.7.1.1,
             data-default-class ==0.1.2.0,
             data-default-instances-containers ==0.0.1,
             data-default-instances-dlist ==0.0.1,
             data-default-instances-old-locale ==0.0.1,
             deepseq ==1.4.3.0,
             directory ==1.3.0.2,
             dlist ==0.8.0.3,
             filepath ==1.4.1.2,
             ghc-prim ==0.5.1.0,
             integer-gmp ==1.0.1.0,
             mtl ==2.2.1,
             network ==2.6.3.2,
             network-uri ==2.6.1.0,
             old-locale ==1.0.0.7,
             parsec ==3.1.11,
             process ==1.6.1.0,
             regex-base ==0.93.2,
             regex-compat ==0.95.1,
             regex-posix ==0.95.2,
             rts ==1.0,
             stm ==2.4.4.1,
             text ==1.2.2.2,
             time ==1.8.0.2,
             transformers ==0.5.2.0,
             unix ==2.7.2.2,
             utf8-string ==1.0.1.1

Edit: Got a second crash on 2017-09-26:

    0x7ffff560134e <evacuate+5838>  or     rbp,r12
  > 0x7ffff5601351 <evacuate+5841>  movzx  eax,WORD PTR [rbp+0x28]
    0x7ffff5601355 <evacuate+5845>  cmp    ebx,eax

$rbp = (void *) 0x2300000000
Cannot access memory at address 0x2300000000

#0  evacuate (p=p@entry=0x42002d7410) at rts/sm/Evac.c:651
#1  0x00007ffff55ff15e in scavenge_block (bd=0x42002035c0) at rts/sm/Scav.c:549
#2  0x00007ffff561495e in scavenge_find_work () at rts/sm/Scav.c:2132
#3  scavenge_loop () at rts/sm/Scav.c:2195
#4  0x00007ffff561b08f in scavenge_until_all_done () at rts/sm/GC.c:1020
#5  GarbageCollect (collect_gen=collect_gen@entry=0, do_heap_census=do_heap_census@entry=false, gc_type=gc_type@entry=0, cap=cap@entry=0x7ffff5648a00 <MainCapability>, 
    idle_cap=idle_cap@entry=0x0) at rts/sm/GC.c:406
#6  0x00007ffff560da3d in scheduleDoGC (pcap=pcap@entry=0x7fffffffdba8, task=task@entry=0x5c28d0, force_major=force_major@entry=false) at rts/Schedule.c:1822
#7  0x00007ffff560e6fb in schedule (task=0x5c28d0, initialCapability=<optimized out>) at rts/Schedule.c:558
#8  scheduleWaitThread (tso=<optimized out>, ret=ret@entry=0x0, pcap=pcap@entry=0x7fffffffdc08) at rts/Schedule.c:2551
#9  0x00007ffff560fed8 in rts_evalLazyIO (cap=cap@entry=0x7fffffffdc08, p=p@entry=0x5ad4a0, ret=ret@entry=0x0) at rts/RtsAPI.c:530
#10 0x00007ffff561086e in hs_main (argc=1, argv=0x7fffffffddd8, main_closure=0x5ad4a0, rts_config=...) at rts/RtsMain.c:64
#11 0x0000000000578fe1 in main ()

Edit 2: Added links to config.

Edit 3: Got a third crash, but this time very different:

   0x00007ffff59f40f3 <+115>:   mov    rax,QWORD PTR [rbx+0x7]
   0x00007ffff59f40f7 <+119>:   mov    rbx,QWORD PTR [rbp+0x18]
   0x00007ffff59f40fb <+123>:   mov    QWORD PTR [rbp+0x18],rax
   0x00007ffff59f40ff <+127>:   test   bl,0x7
   0x00007ffff59f4102 <+130>:   jne    0x7ffff59f40c0 <ghczmprim_GHCziClasses_zdfEqModulezuzdszdczeze_info+64>
=> 0x00007ffff59f4104 <+132>:   jmp    QWORD PTR [rbx]
   0x00007ffff59f4106 <+134>:   xchg   ax,ax
   0x00007ffff59f4108 <+136>:   add    al,BYTE PTR [rax]
   0x00007ffff59f410a <+138>:   add    BYTE PTR [rax],al
   0x00007ffff59f410c <+140>:   add    BYTE PTR [rax],al
   0x00007ffff59f410e <+142>:   add    BYTE PTR [rax],al

$rbx = 0  # null pointer?
$bl = 0

#0  0x00007ffff59f4104 in ghczmprim_GHCziClasses_zdfEqModulezuzdszdczeze_info ()
   from /opt/ghc-8.2.1/lib/ghc-8.2.1/ghc-prim-0.5.1.0/libHSghc-prim-0.5.1.0-ghc8.2.1.so
#1  0x0000000000000000 in ?? ()

Edit 4: Got a fourth and fifth crash. Fourth one was xmobar running in the background in another X session. Fifth one happened while I was examining the fourth crash.

Fourth crash:

#0  0x0000000000871f70 in ghczmprim_GHCziClasses_eqChar_info ()
#1  0x0000000000000000 Something ?? ()

rax            0x42001fcea0     283469926048                                                
rbx            0x630000000c     425201762316                                                
rcx            0xb      11                                                                  
rdx            0x42001019c0     283468896704                                                
rsi            0x961719 9836313                                                             
rdi            0x910c28 9505832                                                             
rbp            0x42001fcea0     0x42001fcea0                                                
rsp            0x7fffffffa638   0x7fffffffa638                                              
r8             0x4200167540     283469313344                                                
r9             0x4200167561     283469313377                                                
r10            0x4200167581     283469313409                                                
r11            0x4200167599     283469313433                                                
r12            0x42001676b0     283469313712                                                
r13            0x963018 9842712                                                             
r14            0x630000000c     425201762316                                                
r15            0x42001f50c0     283469893824
rip            0x871f70 0x871f70 <ghczmprim_GHCziClasses_eqChar_info+64>                    
eflags         0x10202  [ IF RF ]                                                           
cs             0x33     51                                                                  
ss             0x2b     43                                                                  
ds             0x0      0                                                                   
es             0x0      0                                                                   
fs             0x0      0                                                                   
gs             0x0      0                 

There's something really weird about this crash:

=> 0x871f70 <ghczmprim_GHCziClasses_eqChar_info+64>        mov    0x7(%rbx),%rax
   0x871f74 <ghczmprim_GHCziClasses_eqChar_info+68>        mov    0x8(%rbp),%rbx            
   0x871f78 <ghczmprim_GHCziClasses_eqChar_info+72>        mov    %rax,0x8(%rbp)            
   0x871f7c <ghczmprim_GHCziClasses_eqChar_info+76>        test   $0x7,%bl                  
   0x871f7f <ghczmprim_GHCziClasses_eqChar_info+79>        jne    0x871fa0 <ghczmprim_GHCziC
   0x871f81 <ghczmprim_GHCziClasses_eqChar_info+81>        jmpq   *(%rbx)                   
   0x871f83 <ghczmprim_GHCziClasses_eqChar_info+83>        mov    $0x960740,%ebx            
   0x871f88 <ghczmprim_GHCziClasses_eqChar_info+88>        jmpq   *-0x8(%r13)               
   0x871f8c <ghczmprim_GHCziClasses_eqChar_info+92>        nopl   0x0(%rax)                 
   0x871f90 <ghczmprim_GHCziClasses_eqChar_info+96>        add    %al,(%r8)                 
   0x871f93 <ghczmprim_GHCziClasses_eqChar_info+99>        add    %al,(%rax)               

when I try to scroll up, it shows this instead:

   0x871f5e <ghczmprim_GHCziClasses_eqChar_info+46>        add    %al,(%rax)                
   0x871f60 <ghczmprim_GHCziClasses_eqChar_info+48>        (bad)                            
   0x871f61 <ghczmprim_GHCziClasses_eqChar_info+49>        add    %al,(%rax)                
   0x871f63 <ghczmprim_GHCziClasses_eqChar_info+51>        add    %al,(%rax)                
   0x871f65 <ghczmprim_GHCziClasses_eqChar_info+53>        add    %al,(%rax)                
   0x871f67 <ghczmprim_GHCziClasses_eqChar_info+55>        add    %cl,-0x39(%rax)           
   0x871f6a <ghczmprim_GHCziClasses_eqChar_info+58>        add    %r12b,0x4800871f(%r8)     
   0x871f71 <ghczmprim_GHCziClasses_eqChar_info+65>        mov    0x7(%rbx),%eax            
   0x871f74 <ghczmprim_GHCziClasses_eqChar_info+68>        mov    0x8(%rbp),%rbx            
   0x871f78 <ghczmprim_GHCziClasses_eqChar_info+72>        mov    %rax,0x8(%rbp)            
   0x871f7c <ghczmprim_GHCziClasses_eqChar_info+76>        test   $0x7,%bl                  

the cursor (that shows the currently executing instruction) disappears, and the instruction at 0x871f70 doesn't exist anymore

is the instruction pointer is completely corrupted?

Fifth crash: (this one uses GHC b3ae47caf2)

#0  evacuate (p=p@entry=0x420010ef00) at rts/sm/Evac.c:583
#1  0x000000000040d66d in scavenge_block (bd=0x4200100380) at rts/sm/Scav.c:548
#2  0x0000000000d50c1d in scavenge_find_work () at rts/sm/Scav.c:2136
#3  scavenge_loop () at rts/sm/Scav.c:2199
#4  0x0000000000d38923 in scavenge_until_all_done () at rts/sm/GC.c:1035
#5  GarbageCollect (collect_gen=collect_gen@entry=0, do_heap_census=do_heap_census@entry=false, 
    gc_type=gc_type@entry=0, cap=cap@entry=0xfa4600 <MainCapability>, idle_cap=idle_cap@entry=0x0)
    at rts/sm/GC.c:406
#6  0x0000000000d2b8dc in scheduleDoGC (pcap=pcap@entry=0x7fffffffdb98, force_major=force_major@entry=false, 
    task=0xfbe0f0) at rts/Schedule.c:1809
#7  0x0000000000d2c41f in schedule (task=0xfbe0f0, initialCapability=<optimized out>) at rts/Schedule.c:558
#8  scheduleWaitThread (tso=<optimized out>, ret=ret@entry=0x0, pcap=pcap@entry=0x7fffffffdbf8)
    at rts/Schedule.c:2544
#9  0x0000000000d33be4 in rts_evalLazyIO (cap=cap@entry=0x7fffffffdbf8, p=p@entry=0xe00bc8, ret=ret@entry=0x0)
    at rts/RtsAPI.c:530
#10 0x0000000000d34a7e in hs_main (argc=<optimized out>, argv=<optimized out>, main_closure=0xe00bc8, 
    rts_config=...) at rts/RtsMain.c:72
#11 0x000000000053654f in main ()

   0x000000000040bb67 <+103>:	mov    rcx,rbx
   0x000000000040bb6a <+106>:	and    rdx,0xfffffffffff00000
   0x000000000040bb71 <+113>:	shr    rcx,0x6
   0x000000000040bb75 <+117>:	and    ecx,0x3fc0
   0x000000000040bb7b <+123>:	or     rcx,rdx
=> 0x000000000040bb7e <+126>:	movzx  esi,WORD PTR [rcx+0x2e]
   0x000000000040bb82 <+130>:	test   si,0x20b
   0x000000000040bb87 <+135>:	jne    0x40d050 <evacuate+5456>
   0x000000000040bb8d <+141>:	mov    rbp,QWORD PTR [rbx]
   0x000000000040bb90 <+144>:	movzx  edx,WORD PTR [rcx+0x2a]

rax            0x6300000008	425201762312
rbx            0x6300000008	425201762312
rcx            0x6300000000	425201762304
rdx            0x6300000000	425201762304
rsi            0x4	4
rdi            0xd8e66c	14214764
rbp            0xd8ff80	0xd8ff80
rsp            0x7fffffffd9b0	0x7fffffffd9b0
r8             0x4200000000	283467841536
r9             0x14200000000	1382979469312
r10            0xfa8440	16417856
r11            0xd43d80	13909376
r12            0x420010ef00	283468951296
r13            0x4	4
r14            0xd43dd0	13909456
r15            0xd43df8	13909496
rip            0x40bb7e	0x40bb7e <evacuate+126>
eflags         0x10206	[ PF IF RF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0

Last edited 3 months ago by Rufflewind (previous) (diff)

comment:19 Changed 3 months ago by Emantor

I can make it crash on demand by switching workspaces/windows using the XmonadLog Plugin, i'd say its one out of three times.

comment:20 Changed 3 months ago by bgamari

Sadly I can't get a backtrace out of the coredump even with the executable. However, the dump in comment:17 is quite interesting as it implicates the Eq Module instance in GHC.Classes. Unfortunately this is much different from the crash seen in comment:18.

comment:21 Changed 3 months ago by Rufflewind

Okay, so I think I've found a semi-reliable way to reproduce the bug without waiting days. You need to have two X screens (you can also have one X screen and one Linux terminal instead, but I got the impression that crashes are less reliable that way). Suppose you have one screen on TTY1 (Ctrl+Alt+F2) and another on TTY2 (Ctrl+Alt+F2). I found the that if I have xmobar on one of them and repeatedly spam Ctrl+Alt+F1 and Ctrl+Alt+F2 (*) to switch the screens back and forth, I can occasionally reproduce the crash.

What I did essentially was to load 10 instances of xmobar and then switch screens repeatedly, and I could get it to crash fairly often. In one particular run of 100 attempts, it crashed on the attempt 3, 5, 6, 10, 20, 21, 21, 22, 33, 53, 54, 60, 60, 62, 69, 83, 85. Two of the instances crashed one after the other on 21 and 60. Therefore I conclude it has about a 2% chance of crashing each time the screen gets blanked.

I think the bug has something to do with screen blanking / switching. In retrospect, I think the reason I often discover this bug overnight is because my screensaver blanks out the screen while I'm away, so that has a small chance of triggering the bug.

The xmobar configuration seems irrelevant for the most part. I could reproduce this with the default config.

(*) You'll have to fully release the Ctrl and Alt keys between each hit, or else Linux will fail to interpret the key correctly.

Given that I'm able to reproduce a wide variety of stack traces, I think these errors are all somewhat related in cause despite the apparent ways in which they crash. I even got a crash like this:

xmobar: internal error: evacuate: strange closure type 4689
    (GHC version 8.3.20170927 for x86_64_unknown_linux)

comment:22 Changed 2 months ago by bgamari

Thanks Rufflewind; I left an xmobar instance running in the background all of last week but sadly I still have yet to see a crash. I'll try your reproducer shortly.

comment:23 Changed 2 months ago by andrewchen

You can reliably reproduce the crash by sending the xmobar window a lot of events, e.g. using xdotool to send a lot of mouse button presses, or as some members on github has pointed out, dragging other windows over the xmobar window, thus sending Expose events. You also need to have at least 1 monitor in your xmobarrc (e.g. have Run Swap [] 10 in commands).

The stack traces I got weren't very helpful, but most of them segfaulted on values read from the memory area used for return data from XNextEvent.

Also see discussion here: https://ghc.haskell.org/trac/ghc/ticket/14346

comment:24 Changed 8 weeks ago by bgamari

I wonder if any of the number of correctness fixes that we have merged recently will address this. Particularly I wonder about #14346.

Last edited 8 weeks ago by bgamari (previous) (diff)

comment:25 Changed 7 weeks ago by trippels

Resolution: fixed
Status: newclosed

Fixed by "base: Make Foreign.Marshal.Alloc.allocBytes[Aligned] NOINLINE". Took some time, but thanks.

Note: See TracTickets for help on using tickets.