Ticket #1105 (closed defect: fixed in core)

Opened 4 years ago

Last modified 3 years ago

Cannot close or switch between windows

Reported by: stiell Owned by: Heinervdm
Priority: major Milestone:
Component: SHR Image Version: SHR-unstable
Keywords: Cc:

Description

Using the "Illume2 SHR" profile (the "recommended profile" according to SHR manual) with the latest SHR-unstable image (20100507), There is no way to close an application or switch between them.

According to the SHR manual, this is supposed to be done using a "sliding shelve available by tapping Top Shelf on any empty space". I've tried tapping an empty part of the top shelf, but nothing happens at all.

The "Illume-Home" profile has "back" and "close" buttons on the bottom of the screen, but there's no such thing in the "Illume2 SHR" profile.

Pressing the "home" button in the top shelf only hides the window, and in some cases, like with the power button window, there's no way of getting back to it.

Attachments

Xsession.log Download (6.7 KB) - added by stiell 3 years ago.
backtrace-efreet_desktop_cache_create Download (2.7 KB) - added by stiell 3 years ago.
backtrace of efreet_desktop_cache_create segfault

Change History

comment:1 follow-up: ↓ 4 Changed 4 years ago by TAsn

Try running it from terminal :(
There's currently an issue with it not registering with illume correctly. (Starts too early).
The name of the application is shr_elm_softkey.

comment:2 Changed 4 years ago by Heinervdm

  • Milestone set to MS2

comment:3 Changed 4 years ago by jama

As workarround you can put some delay to Xsession script, then it should start right with your illume.

sed -i 's#DISPLAY=:0.0 /usr/bin/shr_elm_softkey#sh -c "sleep 20 && /usr/bin/shr_elm_softkey"#g' /etc/X11/Xsession.d/89shr_elm_softkey

This is not "right" solution, because ie with first time wizard, you have to finish it in less than 20s (not problem if you're waiting for it to show).

comment:4 in reply to: ↑ 1 Changed 4 years ago by Jonci

Bug in SHR-Testing still active.

Workaraounds did not work there (no file /etc/X11/Xsession.d/whatsoever

comment:5 Changed 4 years ago by jama

That "right" solution I was talking about was applied long time ago
 http://git.shr-project.org/git/?p=shr-e-gadgets.git;a=commit;h=ce3de686930676b54e182190216d66930ddc0cb4

 http://git.shr-project.org/git/?p=shr-wizard.git;a=commit;h=0342a0b36ab3df7e980fe7a045c905cee8f2a7e8

unfortunately in latest EFL it's broken again (maybe because of efreet changes) and sometimes shr_elm_softkey.desktop is not started at all from ~/.e/e/applications/startup/.order

comment:6 Changed 4 years ago by jama

I don't see it with my EFL newer than what's in shr-u, so it would be great if someone tries this:

$ mv /usr/bin/shr_elm_softkey /usr/bin/shr_elm_softkey-real
$ cat << EOF > /usr/bin/shr_elm_softkey
#!/bin/sh

LOG=/var/log/shr_elm_softkey.log
echo START >> $LOG
date >> $LOG
shr_elm_softkey-real & >> $LOG
ps aux | grep shr_elm_softkey >> $LOG
echo END >> $LOG
EOF

$ chmod +x /usr/bin/shr_elm_softkey

and then show what was in .log after unsuccessfull startup, if that bash was even started at all, maybe even add strace before shr_elm_softkey-real.

comment:7 follow-up: ↓ 8 Changed 4 years ago by jama

Ahh backslash lost and better to get stderr too

cat << EOF > /usr/bin/shr_elm_softkey
#!/bin/sh
LOG=/var/log/shr_elm_softkey.log
echo START >> \$LOG
date >> \$LOG
shr_elm_softkey-real >> \$LOG 2>> \$LOG &
ps aux | grep shr_elm_softkey >> \$LOG
echo END >> \$LOG
EOF

comment:8 in reply to: ↑ 7 Changed 4 years ago by dforsi

The bash script wasn't called after a fresh install of SHR 2011.1 RC1 15th Dec 2010 and a reboot.

After I ran
enlightenment_remote -default-profile-set default
it was called at the next reboot (and the softkeys were displayed) and the log contained:
START
Mon Dec 27 11:44:36 CET 2010
root 237 3.0 0.4 2644 548 ? SNs 11:44 0:00 /bin/sh /usr/bin/shr_elm_softkey
root 239 0.0 0.7 13288 964 ? RN 11:44 0:00 shr_elm_softkey-real
root 241 0.0 0.4 2644 532 ? SN 11:44 0:00 grep shr_elm_softkey
END

After running that enlightenment_remote command an e.cfg file was created:

-drwxr-xr-x root/root 0 2010-12-27 11:13 home/root/.e/e/config/
--rw------- root/root 54 2010-12-27 11:13 home/root/.e/e/config/profile.cfg
+drwxr-xr-x root/root 0 2010-12-27 11:25 home/root/.e/e/config/
+drwxr-xr-x root/root 0 2010-12-27 11:25 home/root/.e/e/config/default/
+-rw------- root/root 12782 2010-12-27 11:25 home/root/.e/e/config/default/e.cfg
+-rw------- root/root 50 2010-12-27 11:25 home/root/.e/e/config/profile.cfg

comment:9 Changed 4 years ago by jama

Did you see 1st time wizard on first boot after fresh install, right?

Because only this wizard puts shr_elm_softkey.desktop to ~/.e/e/applications/startup/.order

BTW: I've pushed newer EFL revision to OE..
New shr-u images are already built in tests/shr-unstable.

comment:10 Changed 4 years ago by dforsi

Yes, I saw it asking which profile to use (only one to choose from) and then asking for prefix numbers. The wizard appeared again when I ran enlightenment_remote -default-profile-set default

comment:11 Changed 4 years ago by stiell

Still broken in SHR-testing 2011.1 RC2.

I tried the shell script wrapper above, but after reboot, there's no /var/log/shr_elm_softkey.log, so it doesn't seem to be called at all.

comment:12 Changed 4 years ago by amog2011

Did you see 1st time wizard on first boot after fresh install, right?

air jordan

comment:13 Changed 4 years ago by Blue2

I've got the same issue here with a fresh SHR unstable on my GTA02 A7.

The wizard started and put "shr_elm_softkey.desktop" in ~/.e/e/applications/startup/.order.
/usr/share/applications/shr_elm_softkey.desktop exists and contains

[Desktop Entry]
Name=shr_elm_softkey
Exec=shr_elm_softkey
Terminal=false
Type=Application
NoDisplay=true
StartupNotify=false
Categories=Utility;

Using the shellscript wrapper above, no logfile is created at system start.

Removing "NoDisplay=true" and starting it using the desktop icon works.

Kernel: uImage-2.6.34-r7-oe17-om-gta02.bin
rootfs: full-om-gta02.jffs2 from 07-Apr-2011 03:33

comment:14 Changed 4 years ago by Heinervdm

comment:15 Changed 3 years ago by stiell

Still broken on a fresh NAND install of shr-testing2011.1 rc3-20110423. Worked on the very first boot (the one with the wizard), then broken again after next boot.

comment:16 follow-up: ↓ 17 Changed 3 years ago by Heinervdm

@stiell
If you want to help solving this issue, please install the package i in my previus comment and post the results, as well as the log entries from /var/log/Xsession.log

If it doesn't work, you can try to run the following command:
/usr/lib/efreet/efreet_icon_cache_create

Changed 3 years ago by stiell

comment:17 in reply to: ↑ 16 Changed 3 years ago by stiell

Replying to Heinervdm:

If you want to help solving this issue, please install the package i in my previus comment and post the results, as well as the log entries from /var/log/Xsession.log

Installed and rebooted. Still not working. Xsession.log attached.

If it doesn't work, you can try to run the following command:
/usr/lib/efreet/efreet_icon_cache_create

There's no such file. There's a file with a similar name, but it segfaults:

root@om-gta02 ~ # /usr/lib/efreet/efreet_icon_cache_create
-sh: /usr/lib/efreet/efreet_icon_cache_create: not found
root@om-gta02 ~ # /usr/lib/efreet/efreet_desktop_cache_create
Segmentation fault

comment:19 follow-up: ↓ 20 Changed 3 years ago by Heinervdm

@jama
yes seems so

@stiell
ok that's the result i've expected.

I think if we find the cause for this segfault we will fix the other problem too.

Changed 3 years ago by stiell

backtrace of efreet_desktop_cache_create segfault

comment:20 in reply to: ↑ 19 Changed 3 years ago by stiell

FWIW, I've added a backtrace of the efreet_desktop_cache_create segfault.

comment:21 follow-up: ↓ 22 Changed 3 years ago by Heinervdm

Ok, the segfault itself is just a unimportant symptome.

The problem is, that the eet file can't be opened.

@stiell
can you check at which point _eet_data_descriptor_new() in eet_data.c line 1733 return null?
Because eddc is Null or because the calloc fails?

comment:22 in reply to: ↑ 21 Changed 3 years ago by stiell

Replying to Heinervdm:

can you check at which point _eet_data_descriptor_new() in eet_data.c line 1733 return null?
Because eddc is Null or because the calloc fails?

That function does not seem to return null at all:

(gdb) break _eet_data_descriptor_new
Breakpoint 1 (_eet_data_descriptor_new) pending.
(gdb) run
[...]
Breakpoint 1, _eet_data_descriptor_new (eddc=0xbe9bc5c0, version=2)
    at eet_data.c:1734
(gdb) finish
Run till exit from #0  _eet_data_descriptor_new (eddc=0xbe9bc5c0, version=2)
    at eet_data.c:1734
efreet_desktop_edd () at efreet_cache.c:530
Value returned is $1 = (Eet_Data_Descriptor *) 0x13070
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.

comment:23 follow-up: ↓ 24 Changed 3 years ago by Heinervdm

  • Owner changed from ainulindale to Heinervdm
  • Status changed from new to assigned
  • Milestone changed from MS2 to MS1

Oops, i did a mistake.
 http://trac.enlightenment.org/e/browser/trunk/efreet/src/bin/efreet_desktop_cache_create.c?rev=56356#L433 isn't only reached if goto edd_error; is called, it's also reached in case of a goto error;

this means that it fails somewhere between  Line 277 and  Line 363

Can you find out from what point it jumps to Line 433? And perhaps why?

comment:24 in reply to: ↑ 23 ; follow-up: ↓ 25 Changed 3 years ago by stiell

Replying to Heinervdm:

Can you find out from what point it jumps to Line 433? And perhaps why?

It jumps to line 430 from  line 313 (if (map == MAP_FAILED) goto error;).

313	in efreet_desktop_cache_create.c
(gdb) next
430	in efreet_desktop_cache_create.c

If I check errno right after the mmap call, I get 22 (EINVAL).

comment:25 in reply to: ↑ 24 Changed 3 years ago by stiell

I just did some tests with Python's mmap, and I get the same errno 22 if I try to use mmap on a file on jffs2 that's opened writable. It doesn't matter if prot is only PROT_READ; as long as the fd itself is opened writable, mmap will fail with errno 22. If I do the same on a file in tmpfs, or open it read-only, it works.

In efreet_desktop_cache_create.c, dirsfd is opened writable, but I can't see any reason for doing so, as nothing is written to the file.

comment:26 Changed 3 years ago by Heinervdm

fixing efreet_desktop_cache_create.c is probably easy, the main problem is another:
the same operation is done in 4 other places of efreet, and there it needs write access.

In revision  56910 the mmap is removed from that file. But it's still there in other files.

comment:27 follow-up: ↓ 28 Changed 3 years ago by Heinervdm

I compiled r56910 of efreet, can you test if the startup problem is fixed with that version?
 http://downloads.vdm-design.de/libefreet1_1.0.999+svnr56910-r0.0.6_armv4t.ipk
Because the major version of efreet has changed, i've recompiled e-wm too:
 http://downloads.vdm-design.de/e-wm_0.16.999.060+svnr56372-r21.6_armv4t.ipk

comment:28 in reply to: ↑ 27 ; follow-up: ↓ 29 Changed 3 years ago by stiell

Replying to Heinervdm:

I compiled r56910 of efreet, can you test if the startup problem is fixed with that version?
 http://downloads.vdm-design.de/libefreet1_1.0.999+svnr56910-r0.0.6_armv4t.ipk

Installed that and rebooted, shr_elm_softkey now starts up and works correctly at boot. (All desktop icons except Pidgin were gone after first reboot, but were back after I renamed ~/.e and rebooted.)

comment:29 in reply to: ↑ 28 Changed 3 years ago by Heinervdm

Replying to stiell:

Installed that and rebooted, shr_elm_softkey now starts up and works correctly at boot. (All desktop icons except Pidgin were gone after first reboot, but were back after I renamed ~/.e and rebooted.)

I've seen this too, but for me a reboot solved the problem and the icons were back.

comment:30 Changed 3 years ago by raul

can apply this fix to shr-u too, please?

comment:31 Changed 3 years ago by jama

Cannot test it in my shr-u build (because I'm using newer EFL), but pushed to shr-u and will be in feeds later today or tomorrow.

comment:32 Changed 3 years ago by slyon

  • Status changed from assigned to closed
  • Resolution set to fixed in core

shr-unstable is unsupported now.
In shr-core we have shr_elm_softkey, which is the "sliding shelfe" to choose and close windows.

comment:33 Changed 3 years ago by morphis

  • Milestone MS1 deleted

Milestone MS1 deleted

Note: See TracTickets for help on using tickets.