Discord, Discord Canary, .cache vs Cache, and my on-going minor bug

faceyneck · 2018-01-25 05:39:23

Hello again, Arch Community,

I shall do my best to explicate this small annoyance:

This is Arch Linux running in VMWare, and aside from me messing up my own MIME database one time (See = here if you're interested), and a window resize issue that came and went, (See = here if you're interested) the system is doing great. That is, aside from this on-going problem with Discord.

This particular problem happens with any Discord app I've used from the AUR:

After some amount of time - usually 2-7 days - Discord chat window will go completely blank. By "completely blank" I mean to say: it will have the window decorator, and I can minimize/maximize, or move it around. However, there is no content within the window, only a black square. Nothing else.
(I could close the window too by clicking on the X on the window decorator for bad times, but more on that in a sec...)

I've not been able to find much information about this particular issue on this site or on others. I believe I've found 3 posts of people talking about a blank Discord screen/window, although in the 3 I looked at they didn't specify a solution to the problem, other than reboot the system.

I decided to look into it a bit deeper. For one thing, in the .install(s) that I have, it says that cache for Discord or Discord Canary are located in ~/.cache/Discord or ~/.cache/Discord-Canary:

post_upgrade() {
    echo ">>> You may need to delete discord's cache directory ~/.cache/discord"
    echo ">>> try this if discord is stuck on the updating screen or if nothing displays but a gray box"
    echo ">>> If you are experiencing a (A JavaScript error occurred in the main process) error try deleting the /tmp/discordcanary.sock file"
    echo ">>> if this doesn't work ask for help in #linux-general in the Discord Testers server https://discord.gg/discord-testers"
    echo ">>> You may also want to check out the linux server for help as well https://discord.gg/e7GX27C"
}

That's not the case on my system. The cache for Discord/Canary can be found in either ~/.config/discordcanary/Cache or ~/.config/discord/Cache

Now, if I were to simply try to kill the bugged out window, it would hard lock my system, leaving me with the ability to move my cursor around my now-frozen still image of what my desktop enviro looked like right before I tried to kill the problem, and........ nothing else.

No combination of hotkeys was ever able to get me to pull up a terminal or close the desktop session. It would just be borked.

HOWEVER

If I delete the Cache file completely (or rename it to be safe. I used to do that at first) and then kill the window/xkill window/kill PID for Discord, all is well and it closes down without locking up my system. At this point I can relaunch the Discord app and wait until this happens again.

So, now I've gotten a work-around so that nothing I do day-to-day leads to built-up problems that ultimately require me to reboot my system. Or worse, and what usually happens; me losing some amount of work because the system locked up due to Discord not working so great.

Anyone else have this issue, or know what I'm talking about? Does anyone know of a better way to work around this issue? Maybe you have a similar problem with some other software and found a better solution that might be apllicable to me or others with this minor bug?

Thanks for taking the time to read this. I hope it's all clear enough. I'm wanting to make it clear so that now and in the future, whoever comes across it will have all the relevant information.

I have a bit of a vacation/holiday to go on over this weeked starting tomorrow, but I should have Internet and be able to respond to any posts in the meridiem.

Cheers,

Facey

Lone_Wolf · 2018-01-25 12:48:32

After some amount of time - usually 2-7 days - Discord chat window will go completely blank.

How often do you update and/or reboot this VM ?

Is this while running Mate , KDE or both ?

post x org log and output of pacman -Qs xf86-video

Steef435 · 2018-01-26 12:58:08

Memory hog? Any logs after a system freeze?

Maybe relevant: https://github.com/electron/electron/issues/11102

faceyneck · 2018-02-01 02:49:22

Hey guys,

I'm back in town. Sorry for the delay.

Lone_Wolf:

I update the VM daily. I reboot it rarely. I would only ever need to reboot it due to Discord/Canary misbehaving.
I actually don't know if this problem will pop up on Mate. I haven't really used the DE since installing it. (I plan on trying to get Mate to play nicely with Compiz at some point. That's the only reason why I keep it around.)

Here's output:

   

$ pacman -Qs xf86-video
local/xf86-video-vesa 2.3.4-4 (xorg-drivers xorg)
    X.org vesa video driver
local/xf86-video-vmware 13.2.1-3 (xorg-drivers)
    X.org vmware video driver

Steef435:

Here's a snippet from one of the Xorg logs, specifically Xorg.log, but there's a few other ones as well. I can post more of them if you're interested, but this caught my eye, and I think it's probably relevant. The dates match up with the last computer freeze, but I'm not technologically advanced (yet!) to know what I'm looking at, so if you can tell me easily, that would save me the time of figuring it out on my own:

[    18.041] (**) VirtualPS/2 VMware VMMouse: Applying InputClass "libinput pointer catchall"
[    18.041] (II) Using input driver 'libinput' for 'VirtualPS/2 VMware VMMouse'
[    18.041] (**) VirtualPS/2 VMware VMMouse: always reports core events
[    18.041] (**) Option "Device" "/dev/input/event5"
[    18.041] (**) Option "_source" "server/udev"
[    18.041] (II) event5  - (II) VirtualPS/2 VMware VMMouse: (II) is tagged by udev as: Mouse
[    18.041] (II) event5  - (II) VirtualPS/2 VMware VMMouse: (II) device is a pointer
[    18.041] (II) event5  - (II) VirtualPS/2 VMware VMMouse: (II) device removed
[    18.073] (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio1/input/input7/ev
ent5"
[    18.073] (II) XINPUT: Adding extended input device "VirtualPS/2 VMware VMMouse" (type: MOUS
E, id 11)
[    18.073] (**) Option "AccelerationScheme" "none"
[    18.073] (**) VirtualPS/2 VMware VMMouse: (accel) selected scheme none/0
[    18.073] (**) VirtualPS/2 VMware VMMouse: (accel) acceleration factor: 2.000
[    18.073] (**) VirtualPS/2 VMware VMMouse: (accel) acceleration threshold: 4
[    18.074] (II) event5  - (II) VirtualPS/2 VMware VMMouse: (II) is tagged by udev as: Mouse
[    18.074] (II) event5  - (II) VirtualPS/2 VMware VMMouse: (II) device is a pointer
[    18.074] (II) config/udev: Adding input device VirtualPS/2 VMware VMMouse (/dev/input/mouse
2)
[    18.074] (II) No input driver specified, ignoring this device.
[    18.074] (II) This device may have been added with another device file.
[    18.074] (II) config/udev: Adding input device PC Speaker (/dev/input/event4)
[    18.074] (II) No input driver specified, ignoring this device.
[    18.074] (II) This device may have been added with another device file.
[    27.252] (DB) vmware(0): New layout.
[    27.252] (DB) vmware(0): 0: 0 0 2560 1440
[    27.252] (DB) vmware(0): 
[   149.376] [dix] EventToCore: Not implemented yet 
[   982.801] [dix] EventToCore: Not implemented yet 
[  4881.469] [dix] EventToCore: Not implemented yet 
[  5343.963] [dix] EventToCore: Not implemented yet 
[  5343.963] [dix] EventToCore: Not implemented yet 
[  5425.880] [dix] EventToCore: Not implemented yet 
[  5611.669] [dix] EventToCore: Not implemented yet 
[  6105.358] [dix] EventToCore: Not implemented yet 
[  6386.616] [dix] EventToCore: Not implemented yet 
[  6386.617] [dix] EventToCore: Not implemented yet 
[  6520.703] [dix] EventToCore: Not implemented yet 
[  6613.268] [dix] EventToCore: Not implemented yet 
[  6613.272] [dix] EventToCore: Not implemented yet 
[  6702.568] [dix] EventToCore: Not implemented yet 
[  7422.383] [dix] EventToCore: Not implemented yet 
[  7422.390] [dix] EventToCore: Not implemented yet

...but if you would also need to do the research/it ain't obvious to you, then nevermind/no worries. I don't wanna be a burden.

Thanks for the help, guys. I really appreciate it.

Cheers,

Facey

Lone_Wolf · 2018-02-01 10:36:45

[ 7422.390] [dix] EventToCore: Not implemented yet

No idea what it does and if it's related, but dix is part of xorg server.

faceyneck · 2018-02-02 05:39:14

Lone_Wolf; is there another log file I should be looking into? And/or a place/log file I can pull up that says something along the lines of 'this is why your system crashed'?

Thanks again for the help,

Facey

faceyneck · 2018-02-16 01:27:09

Mods, I am currently too busy with work and school to be optimizing Arch/figuring out the root of this issue. I don't think there's a solution to this problem that I'll be able to find out anytime soon, and if I do, I'll make another thread about it.

Arch Linux

#1 2018-01-25 05:39:23

Discord, Discord Canary, .cache vs Cache, and my on-going minor bug

#2 2018-01-25 12:48:32

Re: Discord, Discord Canary, .cache vs Cache, and my on-going minor bug

#3 2018-01-26 12:58:08

Re: Discord, Discord Canary, .cache vs Cache, and my on-going minor bug

#4 2018-02-01 02:49:22

Re: Discord, Discord Canary, .cache vs Cache, and my on-going minor bug

#5 2018-02-01 10:36:45

Re: Discord, Discord Canary, .cache vs Cache, and my on-going minor bug

#6 2018-02-02 05:39:14

Re: Discord, Discord Canary, .cache vs Cache, and my on-going minor bug

#7 2018-02-16 01:27:09

Re: Discord, Discord Canary, .cache vs Cache, and my on-going minor bug

Board footer