With Mir 0.26 test silo, when relaunching an application during/after invoking a trust session causes a crash

Bug #1659310 reported by Andrew Hayzen on 2017-01-25
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
New
Undecided
Unassigned
mir (Ubuntu)
Undecided
Unassigned
qtmir (Ubuntu)
High
Gerry Boland

Bug Description

What happened:
1) Installed Silo 2369 [0] on Xenial + Overlay using Unity8 Deb edition
2) Launched an application
3) Invoked a trust session within that application
4) Optional: Closed the trust session
5) Closed the application
6) Launched the same application from the dash
7) The whole of Unity8 froze (and I assume crashed)

What I expected to happen:
At step 7 for Unity8 not to freeze.

Two crash logs:
webbrowser - http://pastebin.ubuntu.com/23863224/
Kate - http://pastebin.ubuntu.com/23859188/

For the webbrowser crash I didn't close the trust session (step #4).

For Kate I *think* I did, but will confirm collecting some more crashes and noting what I have clicked.

0 - https://bileto.ubuntu.com/#/ticket/2369

The Webbrowser case from the log here: http://pastebin.ubuntu.com/23863224/ describes a segfault in qtmir - According to the log it tries to focus a nullptr surface. So I added qtmir to the report.

The Kate case is different - qtmir sends a mouse pointer leave event to a surface not known or no longer known to mirs InputSender. The Exception is propagated out to the caller and nowhere handled.

Those errors are very different..

Andrew Hayzen (ahayzen) wrote :

For the webbrowser case:
1) Launched Unity8 with the dash focused
2) Opened the web-browser
3) Open trust session
4) Left trust session open
5) Close browser
6) Do *not* focus dash (note if I did focus the dash first it didn't crash)
7) Open browser, by clicking on dash icon
8) Crashed as browser was launching

Crash Log: http://pastebin.ubuntu.com/23863731/

Andrew Hayzen (ahayzen) wrote :

What I've also noticed is if you close the application without a trust session, the focus is given back to the dash. Whereas if you have a trust session open the focus seems to be lost.

Andrew Hayzen (ahayzen) wrote :

This is the webbrowser case with MIR_SERVER_WINDOW_MANAGEMENT_TRACE: http://pastebin.ubuntu.com/23863966/

Alan Griffiths (alan-griffiths) wrote :

I don't think the focus gets lost: In that trace goes to a window called "Scopes".

 [2017-01-25 16:12:57.438287] miral::Window Management: invoke_under_lock
 [2017-01-25 16:12:57.438703] miral::Window Management: advise_focus_lost window_info={name=, type=normal, state=restored, restore_rect=((503, 70), (360, 560)), children={}, min_width=0, min_height=0, max_width=16777215, max_height=16777215, width_inc=1, height_inc=1, min_aspect={0, 4294967295}, max_aspect={4294967295, 0}, preferred_orientation=15, confine_pointer=0, output_id=0}
 [2017-01-25 16:12:57.438805] miral::Window Management: advise_focus_gained window_info={name=Scopes, type=normal, state=restored, restore_rect=((523, 75), (320, 544)), children={}, min_width=320, min_height=320, max_width=16777215, max_height=16777215, width_inc=1, height_inc=1, min_aspect={0, 4294967295}, max_aspect={4294967295, 0}, preferred_orientation=15, confine_pointer=0, output_id=0}
 [2017-01-25 16:12:57.438859] miral::Window Management: raise_tree root=Scopes
 [2017-01-25 16:12:57.438903] miral::Window Management: advise_raise window_info={Scopes}
 [2017-01-25 16:12:57.439270] miral::Window Management: select_active_window hint=Scopes -> Scopes
 [2017-01-25 16:12:57.439312] miral::Window Management: ====

But the next log messages seems to be from Mir starting up...

 [2017-01-25:16:13:24.633] qtmir.screens: ScreensModel::ScreensModel
 [2017-01-25 16:13:24.644863] mirplatform: Found graphics driver: mir:mesa-kms (version 0.26.0)
 [2017-01-25 16:13:24.644948] mirplatform: Found graphics driver: mir:mesa-x11 (version 0.26.0)

Andrew Hayzen (ahayzen) wrote :

For the Kate case:
1) Start unity8 with dash focussed
2) Start terminal
3) Launch kate
4) Two dialogs are shown in the process
- klauncher warning dialog (this dialog is dismissed by pressing OK)
- print dialog (when selecting Print this launches the trust session)
5) Invoke trust session
6) Close kate
7) Shell freezes as kate is closing

Note: The 'dialogs' don't actually appear as dialogs sometimes, they are embedded into the top of the window (which is what happened in this case). Furthermore the trust session appears as the size of the print dialog that was there before, so doesn't fill the whole window. I assume these issues are more todo with dialogs not being handled fully yet?

Crash Log: http://pastebin.ubuntu.com/23864082/

Changed in mir:
milestone: none → 0.26.0
Gerry Boland (gerboland) on 2017-01-31
Changed in qtmir:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Gerry Boland (gerboland)
Changed in mir:
milestone: 0.26.0 → 1.0.0
Gerry Boland (gerboland) on 2017-02-03
Changed in qtmir:
status: Triaged → In Progress
Michał Sawicz (saviq) on 2017-03-13
affects: qtmir → qtmir (Ubuntu)
Changed in mir:
milestone: 0.27.0 → 0.28.0
Michał Sawicz (saviq) wrote :

Syncing task from Mir.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers