<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>/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.</p>
<p>As an example, let's say process 1117 has hung:<br>
</p>
<p><tt>[root@Sailfish ~]# ls -la /proc/1117/exe </tt><tt><br>
</tt><tt>lrwxrwxrwx 1 root root 0 Sep 9 12:59 /proc/1117/exe
-> /usr/libexec/mapplauncherd/booster-qt5</tt><tt><br>
</tt><tt>[root@Sailfish ~]# gdb
/usr/libexec/mapplauncherd/booster-qt5</tt><tt><br>
</tt><tt>GNU gdb (GDB) Mer (7.6.2+git2)</tt><tt><br>
</tt><tt>Copyright (C) 2013 Free Software Foundation, Inc.</tt><tt><br>
</tt><tt>License GPLv3+: GNU GPL version 3 or later
<a class="moz-txt-link-rfc2396E" href="http://gnu.org/licenses/gpl.html"><http://gnu.org/licenses/gpl.html></a></tt><tt><br>
</tt><tt>This is free software: you are free to change and
redistribute it.</tt><tt><br>
</tt><tt>There is NO WARRANTY, to the extent permitted by law.
Type "show copying"</tt><tt><br>
</tt><tt>and "show warranty" for details.</tt><tt><br>
</tt><tt>This GDB was configured as "armv7hl-meego-linux-gnueabi".</tt><tt><br>
</tt><tt>For bug reporting instructions, please see:</tt><tt><br>
</tt><tt><a class="moz-txt-link-rfc2396E" href="http://www.gnu.org/software/gdb/bugs/"><http://www.gnu.org/software/gdb/bugs/></a>...</tt><tt><br>
</tt><tt>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.</tt><tt><br>
</tt><tt>done.</tt><tt><br>
</tt><tt>(gdb) attach 1117 </tt><tt><br>
</tt><tt>Attaching to program:
/usr/libexec/mapplauncherd/booster-qt5, process 1117</tt><tt><br>
</tt><tt>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.</tt><tt><br>
</tt><tt>done.</tt><tt><br>
</tt><tt>Loaded symbols for /usr/lib/libapplauncherd.so</tt><tt><br>
</tt><tt>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.</tt><tt><br>
</tt><tt>...</tt><tt><br>
</tt></p>
<p>and so on. The rest is a regular gdb debugging exercise.<br>
</p>
<p>Cheers,<br>
-Slava</p>
<br>
<div class="moz-cite-prefix">On 09/09/18 12:55, rinigus wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+4hNMFWb+Wd+fkHZ=ZL+utk5uLGDad4jyaeXbhsdKKENPUpTg@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">No, I didn't.
Its QML/Python app, so it is not clear what I should attach
the debugger to. sailfish-qml?</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">Rinigus</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Sun, Sep 9, 2018 at 12:35 PM Slava Monich
<<a href="mailto:slava.monich@jolla.com"
moz-do-not-send="true">slava.monich@jolla.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>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.<br>
</p>
Cheers,<br>
-Slava<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div style="font-size:small">We debugged a failure to
initiate destruction further. As suggested
by @wdehoog, I added </div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">
<pre class="m_1342272520744523798gmail-panel" dir="ltr" style="margin-top:0px;margin-bottom:0px;padding:6px;border:1px solid rgb(135,135,131);font-size:1.1em;width:500px;height:82px;overflow:auto"> Connections {
target: __quickWindow
onClosing: console.log("....")
}</pre>
</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">to ApplicationWindow.
This one does get called during app closure, without
further propagation over to destruction of items.</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">Any ideas on how to debug
it further?</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">Rinigus</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small"><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Sat, Sep 8, 2018 at 4:24 PM rinigus
<<a href="mailto:rinigus.git@gmail.com"
target="_blank" moz-do-not-send="true">rinigus.git@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div style="font-size:small">Hi,</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">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.</div>
<div style="font-size:small"><br>
</div>
<div style="font-size:small">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.</div>
<div style="font-size:small"><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>Hence the question, what could cause Silica
app to refuse starting destruction cascade? </div>
<div style="font-size:small"><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>For the record, haven't seen this on my
device (onyx). </div>
<div><br>
</div>
<div>Rinigus</div>
</div>
</blockquote>
</div>
<br>
<fieldset
class="m_1342272520744523798mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to <a class="m_1342272520744523798moz-txt-link-abbreviated" href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank" moz-do-not-send="true">devel-unsubscribe@lists.sailfishos.org</a></pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to <a class="moz-txt-link-abbreviated" href="mailto:devel-unsubscribe@lists.sailfishos.org">devel-unsubscribe@lists.sailfishos.org</a></pre>
</blockquote>
<br>
</body>
</html>