Page MenuHomePhabricator

Enlightenment focus / window moving breaks when going to the application menu
Closed, ResolvedPublic

Description

Not sure if this is caused by e22.4 or efl 1.21.0 but going to Applications in the main menu and moving through the selections completely breaks focus and the ability to move windows here (some parts of e are still responsive), some gentoo users are reporting it crashing for them, I might get one to add a stacktrace. Here it is broken in Mesa 18.1.4 (tumbleweed) but not 18.0.2 (Leap) a gentoo user is reporting the following "doesnt work in 18.2.0_rc5, works in <18.2.0_rc5" I should possibly raise this in Mesa

Related Objects

simotek created this task.Sep 8 2018, 4:51 AM
simotek triaged this task as Showstopper Issues priority.
juippis added a subscriber: juippis.EditedSep 8 2018, 4:57 AM

Affected versions:

  • e 0.22.3
  • e 0.22.4
  • efl 1.20.7
  • efl 1.21.0

Just any combination of above doesn't work with latest mesa. 18.2.0 was released a day ago I guess, will try with that one and report how that goes. GPU driver doesn't seem to matter, as long as it uses mesa (so nvidia is safe).

EDIT: Yep, still crashes with mesa-18.2.0.
EDIT-2: Not fixed when downgrading to mesa 18.1.8 either, so I really can't tell what's causing this, but it seems to have started after doing a system update.

bu5hm4n added a subscriber: bu5hm4n.Sep 8 2018, 6:55 AM

is valgrind reporting anything suspicious ?

are you able to test, if you use an open source gpu driver (like radeon, noveau), if this happens with kernel 4.13? because since kernel 4.14 I've got some wacky problems.

for example, for me currently (4.18) sometimes on radeon there seems to be a race somewhere with 2x the same monitor type, whereas the kernel gets confused which one is connected to which connector...

are you able to test, if you use an open source gpu driver (like radeon, noveau), if this happens with kernel 4.13? because since kernel 4.14 I've got some wacky problems.

for example, for me currently (4.18) sometimes on radeon there seems to be a race somewhere with 2x the same monitor type, whereas the kernel gets confused which one is connected to which connector...

I think thats probably different, I'm on 4.17.9 and haven't had issues until now

juippis added a comment.EditedSep 16 2018, 2:18 AM

A status update from me:
I haven't been able to reproduce this after rebooting my machine. Last time after mesa updated, I just relaunched X session and it was wonky with all mesa versions.

Running mesa-18.2.0 on Gentoo right now. Latest efl, latest enlightenment. No issues...

It's a mystery what caused it. Oh, I did remove .e and .elementary directories at some point, if that's any help.

EDIT: I also recompiled efl after those system updates to get valgrind support... is there a list what library update requires efl to be recompiled?

I'm a Gentoo user who is having this issue with both enlightenment 0.22.3 and 0.22.4 and efl 1.20.7 and 1.21.0. Using nouveau and mesa-18.2.4 and am now on kernel-4.14.78. I'd already tried removing my .e and .elementary directories to no avail.

Attached is dump of what I got from valgrind invoking it from xinitrc. I do scientific programming in Fortran and Python and haven't touched C or C++ in years (and very little even then), so this is definitely not in my wheelhouse. I can change valgrind parameters if needed and do any further testing as time permits and with reasonable direction.

Thanks,
Kurt

I'm a Gentoo user who is having this issue with both enlightenment 0.22.3 and 0.22.4 and efl 1.20.7 and 1.21.0. Using nouveau and mesa-18.2.4 and am now on kernel-4.14.78. I'd already tried removing my .e and .elementary directories to no avail.

Attached is dump of what I got from valgrind invoking it from xinitrc. I do scientific programming in Fortran and Python and haven't touched C or C++ in years (and very little even then), so this is definitely not in my wheelhouse. I can change valgrind parameters if needed and do any further testing as time permits and with reasonable direction.

valgrind won't help here. for person-to-person help you'll find help in IRC. just please see that most of the core developers are based in Korea/Australia, so timezone is an issue cause you know sleep and all.

anyways, can you get a gdb backtrace when this happens?

first remove/rename ~/.e-crashdump and then follow this instruction .

you of course may go full gdb, if you want, by sending USR1 to enlightenment_start by killall -USR1 enlightenment_start and then gdb attach to the pidof enlightenment.

For me, timezones are less of an issue than overall having time to look at this again myself....

In any case, it now seems to have been resolved for me with upgrade to efl 1.21.1 (gentoo efl-1.21.1-r1 ebuild from a few days ago. That included a patch for a seemingly related evas preload issue causing described here:
https://phab.enlightenment.org/T7354

Thanks!

ProhtMeyhet closed this task as Resolved.Dec 8 2018, 12:58 PM
ProhtMeyhet reassigned this task from zmike to raster.
ProhtMeyhet added a project: efl.
ProhtMeyhet added subscribers: cedric, stefan_schmidt, zmike.

apparently resolved.

thank you @kzeiler

T7354