**** BEGIN LOGGING AT Tue Jun 30 02:59:58 2015 Jun 30 09:12:40 Tofe: recent crashes are caused by https://github.com/webOS-ports/qtwayland/commit/fc968d9ff868279350059bd37c7cbec8116a0156 , maybe you have ideas how to fix this? Jun 30 09:55:38 nizovn/Tofe: Jun 30 09:56:16 THere might be some patches upstream that might fix this? https://github.com/qtproject/qtwayland/commit/d6a9b108f4bc2cf3d6a68a16128796d75f767829 or https://github.com/qtproject/qtwayland/commit/6ac99af0fa3cdf334b59dd3f85803872e7a4194f or https://github.com/qtproject/qtwayland/commit/7d59e55421321839605e1c08f23aeba4da1d8cd8 or https://github.com/qtproject/qtwayland/commit/21a79834a926a420c824cea4c478a33758ebbbf8 Jun 30 11:32:30 Herrie|Laptop: your second pointer is very interesting Jun 30 11:33:32 ah no wait, it's the code of an example compositor Jun 30 11:34:56 nizovn: first we can try reverting that one; a leak is less critical than a crash Jun 30 11:40:43 ok, looks like it avoids the crash (but not for the browser crash scenario) Jun 30 13:17:46 ok, I think I nearly found why the delete m_view creates a crash: in our crash scenario, the view is already destroyed when the shell_surface is destroyed. Jun 30 13:24:34 the scenario *seems* to be: closeWindowWithId() --> destroySurface() --> surfaceAboutToBeDestroyed() --> CompositorWindow::tryRemove() (here the view is deleted) , then the surface is actually destroyed --> ~QWaylandSurface --> delete shell_surface --> delete m_view --> crash. Jun 30 13:25:42 however, commenting out the tryRemove call doesn't avoid the crash, so I must have missed another step. Jun 30 13:25:58 _Fissurez_: please could you fix your IRC connection? Jun 30 14:15:32 Tofe: is it expected that after window is destroyed, luna-next creates surface with window (for appId "") and immediately destroys them? Jun 30 17:56:14 nizovn: I investigated that too, because it was strange; but actually it is a fallback of Qt when the main window view is destroyed before OpenGL resources have been released. It is actually a QOffscreenSurface, created at https://github.com/qtproject/qtdeclarative/blob/dev/src/quick/scenegraph/qsgthreadedrenderloop.cpp#L1093 Jun 30 17:56:50 I found out that it is triggered because we ask twice to destroy the same window id. Jun 30 17:58:32 https://github.com/webOS-ports/luna-next-cardshell/pull/226 <-- this should avoid it Jun 30 18:00:51 What I didn't have time to try yet is to modify the shell surface destruction to make it check if the view is still in the list of views of the surface Jun 30 18:18:31 with this new implementation http://paste.ubuntu.com/11800529/ the crashes of Herrie don't seem to happen anymore. But the multi-window browser still crashes luna-next. Jun 30 18:19:00 ( from qtwayland, in src/compositor/wayland_wrapper/qwlshellsurface.cpp ) Jun 30 18:25:15 can confirm this fixes crashes Jun 30 18:29:33 Tofe: PR#226 should avoid creation of fallback surface? for me it's still here after PR. Jun 30 19:15:49 nizovn: mmh. Well, anyway, the PR#226 can't do any harm Jun 30 19:16:07 ok Jun 30 19:16:13 the fallback surface isn't a bug in itself, it's just an async case among others Jun 30 19:16:18 just not very pretty **** ENDING LOGGING AT Wed Jul 01 02:59:58 2015