[SailfishDevel] app hangs on shutdown

[Slava Monich]

/proc/$PID/exe is a link to the executable. You can load that executable 
into gdb and attach to the hung process. Then you will probably discover 
that important debug symbols are missing but it's a different matter.

As an example, let's say process 1117 has hung:

[root at Sailfish ~]# ls -la /proc/1117/exe
lrwxrwxrwx 1 root root 0 Sep  9 12:59 /proc/1117/exe -> 
/usr/libexec/mapplauncherd/booster-qt5
[root at Sailfish ~]# gdb /usr/libexec/mapplauncherd/booster-qt5
GNU gdb (GDB) Mer (7.6.2+git2)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv7hl-meego-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/libexec/mapplauncherd/booster-qt5...Reading 
symbols from 
/home/debug/lib/debug/usr/libexec/mapplauncherd/booster-qt5-1.1.14-1.2.48.jolla.arm.debug...done.
done.
(gdb) attach 1117
Attaching to program: /usr/libexec/mapplauncherd/booster-qt5, process 1117
Reading symbols from /usr/lib/libapplauncherd.so...Reading symbols from 
/home/debug/lib/debug/usr/lib/libapplauncherd.so-4.1.29-1.9.14.jolla.arm.debug...done.
done.
Loaded symbols for /usr/lib/libapplauncherd.so
Reading symbols from /lib/libresolv.so.2...Reading symbols from 
/home/debug/lib/debug/lib/libresolv-2.19.so-2.19+6.13.1-1.4.16.jolla.arm.debug...done.
...

and so on. The rest is a regular gdb debugging exercise.

Cheers,
-Slava


On 09/09/18 12:55, rinigus wrote:
> No, I didn't. Its QML/Python app, so it is not clear what I should 
> attach the debugger to. sailfish-qml?
>
> Rinigus
>
> On Sun, Sep 9, 2018 at 12:35 PM Slava Monich <slava.monich at jolla.com 
> <mailto:slava.monich at jolla.com>> wrote:
>
>     Have you tried debugging with a debugger (run the app under gdb
>     and examine the backtrace when it gets stuck)? That seems to be
>     the obvious first step to me.
>
>     Cheers,
>     -Slava
>
>>     We debugged a failure to initiate destruction further. As
>>     suggested by @wdehoog, I added
>>
>>         Connections {
>>              target: __quickWindow
>>              onClosing: console.log("....")
>>          }
>>
>>     to ApplicationWindow. This one does get called during app
>>     closure, without further propagation over to destruction of items.
>>
>>     Any ideas on how to debug it further?
>>
>>     Rinigus
>>
>>
>>
>>     On Sat, Sep 8, 2018 at 4:24 PM rinigus <rinigus.git at gmail.com
>>     <mailto:rinigus.git at gmail.com>> wrote:
>>
>>         Hi,
>>
>>         I am working on Pure Maps - a fork of @otsaloma's map
>>         applications. As a background: Its a Python app, with
>>         pyotherside used for QML/Python interaction. Its also using
>>         Mapbox GL widget that I wrote on the basis of Mapbox GL
>>         QtLocation plugin.
>>
>>         I am facing a problem which I don't know how to solve, hence
>>         asking for help. Namely, Pure Maps sometimes does not
>>         shutdown cleanly after closure by the user. Namely, when app
>>         is closed in GUI (I presume close guesture or touching X in
>>         SFOS overview mode), the process stays. Same if the app is
>>         started from terminal - if the shutdown was unsuccessful,
>>         terminal prompt does not return after closing the program.
>>
>>         And here were the mystery starts. With the suspicion that
>>         maybe some python call is hanging, the printouts were added
>>         before and after Python calls (through QML Python wrapper).
>>         Regardless to whether the app was shutdown cleanly or was
>>         left hanging, the calls (sync or async) always returned.
>>
>>         I have added printout statements in Component.onDestruction
>>         for key QML items in the app and could see that, when the app
>>         hangs, none of the onDestruction handlers were called.
>>
>>         Hence the question, what could cause Silica app to refuse
>>         starting destruction cascade?
>>
>>         This issue is mainly reported by J1 users and I had a great
>>         help from @pichlo with debugging it. Sometimes, we observed
>>         OOM killing of other app during the navigation. So, I
>>         presume, the device is under significant RAM pressure. But
>>         still, I am rather blank on where to debug it further and
>>         what could cause such behavior.
>>
>>         For the record, haven't seen this on my device (onyx).
>>
>>         Rinigus
>>
>>
>>
>>     _______________________________________________
>>     SailfishOS.org Devel mailing list
>>     To unsubscribe, please send a mail todevel-unsubscribe at lists.sailfishos.org
>>     <mailto:devel-unsubscribe at lists.sailfishos.org>
>
>
>
> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe at lists.sailfishos.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20180909/c6fe0b04/attachment.html>