Searching in 'Run Everything' locks up Enlightenment, process at 100% CPU usage #20

New Issue

rennod · 2022-10-01T11:59:11-07:00

rennod commented

2022-10-01 11:59:11 -07:00

Typing to search in the 'Run Everything' menu locks up the complete desktop, I have to kill the main Enlightenment process from another tty to get out of it. Said process is at 100% CPU usage after triggering the bug.

I tried to start over with a new, fresh .e profile, still happens. Bit unsure how to find out what the process is doing with gdb...

Up to date Arch builds, so Enlightenment 0.25.4 and EFL 1.26.3. I'm just starting Enlightenment with startx, but it also happens in Wayland.

Typing to search in the 'Run Everything' menu locks up the complete desktop, I have to kill the main Enlightenment process from another tty to get out of it. Said process is at 100% CPU usage after triggering the bug. I tried to start over with a new, fresh .e profile, still happens. Bit unsure how to find out what the process is doing with gdb... Up to date Arch builds, so Enlightenment 0.25.4 and EFL 1.26.3. I'm just starting Enlightenment with startx, but it also happens in Wayland.

raster commented

2022-10-03 10:06:41 -07:00

i don't see it here... well on git - i backported various fixes from git master. does git master work (try install the efl-git and enlightenment-git aur's). i want to know if its a fix already in git master but somehow not in stable or it's something specific to you?

raster self-assigned this 2022-10-03 10:07:54 -07:00

rennod commented

2022-10-03 15:44:37 -07:00

Build both efl-git and enlightenment-git, no change. Still locks up, process sits at 100% CPU.

rennod commented

2022-10-03 17:06:44 -07:00

So i looked a bit at the .e-log.log output and after a few tries reproducing the issue the only relevant log message seems to be

WD: Enlightenment main loop hung. No response to ping for 10sec

So i looked a bit at the .e-log.log output and after a few tries reproducing the issue the only relevant log message seems to be ``` WD: Enlightenment main loop hung. No response to ping for 10sec ```

raster commented

2022-10-08 10:42:37 -07:00

ooook - the watchdog found a mainloop lockup. can you get a backtrace with symbols?

https://www.enlightenment.org/contrib/enlightenment_debugging

also see efl debugging. i need to know where it hangs.

ooook - the watchdog found a mainloop lockup. can you get a backtrace with symbols? https://www.enlightenment.org/contrib/enlightenment_debugging also see efl debugging. i need to know where it hangs.

rennod commented

2022-10-08 19:18:18 -07:00

Bit tricky, the process seems to get restarted after some time. I'm not sure how much sense the bt makes. I did one of all threads too.

gdb.txt

17 KiB

raster commented

2022-10-09 23:39:33 -07:00

the watchdog will restart e after a bit if a complete mainloop lockup is detected. evry_fuzzy_match() seems to be the problem... this loop here:

              /* go to next word */
              for (; (p[0] && (s_len - (p - str) >= (unsigned int)ii)) &&
                   !((isspace(*p) || (ip && ispunct(*p))));
                   p += ii)
                {
                   if (!_evry_utf8_next(p, &ii)) break;
                }

i can only imagine ii stops goinng up0 - it's not advancing... for some reason. why? what sgtrng is it looking at? what is it not advancing on (what char)?

the watchdog will restart e after a bit if a complete mainloop lockup is detected. evry_fuzzy_match() seems to be the problem... this loop here: /* go to next word */ for (; (p[0] && (s_len - (p - str) >= (unsigned int)ii)) && !((isspace(*p) || (ip && ispunct(*p)))); p += ii) { if (!_evry_utf8_next(p, &ii)) break; } i can only imagine ii stops goinng up0 - it's not advancing... for some reason. why? what sgtrng is it looking at? what is it not advancing on (what char)?

raster commented

2022-10-10 00:20:44 -07:00

can you try this patch in e?

diff --git a/src/modules/everything/evry_util.c b/src/modules/everything/evry_util.c
index 7817c7ff6..7daf50412 100644
--- a/src/modules/everything/evry_util.c
+++ b/src/modules/everything/evry_util.c
@@ -52,8 +52,9 @@ evry_util_file_detail_set(Evry_Item_File *file)
 static inline Eina_Unicode
 _evry_utf8_next(const char *buf, int *iindex)
 {
+   int pidx = *iindex;
    Eina_Unicode u = eina_unicode_utf8_next_get(buf, iindex);
-   if ((!u) || ((u >= 0xdc80) && (u <= 0xdcff))) return 0;
+   if ((!u) || ((u >= 0xdc80) && (u <= 0xdcff)) || (pidx != *iindex)) return 0;
    return u;
 }

can you try this patch in e? ``` diff --git a/src/modules/everything/evry_util.c b/src/modules/everything/evry_util.c index 7817c7ff6..7daf50412 100644 --- a/src/modules/everything/evry_util.c +++ b/src/modules/everything/evry_util.c @@ -52,8 +52,9 @@ evry_util_file_detail_set(Evry_Item_File *file) static inline Eina_Unicode _evry_utf8_next(const char *buf, int *iindex) { + int pidx = *iindex; Eina_Unicode u = eina_unicode_utf8_next_get(buf, iindex); - if ((!u) || ((u >= 0xdc80) && (u <= 0xdcff))) return 0; + if ((!u) || ((u >= 0xdc80) && (u <= 0xdcff)) || (pidx != *iindex)) return 0; return u; } ```

rennod commented

2022-10-10 12:21:55 -07:00

So applied that on top of current git, same symptoms, new bt, different place...

gdb2.txt

31 KiB

raster commented

2022-10-11 03:25:32 -07:00

hmm maybe it was not that loop? maybe its always in

while ((m_cnt < m_num) && (*next != 0))
  {
...
  }

if its always some line within this loop (line 107 -> 243) is it always stuck in this range somewhere?

hmm maybe it was not that loop? maybe its always in while ((m_cnt < m_num) && (*next != 0)) { ... } if its always some line within this loop (line 107 -> 243) is it always stuck in this range somewhere?

rennod commented

2022-10-11 14:34:53 -07:00

It looks like it's always within that range.

raster commented

2022-11-01 02:26:24 -07:00

hmm well i'd need to know more like what is m_cnt and m_num? what is next and *next?

rennod commented

2022-11-06 06:42:18 -08:00

I did some printf debugging. Attached is part of the log, it indeed starts looping here forever.

e-log.log

913 B

andre-schulz commented

2023-03-04 04:21:09 -08:00

Hi,

I think I have a similar issue on my system and I investigated it a bit. I have a file in my home directory whose name is Readme \366ffnen which is encoded in the Windows-1252 character set (366 oct = 246 dec = "ö" (German umlaut)) probably because it was installed via Wine ages ago. The everything module will enter an infinite loop in evry_fuzzy_match() when starting a search because of this file name. Here's a minimal repro case which will cause the infinite loop:

evry_fuzzy_match("\366", "a");

It seems that the issue was introduced by commit fd26c7b224 because if I apply the patch below, which reverts a part of that commit, evry_fuzzy_match() no longer runs into an infinite loop with the repro case inputs:

diff --git a/src/modules/everything/evry_util.c b/src/modules/everything/evry_util.c
index 7817c7ff6..5f733f5fd 100644
--- a/src/modules/everything/evry_util.c
+++ b/src/modules/everything/evry_util.c
@@ -220,7 +220,7 @@ evry_fuzzy_match(const char *str, const char *match)
                        !((isspace(*p) || (ip && ispunct(*p))));
                        p += ii)
                     {
-                       if (!_evry_utf8_next(p, &ii)) break;
+                       if (!eina_unicode_utf8_next_get(p, &ii)) break;
                     }
                   ii = 0;
                   for (; (p[0] && (s_len - (p - str) >= (unsigned int)ii)) &&

Not sure if this a correct fix for this issue though.

Hi, I think I have a similar issue on my system and I investigated it a bit. I have a file in my home directory whose name is `Readme \366ffnen` which is encoded in the Windows-1252 character set (366 oct = 246 dec = "ö" (German umlaut)) probably because it was installed via Wine ages ago. The everything module will enter an infinite loop in `evry_fuzzy_match()` when starting a search because of this file name. Here's a minimal repro case which will cause the infinite loop: `evry_fuzzy_match("\366", "a");` It seems that the issue was introduced by commit fd26c7b224e1010df8e4b24d174818b2add39b0b because if I apply the patch below, which reverts a part of that commit, `evry_fuzzy_match()` no longer runs into an infinite loop with the repro case inputs: ``` diff --git a/src/modules/everything/evry_util.c b/src/modules/everything/evry_util.c index 7817c7ff6..5f733f5fd 100644 --- a/src/modules/everything/evry_util.c +++ b/src/modules/everything/evry_util.c @@ -220,7 +220,7 @@ evry_fuzzy_match(const char *str, const char *match) !((isspace(*p) || (ip && ispunct(*p)))); p += ii) { - if (!_evry_utf8_next(p, &ii)) break; + if (!eina_unicode_utf8_next_get(p, &ii)) break; } ii = 0; for (; (p[0] && (s_len - (p - str) >= (unsigned int)ii)) && ``` Not sure if this a correct fix for this issue though.

raster referenced this issue from a commit

2023-03-05 01:35:55 -08:00

evrything - fix handling of broken strings without looping forever

raster closed this issue

2023-03-05 01:35:55 -08:00

raster commented

2023-03-05 01:38:50 -08:00

:) thanks! now i know what caused it! :)

Sign in to join this conversation.