/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@Sailfish ~]# ls -la /proc/1117/exe
lrwxrwxrwx 1 root root 0 Sep 9 12:59 /proc/1117/exe ->
/usr/libexec/mapplauncherd/booster-qt5
[root@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.mon...@jolla.com
<mailto:slava.mon...@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....@gmail.com
<mailto:rinigus....@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-unsubscr...@lists.sailfishos.org
<mailto:devel-unsubscr...@lists.sailfishos.org>
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
