Phone not usable while a call comes in - followed by "restart"

[Uranicus]

My system:

current build number: 225
device name: krillin
channel: ubuntu-touch/rc-proposed/bq-aquaris.en
last update: 2016-01-09 06:52:53
version version: 225
version ubuntu: 20160109
version device: 20151216-378d4f3
version custom: 20151111--36-46-vivid

What happened:
Someone called me and I wanted to take the call on the phone (nothing attached to the phone). The screen was locked and I pressed the power button to unlock the screen. The phone did not react on any pushed buttons. The phone continued ringing but I was not able to do anything with the phone during this time.

During the next minute the phone was blocked. After this period a "restart" followed.

"Restart":
The restart was not a real reset. The phone screen was black. Then approx. 1 - 2 minutes after the call was gone, the screen went on again and the ubuntu logo with the dots appeared (same screen when you start the phone but without the "bq"-screen).

I did not need to enter the PIN code of the SIM card. The phone was again fully operational.

This happened on January, 10th at approx. 13:30 h. I have attached the sys.log for your review and hopefully for tracing back the issue to the root cause.

Matthias

[Ilonka (ilonka-o)]

I had a similar issue two days ago. A phone call came in and I couldn't accept it or do anything else. In different to the report above my phone didn't start alone. I have to made a "Power on" + "Vol Up" restart because nothing else worked. After restart (which needed more time as normal) my phone worked again normal.

I use a BQ 4.5 Aquaris
Ubuntu 15.04 OTA 8.5
Ubuntu-Image Part 20151210

If you need further information please let me know.

[Jean-Baptiste Lallement (jibel)]

@Uranicus, thanks for your report. Your syslog is rather big, could you please tell approximately at what time and day is happened? Also could you please attach the content of the directory /home/phablet/.cache/upstart/

@Ilonka, could you please file another report and attach the content of the directory /home/phablet/.cache/upstart/ and the file /var/log/syslog from when it happened ?

Thanks in advance.

[Uranicus (matthias.ritter)]

@Jean-Baptiste

This happened on January, 10th at approx. 13:30 h.

I have attached the upstart directory. It seems that the directory has not data from yesterday.

Which data should I sent in case I report such a bug next time? sys.log and upstart? Anything else?

[Uranicus (matthias.ritter)]

Now the attachment ...

[Jean-Baptiste Lallement (jibel)]

Thanks for the logs. /var/log/syslog, /home/phablet/.cache/upstart and /var/crash are usually good place to start gathering information.

From syslog lightdm restarted
Jan 10 13:31:17 ubuntu-phablet kernel: [62846.465084]init: lightdm main process (1966) terminated with status 1
Jan 10 13:31:17 ubuntu-phablet kernel: [62846.465143]init: lightdm main process ended, respawning

Which could be due to mir stopping according to this error unity.log.3.gz
[1452429068.600713] <ERROR> mircommon: Caught exception at Mir/EGL driver boundary (in queueBuffer): /build/mir-4B0JBP/mir-0.18.0+15.04.20151216.1/src/client/buffer_stream.cpp(169): Throw in function virtual MirWaitHandle* {anonymous}::ExchangeSemantics::submit(const std::function<void()>&, mir::geometry::Size, MirPixelFormat, int)
Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
std::exception::what: disconnected: no new buffers

[1452429068.629109] <ERROR> mircommon: Caught exception at Mir/EGL driver boundary (in queueBuffer): /build/mir-4B0JBP/mir-0.18.0+15.04.20151216.1/src/client/buffer_stream.cpp(169): Throw in function virtual MirWaitHandle* {anonymous}::ExchangeSemantics::submit(const std::function<void()>&, mir::geometry::Size, MirPixelFormat, int)
Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
std::exception::what: disconnected: no new buffers

[1452429068.662103] <ERROR> mircommon: Caught exception at Mir/EGL driver boundary (in queueBuffer): /build/mir-4B0JBP/mir-0.18.0+15.04.20151216.1/src/client/buffer_stream.cpp(169): Throw in function virtual MirWaitHandle* {anonymous}::ExchangeSemantics::submit(const std::function<void()>&, mir::geometry::Size, MirPixelFormat, int)
Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
std::exception::what: disconnected: no new buffers

qtmir.mir: SessionListener::stopping - this= SessionListener(0xb191eed4) session= 0xae201d54
[1452429068.693550] <ERROR> mircommon: Caught exception at Mir/EGL driver boundary (in queueBuffer): /build/mir-4B0JBP/mir-0.18.0+15.04.20151216.1/src/client/buffer_stream.cpp(169): Throw in function virtual MirWaitHandle* {anonymous}::ExchangeSemantics::submit(const std::function<void()>&, mir::geometry::Size, MirPixelFormat, int)
Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
std::exception::what: disconnected: no new buffers

Signal caught by Mir, stopping Mir server..

@Uranicus, is there any crash file from the date of the incident in /var/crash?

Thanks.

[Uranicus (matthias.ritter)]

@Jean-Baptiste:

I have checked the directory /var/crash/. There is no file from this time interval.

Uranicus

[kevin gunn (kgunn72)]

@Uranicus
From your original report, can I ask when you described this...

>Someone called me and I wanted to take the call on the phone
>(nothing attached to the phone). The screen was locked and
>I pressed the power button to unlock the screen. The phone did
>not react on any pushed buttons. The phone continued ringing
>but I was not able to do anything with the phone during this time.

What was on the screen when you "wanted to take the call"? was the incoming call screen displayed? or was the screen not on?
What exactly do you mean by "screen was locked"?
I'm a little confused b/c hitting the power button during an incoming call will/should terminate the incoming call and turn the screen off (if it is on).

[Uranicus (matthias.ritter)]

@kevin gunn
To be honest, I can not guarantee what the screen was when I wanted to take the incoming call. Since the phone was in my pocket I might have pushed something, may the screen be on or off. When I had the phone in my hand the screen was black (this is what I meant with "screen locked").

Since the screen was off (black) and the phone was ringing, I wanted to turn on the screen by pushing the power button, what I normally do to turn on the screen. But nothing happened. The phone was continuously ringing even though I pushed the power button. The screen was black during this period of time.

The screen only came back (screen was on again) after approximately one minute (this is what I meant with "During the next minute the phone was blocked."). The screen was on again when the ubuntu start screen with the dots appeared.

I hope this helps,

Uranicus

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Patrick Poulin (pcpnielsen)]

Same issue with my BQ E5

- Phone rings
- I take it up from the pocket or table
- Black screen and not waking up if I press the power button.
- Keeps ringing
- The screen wakes up 1-3 minuts after and is again usable.
- No recent or missed call are registeret

Build number: 229

[Pat McGowan (pat-mcgowan)]

I have seen a similar symptom twice in the past 4 days In both cases a new SMS followed an exchange of SMS's within the previous minute. I hear the notification, phone is in pocket so proximity will be enabled, take phone out and it stays black, pressing power does not turn on the screen, then the UI restarts.

There were not crash files.

I see the same Mir exception in the unity log as noted in comment 6

[Patrick Poulin (pcpnielsen)]

Forgot log files

syslog text:
Jan 20 10:51:58 ubuntu-phablet kernel: [ 6749.701233]init: lightdm main process (1678) terminated with status 1
Jan 20 10:51:58 ubuntu-phablet kernel: [ 6749.701292]init: lightdm main process ended, respawning

[Kevin DuBois (kdub)]

The logs in comment #6 are a normal reaction that unity8 would have if USC crashed. So I'd guess from what's gathered here that we should be looking for USC logs instead of unity8 ones.

[Pat McGowan (pat-mcgowan)]

lightdm / u-s-c logs

[kevin gunn (kgunn72)]

After re-reading this thread it sounds like
a) a bug specifically in the proximity sensor/blanking logic...like in some situation it's getting locked to blank
b) it sounds like as part of this, u-s-c (possibly unity8) is restarting as a result

[Jean-Baptiste Lallement (jibel)]

From the comment of Olivier on bug 1528384 could it be the due to the same crash?

[kevin gunn (kgunn72)]

Comment #7 & #13 in this bug claiming "no crash files" would seem to suggest they're different, but sometimes people miss them.
And I do agree the description from Olivier sure sounds the same as this.

[Alan Griffiths (alan-griffiths)]

Agreed, this is the behaviour I'd expect lp:1528384 to exhibit. Occum's razor suggests we don't needlessly look for another explanation.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[kevin gunn (kgunn72)]

We're needing more data on this bug, and we're going to eventually land the MP's to improve some reporting.

But this bug is critical, and we'd like to get information as soon as possible.
_Only_ if you are willing to risk not getting autoupdates (and have to flash your phone in future) - you can try the improved reporting for mir & unity-system-compositor by installing
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-014
you'd need to be on OTA9.5 or latest rc-proposed image.

If you install this ci-train silo and experience this bug, we are highly interested in the /var/log/lightdm/unity-system-compositor.log

I'll follow up once we land these reporting improvements in the image and the silo is no longer needed.

[Daniel van Vugt (vanvugt)]

The exceptions in comment #6 is bug 1506358, where the client dies unexpectedly but the server keeps running (and remember Unity8 is a client as well as a server).

If that's the only issue then this is a duplicate of that. But it may not be the only issue.

[kevin gunn (kgunn72)]

OK, we've made a point release of mir 0.19.1 and unity-system-compositor 0.4.1 which are now in the stable overlay.
Which means will be built into the next image and available on the rc-proposed channel.
Also, this should make it into the OTA9.5 release.
If you update and know you are on these point releases and are someone who is seeing this bug occur, please attach your /var/log/lightdm/unity-system-compositor.log

[Jelmer Prins (justcarakas)]

also happens sometimes when I'm in a call and briefly turn the screen on to check the time

[Wayne Ward (waynepaulward)]

i have exactly the same problem and sometimes during a call the phone will just reset back to the ubuntu loading screen and cut the call and has once had the phone call still running but usually just cuts the call
its been doing that for over a month id say maybe 2-3 months?

[Ivo Xavier (ivoxavier)]

Until the moment I did not have this bug, at least with phone calls, because I have those reboots when I receive SMS. In OTA-8.5, the phone was great, no reboots, everything worked as expected. My phone is the E4.5

[Pat McGowan (pat-mcgowan)]

I managed to reproduce it once on E4.5 running ota 9
I made 6 calls and on the 6th it failed as described, kept ringing and u-s-c crashed

[Pat McGowan (pat-mcgowan)]

To add to the steps, the screen was off, phone was face down to engage the proximity sensor.
When the call came in I touched the screen before lifting it, but not sure that was necessary as it hasn't reproduced again.
The device was plugged into usb the entire time o not suspended.

[Pat McGowan (pat-mcgowan)]

Reproduced on MX4 running rc-proposed r242
I am also touching the screen prior to picking it up and allowing the screen to come on, which may help trigger it.

[Pat McGowan (pat-mcgowan)]

On the E4.5 the phone came back on its own after about a min, on the MX4 it did not recover and I did a hard power cycle. There is also no crash file on the MX4.

Seems quite random when it will happen. I got it on the second call, then not again after 10 calls

[Nekhelesh Ramananthan (nik90)]

I also noticed a few things after the crash,

- the first being the proximity sensor which now behaves like the phone is in a call and blanks the screen when your hands reach the top of the phone during normal usage.

- Second being the call which is dropped is not recorded/listed in the dialer app. I suppose this could be because dialer-app only adds call to the history list after it is ended.

The crash triggers seems rather random. I have had it crash with just one app running and also with several apps running. Can't find a reliable way to reproduce it :/ Hopefully the unity-system-compositor.log provided by pat should help. I will upload mine as well in the next comment.

[Stefan Mikulaj (stefanmikulaj)]

Don't know if the bug I experienced is related directly to this bug, but I had a couple of situations that when I tried to call someone the phone just hangs, no dial tone, just hangs.
Other time I have closed the dialler and the call stayed active and I couldn't close the call when I have reached the recipient voice mail. When opening dialler again there was no option to end the ongoing call and call was still active in background . This is an annoying bug and should be fixed ASAP.
When we close the dialler then the call should be ended immediately, no exemption.

[Rakesh Manandhar (2005-rakesh)]

I'm using nexus 4. After installing OTA 9 my phone rebooted for installation but after successful installation. It just keeps on a a reboot loop shows ubuntu dotted booting logo then reboots again. So, I've to use volume up + power button to turn on and from the recovery menu i did 'wipe cache'. Only then my phone successfully booted. There are so many nice goodies in OTA 9 but some times while using phone it shows ubuntu booting logo out of no where. since the update it had happened 6 times. but for me it hasn't yet happened during the call.

[Daniel van Vugt (vanvugt)]

Going back to the reporter Uranicus' original description, he says he noticed the issue at "January, 10th at approx. 13:30 h".

And his unit8.log.3.gz contains:

[1452429068.248925] <ERROR> mircommon: Caught exception at Mir/EGL driver boundary (in queueBuffer): /build/mir-4B0JBP/mir-0.18.0+15.04.20151216.1/src/client/buffer_stream.cpp(169): Throw in function virtual MirWaitHandle* {anonymous}::ExchangeSemantics::submit(const std::function<void()>&, mir::geometry::Size, MirPixelFormat, int)
Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
std::exception::what: disconnected: no new buffers

whose time stamp translates to:

$ env TZ='Europe/Paris' date -d @1452429068
Sun Jan 10 13:31:08 CET 2016

Assuming Uranicus is in Western Europe, that must be the error. So this bug becomes a duplicate of bug 1506358, which has the added bonus of almost having a nice reproducible test case (needs work still).

[Daniel van Vugt (vanvugt)]

BTW, you won't get a crash report either. Because although it starts out as a serious-sounding C++ exception, libmirclient converts that into a SIGHUP for consumption by C clients. And SIGHUP's default action is to terminate without dumping core.

Normally SIGHUP is the right answer, because most such exceptions are just "the server disconnected us or died". So we do want the client to die (or catch the signal), and to not bother us with a core dump.

However bug 1506358 is a special unusual case where Mir has accidentally mapped a serious exception indicating a programming error into a non-serious SIGHUP. We need to learn to tell the difference between "normal" (server died and disconnected) and abnormal (server's still running but libmirclient is broken) exceptions...

[Daniel van Vugt (vanvugt)]

Oops, my memory failed me. We don't use SIGHUP there. Instead mir_buffer_stream_api.cpp simply catches, logs and then ignores all exceptions. That's probably worse.

[Alexandros Frantzis (afrantzis)]

The core problem here is that USC crashes with "Compositor thread failed to start" (see unity-system-compositor.log.old), not that libmirclient throws (because the server crashed, in this case). I think this bug should be kept separate from bug #1506358.

[Daniel van Vugt (vanvugt)]

unity-system-compositor.log is not from the original reporter of the bug. So likely a separate issue.

As always, we should ignore "me too"'s on the bug and focus on what the original reporter has provided. Any "me too" attachments are usually different bugs that will lead you down the wrong path.

[kevin gunn (kgunn72)]

deduplicating for the moment, discussing with alf not convinced we should dupe quite yet

[Wilson (wilson-ubuntu)]

I've got a similar issue and is definitely related to the proximity sensor: when the telephone app is down but there's a call active and I want to tap the green stripe to go back to the call the screen starts to blink and the phone ceased to respond until it perform a "fake reboot" (no pin needed). It happens almost every time I put the phone near my cheek ant next try to change the audio mode.

[Daniel van Vugt (vanvugt)]

I don't think treating this separately to bug 1506358 will be helpful.

Firstly, there is proof in comment #40 that the original reporter hit bug 1506358 at 13:31:08 on 10 January. Assuming Uranicus is 1 hour ahead of UTC...

Secondly, if you look in bug 1506358 you'll find I mentioned that when it occurs (client crashes) the server is unaffected and keeps running. In the case of this bug where unity8 is the client, unity-system-compositor is the server. So if unity-system-compositor has issues at all it's likely unrelated to bug 1506358. And the bug most provably related to this one is bug 1506358.

[Daniel van Vugt (vanvugt)]

Don't yet claim any fix committed. It was only mentioned in the 0.19.2 changelog and I suspect that's incorrect.

[Alberto Aguirre (albaguirre)]

@Daniel,

The OP also reports a "restart", whose description match what would happen if USC restarts... so we are going by our suspicion that it's related to the failure to start the compositor threads. The error logs in unity8 (USC's client) are irrelevant in that case.

[Pat McGowan (pat-mcgowan)]

I reproduced this again with an incoming text on mx4, and we checked the stack trace in http://pastebin.ubuntu.com/15009225/

Using silo 64 I am unable to trigger the symptom

[kevin gunn (kgunn72)]

just following up, very good anecdotal evidence testing from pat who consistently could repro this bug that the mir0.19.2 branch corrects this issue. Silo under test now. thanks for everyone's help.

[Daniel van Vugt (vanvugt)]

I'm happy to let this become another confused bug and it get closed. We have plenty of those and it's an unavoidable consequence of Launchpad's awesome openness. Managing popular bugs is often like herding cats.

There is however still absolute proof here that the original reporter hit bug 1506358 at 13:31 on 10 January, exactly when he described. Yes, there is a possibility the two bugs are related, however they will need to be kept separate now. Because bug 1506358 is known to occur on a simple Mir server that itself is not restarting or faulty.

So if anyone continues to see:
  std::exception::what: disconnected: no new buffers
please discuss that in bug 1506358 instead.

[Uranicus (matthias.ritter)]

Dear developers!

Thanks for the great work done to fix this issue!

Seeing that this bug (maybe also the reporting of it?) has caused some troubles I would appreciate a feedback what needs to be improved in the future bug reporting to get directly to the point where you can fix it. If there is something to be improved please let me (and others) know what we "users" can do different to ease your job.

Uranicus

[Daniel van Vugt (vanvugt)]

Uranicus:

You did a great job with your detailed bug report. There's nothing to improve. Thanks.