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

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.

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?

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

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

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.

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

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)?

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;
 }

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

gdb2.txt

31 KiB

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?

It looks like it's always within that range.

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

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

e-log.log

913 B