50% success rate of the app starting #151
Comments
|
@jrmcpeek I've split this issue as it's something different to the OSK not minimizing, as I understand it. Are you saying that, on boot, your app doesn't always start, but a Can you provide logs from the failed run? |
|
Transferred to ubuntu-frame as it doesn't sound OSK specific. (Sounds like #130) |
Note that prior to the comment you copied over, I also included canonical/ubuntu-frame-osk#58 (comment):
So at least from the outside, it look(ed)/look(s) like our app worked on the latest Of course, it could be unrelated and simply coincidence.
Correct. Only for Prior to this, we were using
From canonical/ubuntu-frame-osk#58 (comment):
We had not used this, but I see that the next update of our snap includes both: So, I will build this and test again 🙂. I'll report back after testing and see if this is resolved. |
|
Thanks, the lines above this would also be interesting - as that's where the information on why the app was failing should be:
|
|
I was able to recreate the launch failure, using This is definitely a much lower frequency of issue, but in our setup, getting to the machine to restart it will be quite inconvenient if the app simply fails to launch. Here's the log output (as a file, due to its size and line width) from the one failed run across 30 power cycles: It actually looks like the entire And it's possible the app launch is what killed it?: We are building against Flutter 3.13.4. 3.13.5 only includes iOS and mac fixes that don't apply here. Here's a successful boot log for comparison: |
|
Yes, something crashed Frame (with a SEGV) at the same time that "onboard" first creates a surface. Will have a closer look on Monday. (It doesn't look like #130) |
|
@jrmcpeek we're not seeing these failures with other snaps in other environments. Unfortunately, the log you provided above only shows that Frame is segfaulting but doesn't help identify the cause. Whatever is going on, Frame should not be segfaulting and I'd like to track this down. As I cannot reproduce, I need your help. The following will enable some very verbose logging of the interaction between Frame, the OSK and onboard: I hope that, with this. the logs from a failure will contain the clue I need. |
|
I'll run some more testing against I'll report back with my findings, but it may take a day or two. |
|
@AlanGriffiths - I was able to reproduce it again today after about 20 power cycles. Using: Since the last time, I have upgraded I captured the failure with the verbose logging requested (attached, due to size): And, for a quick view of the last moment leading up to the failure: For comparison, here's a successful boot with verbose logging running: |
|
OK, so nothing immediately strikes me as weird, but here's the point of divergence: debug-failed-boot-log.txtdebug-successful-boot-log.txtThat gives me a specific area to look at: Mir the sizing the "ONBOARD" window. (Curiously enough the same area of code that was not working when the OSK hid - what do they say about bugs coming in bunches?) |
|
I may have a reproducer! I left this running for an hour: $ while xvfb-run frame-it qterminal -e ./sleep-exit.sh; do :; done 2>&1 | grep Fatal
!!! Fatal signal received. Attempting cleanup, but deadlock may occurI just need tweak this to capture the crash and look for more evidence |
|
I have a stack trace I hope represents the same problem (it isn't where I expected to see an issue): But am at EOD and on leave tomorrow. |
Oh, no. SIGSEGV in |
|
@jrmcpeek there's a fix for the problem I found in [update] the fix landed, so it is is now on |
Actually, that was premature. the |
It's building right now: https://launchpad.net/~mir-team/+snap/ubuntu-frame-22-edge/+build/2247347 |
I just kicked off the import from github |
|
I'll run it through a bunch of cycles, see if this fixes it, and get back to you! |
|
Using: I was no longer able to reproduce this after a few hours of automated, rapid power cycling. This fix appears to resolve our issue as well. |
Using the following:
This is maybe a little bit better, but still the same issue.
It's about a 50% success rate of the app loading and going full screen or attempting to load, failing a bunch, and the init servicing saying "no more".
100% success rate of the app loading as expected if I simply run a
snap restart onboard.onboardorsystemctl retsart snap.onboard.onboardafter it fails and I ssh into the machine.Originally posted by @jrmcpeek in canonical/ubuntu-frame-osk#58 (comment)
[edit]
The title may be misleading about the frequency of problems. In #151 (comment) it says "one failed run across 30 power cycles"
The log included there shows that Frame segfaults, but doesn't contain anything to help identify why
The text was updated successfully, but these errors were encountered: