xivi: find_shm: Invalid signature, fetching new shm! (blinking display with i3)

[stsquad]

I'm seeing this on my Pixel with the new xiwi framebuffer (running i3 via xinit). I'm also seeing a regular blink while the xiwi frame is in fullscreen which may be related although I haven't confirmed they occur at the same time.

chronos@localhost ~/Downloads/src/crouton.git $ sudo /usr/local/bin/starti3
Entering /mnt/stateful_partition/crouton/chroots/jessie...

X.Org X Server 1.16.2.901 (1.16.3 RC 1)
Release Date: 2014-12-09
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.2.0-4-amd64 x86_64 Debian
Current Operating System: Linux localhost 3.8.11 #1 SMP Wed Dec 10 14:50:53 PST 2014 x86_64
Kernel command line: cros_secure  console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=/dev/dm-0 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="1 vroot none ro 1,0 2506752 verity payload=PARTUUID=e91b60f1-ee07-8a4c-b686-b7e6188c12d5/PARTNROFF=1 hashtree=PARTUUID=e91b60f1-ee07-8a4c-b686-b7e6188c12d5/PARTNROFF=1 hashstart=2506752 alg=sha1 root_hexdigest=a842af158f1c4786441e79a639610a84b73136e1 salt=eb7697527ea6ef45820cf8708107ebde0b128e07a1337d4a7e1f8dd0472f3b85" noinitrd vt.global_cursor_default=0 kern_guid=e91b60f1-ee07-8a4c-b686-b7e6188c12d5 add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic iTCO_vendor_support.vendorsupport=3 gpt 
Build Date: 09 December 2014  10:15:28PM
xorg-server 2:1.16.2.901-1 (http://www.debian.org/support) 
Current version of pixman: 0.32.6
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/Xorg.crouton.1.log", Time: Wed Dec 31 11:20:53 2014
(++) Using config file: "/etc/X11/xorg-dummy.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
/usr/bin/xinit: XFree86_VT property unexpectedly has 0 items instead of 1
Error: not connected.
Cannot connect to extension, retrying...
Error: not connected.
Cannot connect to extension, retrying...
scros
Cannot connect to extension, retrying...
Error: not connected.
Cannot connect to extension, retrying...
Error: not connected.
Cannot connect to extension, retrying...
Error: target STRING not available
Connected to extension, launched crouton in a tab window.
No display support for localhost
find_shm: Invalid signature, fetching new shm!
unable to connect to the rxvt-unicode daemon: Connection refused
/home/alex/.config/i3/setup_systray.sh: line 6: /usr/bin/pasystray: No such file or directory
[libi3] libi3/font.c Using X font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1
i3status: trying to auto-detect output_format setting
i3status: auto-detection: parent process is "sh", looking at its parent
i3status: auto-detected "i3bar"
find_shm: Invalid signature, fetching new shm!
find_shm: Invalid signature, fetching new shm!
find_shm: Invalid signature, fetching new shm!
find_shm: Invalid signature, fetching new shm!
find_shm: Invalid signature, fetching new shm!

chronos@localhost ~/Downloads/src/crouton.git $ sudo enter-chroot croutonversion
Password: 
Entering /mnt/stateful_partition/crouton/chroots/jessie...
crouton: version git
release: jessie
architecture: amd64
targets: xiwi,keyboard,i3,xfce,core,cli-extra
host: version 6310.68.0 (Official Build) stable-channel link 
Not unmounting /mnt/stateful_partition/crouton/chroots/jessie as another instance is using it.

[dnschneid]

That's totally fine debug messaging. It should probably be removed at this point.

[stsquad]

I'll see if I can correlate something else to the blink I'm seeing then. Is there a way to enable/disable debugging from the driver dynamically?

[dnschneid]

If you press the extension button you can enable debugging. I think that also gives you a bar which you can right-click in the main window to enable inspection and check the js console.

[stsquad]

Hmm are we sure there isn't a resource leak here. After running overnight I end up with:

popen2: Failed to create pipe. (Too many open files)
find_shm: Error running helper.
write_image: Cannot find shm, moving on...
popen2: Failed to create pipe. (Too many open files)
find_shm: Error running helper.
write_image: Cannot find shm, moving on...
popen2: Failed to create pipe. (Too many open files)
find_shm: Error running helper.
write_image: Cannot find shm, moving on...
popen2: Failed to create pipe. (Too many open files)
find_shm: Error running helper.
write_image: Cannot find shm, moving on...
popen2: Failed to create pipe. (Too many open files)
find_shm: Error running helper.
^Cwrite_image: Cannot find shm, moving on...

Session terminated, terminating shell.../usr/bin/xinit: connection to X server lost

waiting for X server to shut down Hangup
Hangup
Running exit commands...
urxvt: X connection to ':1' broken, unable to recover, exiting.
Exiting due to signal.
(EE) Server terminated successfully (0). Closing log file.

/usr/bin/xinit: unexpected signal 2
 ...terminated.
Not unmounting /mnt/stateful_partition/crouton/chroots/jessie as another instance is using it.

[dnschneid]

There is. See #1286

[drinkcat]

@stsquad : I tried to reproduce your issue on sid (same i3 version: 4.8) and trusty (version 4.7), and I don't see any blinking (except when creating new windows, but that's expected). (that's a peppy, beta channel)

Is it happening only when some specific apps are running? Is it stock i3 configuration?

[stsquad]

@drinkcat: just plain i3 however I was using my dotfile config. I'll try with blank config and see if that was triggering it. I was having issues using a Win key though - Search should go through as Super_L right?

[drinkcat]

@stsquad : Search as Super_L is tricky:

• Chromium OS remaps Search+arrows to home/end/page up/down. We definitely want to keep that (we could revert that translation as an option, though).
• Chromium OS remaps Search+0..9 to F1..10 keys. We might be able to revert that to Super_L+0..9 (since F-keys are already available on the row above).
• Search alone, and Search+letters, will work as intended (Super_L combo)
• Search+Enter does not currently work, but that's an easy fix.

So, you better use Alt as it currently stands (I'm aware that's not optimal either...).

I'll keep this in mind when I attempt to fix #1275.

Let me know if you can reproduce the blinking issue.

[stsquad]

@drinkcat: I'm sure you'll appreciate that both Ctrl & Alt are sucked up by my Emacs session. Are there any other mod capable keys on the Pixel/ChromeOS?

I'll test i3 with the plain config now...

[drinkcat]

I'm sure you'll appreciate that both Ctrl & Alt are sucked up by my Emacs session. Are there any other mod capable keys on the Pixel/ChromeOS?

Yeah, that's really not great... And I don't think you could remap the 2 Alt keys to have different meaning... Maybe you could use Ctrl+Alt+keys? (or Ctrl-Shift?)

[stsquad]

@drinkcat OK I've been unable to reproduce the problem with my current i3 setup so I think we can close this once the debug message is gone.

In a vaguely related question is there any documentation about the protocol for talking to the extension? I'd like to get Emacs to trigger the focus of the xiwi window when it's dealing with edit requests from the ChromeOS browser.

[dnschneid]

To clarify to whomever wants to pick this up as an "easy-as-pie" commit: the debug output (find_shm: Invalid signature, fetching new shm!) should be silenced.

[tedm]

I like pie. If someone can tell me where to move the mouse and what to type, I'd like to try fixing this.

[dnschneid]

But figuring that out is how you use these simple issues to learn :) Try searching the source code for that string.

[DennisLfromGA]

@ted, Hint:

chronos@localhost ~/Downloads/ $ find crouton.unbundled/ -type f -exec grep -Hi 'Invalid signature, fetching new shm' '{}' \;

*crouton.unbundled/src/fbserver.c:            error("Invalid signature, fetching new shm!");*

[tedm]

Thanks @dnschneid and @Dennis - I will try this, so you're saying the source I'm looking for is local, and not on this big github cloud? I'm anxious that someone like you, David or Drinkcat is just going to fix and commit it before I get a chance, so slow down there and let me take a crack at this please ;)

[tedm]

@Dennis - apparently you have downloaded some source from somewhere. I have a /src directory, but it is just the chroot /usr/src and /usr/local/src from the precise and trusty distros:

localhost Downloads # find / -name fbserver.c localhost Downloads # find / -name crouton.unbundled localhost Downloads # find / -name src /usr/share/chromeos-assets/quickoffice/scripts/lib/qowt/third_party/when/node_modules/curl/src /mnt/stateful_partition/crouton/chroots/trusty/usr/src /mnt/stateful_partition/crouton/chroots/trusty/usr/local/src /mnt/stateful_partition/crouton/chroots/precise/usr/src /mnt/stateful_partition/crouton/chroots/precise/usr/local/src localhost Downloads #

I'm going to take a wild stab in the dark, and presume that this crouton.unbundled/ file is somewhere on this github thing? Am I close?

[dennis]

Please dont use @dennis unless you really want me involved.

[DennisLfromGA]

@tedm - The trick is to use the '-x' option of the crouton installer which untars the source in a folder named 'crouton.unbundled'.

[tedm]

sorry. @DennisLfromGA so finding fbserver.c

at around line 239, what if we comment out the 3rd from the bottom line to this:

/* error("Invalid signature, fetching new shm!"); */

it is still going to try 2 times for a valid sig, and return entry; but the error(text) string will be silenced.

Am I close?

fbserver.c line 239

int try; for (try = 0; try < 2; try++) { /* Check signature / if (entry->map) { if (((uint64_t*)entry->map) == sig) return entry;

        error("Invalid signature, fetching new shm!");
        close_mmap(entry);
    }

[tedm]

the -x works, I now have the crouton.unbundled dir with src and fbserver.c local, but I think we need to fix the find_shm function, beyond just commenting out the error text.

I am missing where find_shm and the error string are concatenated:

"find_shm: Invalid signature, fetching new shm!"

struct cache_entry* find_shm(uint64_t paddr, uint64_t sig, size_t length) { struct cache_entry* entry = NULL;

[dnschneid]

Don't worry, neither @drinkcat nor I will snatch anything tagged "pie". Also, you should be working from a git clone of a fork of the repo if you want to be able to submit pull requests, not from the stuff dumped from the latest installer.

[tedm]

I've setup a forked git clone. I cannot replicate the stream of debug messages that I saw about 10 days ago with precise / xiwi and the previous stable channel on the ARM, in the extension debug window:

These: find_shm: Invalid signature, fetching new shm! find_shm: Invalid signature, fetching new shm!

are not showing on my system. I updated trusty / xfce / xiwi and it doesn't connect with the extension on the arm / stable channel, I think this is noted in another issue. The $sudo startxfce4 -n trusty brings trusty up in a full screen, but no option to run in a window, and the chrome extension shows no connection.

With an updated precise / xfce / xiwi chroot on the current stable channel, it does connect, but unlike the last debug session 2 weeks ago, the streaming "find_shm: Invalid signature, fetching new shm!" I'm getting slower, but still random (to me) debug messages, note the newegg product message!

Can someone verify that trusty / xfce / xiwi shouldn't connect at this time on the arm on the stable channel? And is there a way I can get back to seeing the "find_shm: Invalid signature, fetching new shm!" debug scrolling, so I can try to fix, and upload pull request?

[tedm]

OK, I see it now, it's in the terminal that started the chroot, but is appearing upon closing the windowed xiwi / precise chroot, and it's not endless, it only goes about 10x but then pauses. Unlike the behavior 10 days ago (earlier crouton, earlier Chrome OS stable), closing the windowed xiwi chroot today, leaves the debug file open, and doesn't unmount the chroot, and close the debug file until a ctrl c is hit, then unmounts fine. I think this may be harder pie for me to handle than I first thought...

[tedm]

Both the trusty chroot and the precise chroot have xiwi in their xmethod file at:

$chronos@localhost /mnt/stateful_partition/crouton/chroots/[chrootname]/etc/crouton/xmethod

[tedm]

trusty / xfce / xiwi / extension is now working windowed, I had to add the -t xiwi,extension -u -n trusty where the precise / xfce / xiwi chroot didn't need the 'extension' target explicitly specified.

Same 13 find_shm invalid signatures in terminal after closing window of trusty / xiwi / extension chroot.

[tedm]

in fbserver.c I am at a loss as to why the for loop in the try function appears to loop twice, but the debug output in the terminal upon the window closing, is 13 find_shm: invalid signature messages.

int try; for (try = 0; try < 2; try++) { /* Check signature / if (entry->map) { if (((uint64_t*)entry->map) == sig) return entry;

        error("Invalid signature, fetching new shm!");
        close_mmap(entry);
    }

[tedm]

I'm thinking that we want to silence the stdout, but keep the debug info. going to file, so can we use:

1>&2 stdout to stderr

or

2> ~/Downloads/fbserverdebug.log

or, do we want to silence all output from fbserver and just have it do it's thing quietly?

fbserver &> /dev/null

Am I on the right track, or am I missing something completely here?

[tedm]

OK, so I've thought about this some more... There are several valid error messages in fbserver.c that don't clog the terminal like the find_shm - one does, which on my system, is about once every 10 seconds, while the windowed xiwi chroot is up and fine.

So I'm leaning back towards commenting out the overly verbose debug error:

/* error("Invalid signature, fetching new shm!"); */

I also think that closing the chroot window, should close the debug file and unmount the chroot automatcially without a ctrl c.

[DennisLfromGA]

@ted, I am in no way qualified to answer your questions but...

So I'm leaning back towards commenting out the overly verbose debug error:

I totallly agree, this may be the simplest solution but I think it's best.

I also think that closing the chroot window, should close the debug file and unmount the chroot automatcially without a ctrl c.

It currently doesn't work that way and I don't think it needs to, some may just want to close the (noisy) window and go on with their life, you can still get to the chroot and logoff if you want to close it. Maybe that's just me though; I often use the '-b' background option when starting a chroot just so I can use the same Crosh Window to do other things, since you can only have one instance of it and I prefer using it over the 'Ctrl+Alt+T' crosh window.

[tedm]

@DennisLfromGA Thanks Dennis, I'll make that comment change, and submit a proper git pull request later tonight or tomorrow. I initially pulled my git fork/repo to a windows system, and want to move it to a proper linux box I have available.

I've often run into issues when closing the crosh / shell terminal window when a chroot is running, even before the crouton extension and xiwi. But now with xiwi, if I don't close the chroot window first, the graphics can go fuzzy, sometimes with text that the session ended, sometimes, the window is frozen with a '60s horizontal / diagonal blurry tv image only, but the rest of the system is fine. I think this issue is a known one, or specific to the arm, but I've seen it on both precise and trusty. Below is a screen shot of it:

[tedm]

@DennisLfromGA Can you clarify about how you get crosh / shell terminal windows? The only way I know of is the ctrl alt T way, and I often have several up simultaneously, but the one I"m referring to would be the crosh / shell window that I started the chroot up in, and receives debug info. in. I'm not sure I remember any other ways to get a terminal other than ctrl alt T ?

[DennisLfromGA]

@ted,

Thanks Dennis, I'll make that comment change, and submit a proper git pull request...

I am definitely no authority on this so please don't act based just on my input. If it were me, I'd let @dnschneid and/or @drinkcat weigh in on this before I pulled the trigger on a PR - just sayin'.

Also, you can fork, edit & do the pull request on the github site without having to download anything. When you're perusing the crouton-master branch and arrive at the file: fbserver.c, just click on the pencil icon to the left of the trash can and it will 'fork' the file for editing and allow a pull request if you desire.

I've often run into issues when closing the crosh / shell terminal window when a chroot is running

That is strange, I've never run into that.

[DennisLfromGA]

@tedm,

Can you clarify about how you get crosh / shell terminal windows?

Sure, I use an app called 'Crosh Window', it requires the 'Secure Shell' be installed first. They're very handy.

[tedm]

@DennisLfromGA Thanks Dennis, I'll ask David and Drinkcat what they would like. I have Secure Shell, but only used it years ago when I wasn't in dev mode. What are the advantages of the Crosh Window app and Secure Shell over just ctrl alt t windows? For a real bash shell, I go to the chroot, even enter-chroot is pretty quick, but the few things in crosh / shell like ssh, and scp, seem to work pretty well.

@dnschneid @drinkcat Is the commenting out of the find_shm invalid signature error OK, to silence this from spewing into a terminal window every 10 seconds while a windowed chroot is up and running? Or is there another method that is preferred to silence this? Let me know and I will try initiating a pull request, probably making this change online as Dennis mentioned, and future ones from a tested offline forked clone. Let me know. Thanks.

[dnschneid]

I would turn it into a call to log, so that it shows in verbose mode.

edit: with the level set to 1

[tedm]

OK, this will take some time and thought, but should be interesting.

[DennisLfromGA]

@ted, I'm thinking it might be: (246) error("Invalid signature, fetching new shm!"); (246) log(1, "Invalid signature, fetching new shm!");

[tedm]

@DennisLfromGA Dennis I'm pretty lost about where to start here, I have no idea what the 246 is, and I'm not sure if we already have a log and dest file selected, or if we want syslog logging with logger to /var/log/fbserver.log, etc., and then we want it to display to stdout if -v is used, right? Since you've browsed more of the source, do you want to take this pie one, and I'll grab the next one?

EDIT: OK, I see 246 is the line #, and from previous uses of log() in the file, log takes 3 parameters: loglevel, string, optional variables). So that does look correct to me. @dnschneid or @drinkcat can you verify that the log syntax @DennisLfromGA proposed is the best fix:

change line: 246 to:

log(1, "Invalid signature, fetching new shm!");

[DennisLfromGA]

@ted,

Sorry, I didn't mean to confuse you, the (246) is the line number in fbserver.c where the subject error message was.

I don't have any special knowlege about the fix, I just looked at this and other files on how the log() function was being used - I could be all wrong...

If you like, I'll eat this pie and submit the above to the experts and see if it's a go. ;)

[tedm]

@DennisLfromGA Go for it Dennis, do a Pull Request!!

[DennisLfromGA]

Okay, here's my (simple) proposal - update src/fbserver.c Hopefully I'll be eating pie instead of crow like a few times before.

[dnschneid]

Looks good :)

[DennisLfromGA]

Cool, pr coming your way.

On Mon, Feb 23, 2015 at 9:37 PM, David Schneider notifications@github.com wrote:

Looks good :)

— Reply to this email directly or view it on GitHub https://github.com/dnschneid/crouton/issues/1289#issuecomment-75688034.

DennyL@GMail

[DennisLfromGA]

Thanx @dnschneid, I'll let @tedm know.

Hey @tedm, it's a go - https://github.com/dnschneid/crouton/pull/1437#event-242770471 ...and not humble pie this time ;)

[tedm]

Great Job @DennisLfromGA ! I just updated my precise chroot with the latest crouton, and checked the latest source and your fix is there, and it is behaving well. There are some new messages that are keeping the terminal scrolling with debug.

There's a some new debug txt that comes up about every switch between xiwi chroot window and chrome window, but it's when debug is on, so in the exension app, so I think it's OK.

Also, since it takes about 6 retries for me to connect, should the first 5 retry errors be sent to log or /dev/null ? or perhaps this is system dependent?

Great Job ! I will try on trusty later tonight!

chronos@localhost / $ sudo startxfce4 Entering /mnt/stateful_partition/crouton/chroots/precise... /usr/bin/startxfce4: Starting X server ... Error: not connected. Cannot connect to extension, retrying... Error: not connected. Cannot connect to extension, retrying... Error: not connected. Cannot connect to extension, retrying... Error: not connected. Cannot connect to extension, retrying... Error timeout Cannot connect to extension, retrying... croutoncycle next|prev|cros|list|# Cycles through running graphical chroots. next: switch to the next display prev: switch to the previous display cros: switch directly to Chromium OS list: list all of the active displays and the associated chroot name

: switch to the nth item in the list, zero-indexed

:#: switch directly to the chroot owning the specified display number

croutoncycle next|prev|cros|list|# Cycles through running graphical chroots. next: switch to the next display prev: switch to the previous display cros: switch directly to Chromium OS list: list all of the active displays and the associated chroot name

: switch to the nth item in the list, zero-indexed

:#: switch directly to the chroot owning the specified display number

croutoncycle next|prev|cros|list|# Cycles through running graphical chroots. next: switch to the next display prev: switch to the previous display cros: switch directly to Chromium OS list: list all of the active displays and the associated chroot name

: switch to the nth item in the list, zero-indexed

:#: switch directly to the chroot owning the specified display number

Connected to extension, launched crouton in a tab window. Agent pid 30624 croutoncycle next|prev|cros|list|# Cycles through running graphical chroots. next: switch to the next display prev: switch to the previous display cros: switch directly to Chromium OS list: list all of the active displays and the associated chroot name

: switch to the nth item in the list, zero-indexed

:#: switch directly to the chroot owning the specified display number

[dnschneid]

Disregard that. It'll be gone when xiwi-app is merged.

[tedm]

@dnschneid OK, trusty / precise / xiwi upgrade is also working fine on the arm. I had one crash (xiwi chroot window went away, and couldn't come back, chrome OS was fine), with this message in terminal:

socket_client_read_frame_header: Connection close from WebSocket client.

, and some red js errors in the extension app debug window.

Right now, trusty / xiwi is running fine, but some scary errors are in the terminal, but no red js errors in extension debug window. The terminal errors are:

croutonwebsocket error: Error timeout Error: target STRING not available croutonwebsocket error: Rsocket_client_read_frame_header: Connection close from WebSocket client.Error: target STRING not available croutonwebsocket error: EError: not connected.

also, now when clicking on debug, the xiwi chroot window does a long pause flicker, which is OK, but closing the xiwi chroot window by ctrl-c in the crosh terminal, still gives the horizontal purple/green bars, but this is OK (by design??) as long as the "Disconnected, please close the window" text is visible.

@DennisLfromGA says he can start chroots, and then close terminal windows and the chroots still run. Is that an intel only feature?

[dnschneid]

I think @DennisLfromGA uses the -b parameter to start* to fork into the background. If you use that, you can then close the terminal. For all the other stuff, you should file bugs if the behavior concerns you.

[tedm]

-b works great ('sudo start*' & starts the job, but leaves it stopped), I can launch a nice precise and trusty window, and then just close the window. Very sweet. A bit disconcerting though, as with no terminal output, I'm inclined to start a chroot again, just to ensure it unmounted cleanly ;)