Micro sometimes doesn't properly open about micro HOT 12 CLOSED

EDIT:

The guess described below is seemingly wrong (although the problem described below is real and reproducible for example remove read permission from bindings.json). If micro exits from InitBindings function before initializing default bindings it will at least show statusline and ruler (if they aren't disabled in settings.json)

Instructions/questions for issues creator

Micro sometimes doesn't properly open. It is interesting. Does "sometimes" is when user from what micro was open can't open the bindings.json file or when it doesn't exist?

Please say what you see in ~/.config/micro. Do you see there bindings.json file? If yes, what is there?

Did you try to open new terminal and kill micro (not terminal with micro)? Please try it, if my guess is correct, after killing micro you can (I am not absolutely sure) see there something like: Error reading bindings.json file: .......

Can you type something when it happens?

Possible reason

It reminded me one my test with config file bindings.json loading. I can guess it is related to initialization of bindings. I guess it is because in some cases micro can exit before initializing default bindings (Ctrl+q for exit, is one of them)

Point of exit:

Point of default bindings initialization:

P.S: If I am right and the problem is that InitBindings function exits before initializing default bindings, PR #3068 resolves the problem (and reduce code duplication)

from micro.

In case this does actually turn out to be the issue, here is my bindings.json. Since I reset the config and don't remember ever changing it it should be the default.

bindings.json

from micro.

As I wrote in the start of the comment (edit section) seemingly the issue not in the initing of bindings. It looks like problem is before initing bindings. And if problem in initing bindings it would print it before opening micro. But if you for example create folder binding.json instead of file you will see something similar about bindings but window won't be empty. In your case it is empty so it is another problem

from micro.

But if you for example create folder binding.json instead of file you will see something similar about bindings but window won't be empty. In your case it is empty so it is another problem

Yup. The next time the issue occurs I will try killing the process from somewhere else and see what it spits out.

from micro.

this has been happening to me. Right now it's happening every time I try to use micro.

There's no stdout or stderr from micro if I micro &> microlog and kill it.

I did a strace -tt -f -o microlog.txt micro. See the log attached: microlog.txt

At clock time~1:14:00 I run it, and I kill it at ~1:15:00

Seems there is something happening every 8 seconds (1:14:00, 1:14:08, 1:14:16, 1:14:24, ... etc.)

1163222 01:14:00.999757 epoll_pwait(3,  <unfinished ...>
1163230 01:14:00.999768 futex(0xc000580548, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
1163218 01:14:01.009780 <... nanosleep resumed>NULL) = 0
1163218 01:14:01.009861 futex(0x560b138398a0, FUTEX_WAIT_PRIVATE, 0, {tv_sec=7, tv_nsec=925544986}) = -1 ETIMEDOUT (Connection timed out)
1163218 01:14:08.935616 nanosleep({tv_sec=0, tv_nsec=10000000},  <unfinished ...>
1163222 01:14:08.942715 <... epoll_pwait resumed>[], 128, 7935, NULL, 0) = 0
1163222 01:14:08.942754 epoll_pwait(3, [], 128, 0, NULL, 0) = 0
1163222 01:14:08.942838 futex(0xc000580548, FUTEX_WAKE_PRIVATE, 1) = 1
1163230 01:14:08.942918 <... futex resumed>) = 0
1163222 01:14:08.942932 epoll_pwait(3, [], 128, 0, NULL, 0) = 0
1163222 01:14:08.942961 epoll_pwait(3,  <unfinished ...>
1163230 01:14:08.942974 futex(0xc000580548, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
1163218 01:14:08.945790 <... nanosleep resumed>NULL) = 0
1163218 01:14:08.945882 futex(0x560b138398a0, FUTEX_WAIT_PRIVATE, 0, {tv_sec=7, tv_nsec=997034582}) = -1 ETIMEDOUT (Connection timed out)
1163218 01:14:16.943114 nanosleep({tv_sec=0, tv_nsec=10000000},  <unfinished ...>
1163222 01:14:16.946662 <... epoll_pwait resumed>[], 128, 7999, NULL, 0) = 0
1163222 01:14:16.946699 epoll_pwait(3, [], 128, 0, NULL, 0) = 0
1163222 01:14:16.946741 futex(0xc000580548, FUTEX_WAKE_PRIVATE, 1) = 1
1163222 01:14:16.946781 epoll_pwait(3,  <unfinished ...>
1163230 01:14:16.946796 <... futex resumed>) = 0
1163222 01:14:16.946809 <... epoll_pwait resumed>[], 128, 0, NULL, 0) = 0
1163222 01:14:16.946827 epoll_pwait(3,  <unfinished ...>
1163230 01:14:16.946856 futex(0xc000580548, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
1163218 01:14:16.953211 <... nanosleep resumed>NULL) = 0
1163218 01:14:16.953250 futex(0x560b138398a0, FUTEX_WAIT_PRIVATE, 0, {tv_sec=7, tv_nsec=993531664}) = -1 ETIMEDOUT (Connection timed out)
1163218 01:14:24.946978 nanosleep({tv_sec=0, tv_nsec=10000000},  <unfinished ...>
1163222 01:14:24.953327 <... epoll_pwait resumed>[], 128, 7999, NULL, 0) = 0
1163222 01:14:24.953362 epoll_pwait(3, [], 128, 0, NULL, 0) = 0
1163222 01:14:24.953398 futex(0xc000580548, FUTEX_WAKE_PRIVATE, 1) = 1
1163222 01:14:24.953438 epoll_pwait(3,  <unfinished ...>
1163230 01:14:24.953449 <... futex resumed>) = 0
1163222 01:14:24.953466 <... epoll_pwait resumed>[], 128, 0, NULL, 0) = 0
1163222 01:14:24.953487 epoll_pwait(3,  <unfinished ...>
1163230 01:14:24.953505 futex(0xc000580548, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
1163218 01:14:24.957072 <... nanosleep resumed>NULL) = 0
1163218 01:14:24.957114 futex(0x560b138398a0, FUTEX_WAIT_PRIVATE, 0, {tv_sec=7, tv_nsec=996326729}) = -1 ETIMEDOUT (Connection timed out)
1163218 01:14:32.953600 nanosleep({tv_sec=0, tv_nsec=10000000},  <unfinished ...>
1163222 01:14:32.960026 <... epoll_pwait resumed>[], 128, 7999, NULL, 0) = 0
1163222 01:14:32.960076 epoll_pwait(3, [], 128, 0, NULL, 0) = 0
1163222 01:14:32.960119 futex(0xc000580548, FUTEX_WAKE_PRIVATE, 1) = 1
1163230 01:14:32.960150 <... futex resumed>) = 0
1163222 01:14:32.960164 epoll_pwait(3,  <unfinished ...>
1163230 01:14:32.960175 epoll_pwait(3,  <unfinished ...>
1163222 01:14:32.960187 <... epoll_pwait resumed>[], 128, 0, NULL, 0) = 0
1163230 01:14:32.960199 <... epoll_pwait resumed>[], 128, 0, NULL, 0) = 0
1163222 01:14:32.960212 epoll_pwait(3,  <unfinished ...>
1163230 01:14:32.960223 futex(0xc000580548, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
1163218 01:14:32.963728 <... nanosleep resumed>NULL) = 0
1163218 01:14:32.963796 futex(0x560b138398a0, FUTEX_WAIT_PRIVATE, 0, {tv_sec=7, tv_nsec=996388873}) = -1 ETIMEDOUT (Connection timed out)
1163218 01:14:40.960418 nanosleep({tv_sec=0, tv_nsec=10000000},  <unfinished ...>
1163222 01:14:40.966695 <... epoll_pwait resumed>[], 128, 7999, NULL, 0) = 0
1163222 01:14:40.966768 epoll_pwait(3, [], 128, 0, NULL, 0) = 0
1163222 01:14:40.966929 futex(0xc000580548, FUTEX_WAKE_PRIVATE, 1) = 1
1163230 01:14:40.967011 <... futex resumed>) = 0
1163222 01:14:40.967043 epoll_pwait(3,  <unfinished ...>
1163230 01:14:40.967068 epoll_pwait(3, [], 128, 0, NULL, 0) = 0

Lots of futex timeout stuff, maybe a deadlock?

I also tried moving my whole micro config (cd ~/.config; mv micro micro2) but still hangs

from micro.

this has been happening to me. Right now it's happening every time I try to use micro.

Just to be sure. Your screen is also absolutely empty like OP have? You tried to also use -debug option? micro -debug

What OS, terminal emulator, micros commit do you use? Micro's commit can be accessed via micro -version

About strace and bunch of epoll_pwait3; futex; nanosleep. I launched strace with the same parameters and got the similar log file where I saw similar bunch of epoll_pwait3; futex; nanosleep but my micro started and worked normally so it looks like it is a part of normal execution process. About he reason of many futexes: I don't know but have a guess. IIUC micro draws in separate thread and use mutex for synchronization:

While I inspected your strace log I found there common paths micro paths ~/.config/micro; ~/.config/micro/help; ~/.config/micro/syntax; ~/.config/micro/init.lua; ~/.config/micro/plug; ~/.config/micro/settings.json ..... Were the attempts to open them successful? ¯\_(ツ)_/¯.

The most interesting part for me was finding there ~/.config/micro/bindings.json path that means that micro at least reached the function of initialization bindings. Maybe it initialized default bindings maybe it returned before it but it reached that function and it looks like it went further

from micro.

Arch Linux, also was using Konsole. I just tried with kitty and it's the same. Completely blank terminal screen.

micro -debug &> debugout is an empty file - no stdout or stderr

Note the issue is the same if I remove ~/.config/micro

USing arch linux package version 2.0.13-1, the latest as of now
https://archlinux.org/packages/extra/x86_64/micro/
the PKGBUILD references commit 68d88b571de6dca9fb8f03e2a3caafa2287c38d4") # tag: v2.0.13

from micro.

@digitalsignalperson as you have the problem at each attempt to open micro I want to ask you. Did you try another terminals? You and OP have the same OS and terminal so maybe it is a fault of them? ¯\_(ツ)_/¯

from micro.

¯\_(ツ)_/¯ I found in micros history thing that looks similarly #2662 In the issue described some techniques that can probably solve your issue

from micro.

@digitalsignalperson as you have the problem at each attempt to open micro I want to ask you. Did you try another terminals? You and OP have the same OS and terminal so maybe it is a fault of them? ¯_(ツ)_/¯

@dustdfg I also tried kitty terminal and it's the same

¯_(ツ)_/¯ I found in micros history thing that looks similarly #2662 In the issue described some techniques that can probably solve your issue

Ah, k I think I narrowed things down.

Completely uninstalling wl-clipboard solve it yes. But it only fails to open with wl-clipboard if the XWayland clipboard is empty.

• wayland: open a text editor, copy text and then close the editor. This clears the clipboard. micro still works
  • on kde we can confirm clipboard status with qdbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole
• xwayland: copy some text from an X program. do xsel -bc; xsel -pc; xsel -sc to clear all clipboards. micro doesn't work.
  • this also leaves a wl-paste --no-newline process, which does not get destroyed if you killall micro

from micro.

I can no longer reproduce the issue. Can it be closed?

from micro.

@edwloef yes seems to be fixed! Can probably close #2662 too

from micro.