Active Topics
-
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (9)
to SailfishOS by biketool - 5 hrs, 56 mins ago -
[Announce] coderus unrestricted system-ui (297)
to MeeGo / Harmattan by nieldk - 6 days, 11 hrs ago - more...
| The Following 5 Users Say Thank You to pichlo For This Useful Post: | ||
|
2018-09-06
, 19:33
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#152
|
Version with chattier exit is available at https://drive.google.com/file/d/1QAU...ew?usp=sharing
Please start it with sailfish-qml from terminal.
I have not included the hammer yet. Would need to confirm that the issue is reproducible in terminal (sometimes terminal seems to be acting better).
@otsaloma, its also not clear where to invoke the hammer. At the end of quit? Then the stack was almost absent. Somewhere else? Or is it mainly to ensure that we do quit?
Edit Re picotts - keep it then with pico for now, we'll look into it a bit later. Probably you just need to replace a voice in mimic (for example female voice in mimic should use significantly less resources)
Please start it with sailfish-qml from terminal.
I have not included the hammer yet. Would need to confirm that the issue is reproducible in terminal (sometimes terminal seems to be acting better).
@otsaloma, its also not clear where to invoke the hammer. At the end of quit? Then the stack was almost absent. Somewhere else? Or is it mainly to ensure that we do quit?
Edit Re picotts - keep it then with pico for now, we'll look into it a bit later. Probably you just need to replace a voice in mimic (for example female voice in mimic should use significantly less resources)
| The Following 4 Users Say Thank You to rinigus For This Useful Post: | ||
 |
|
2018-09-06
, 20:54
|
|
Posts: 141 |
Thanked: 1,530 times |
Joined on May 2011
@ Finland
|
#153
|
Originally Posted by rinigus
Yes, I figured if all the function calls under Application.quit pass, but maybe a subprocess or thread is misbehaving, a "raise SystemExit(0)" at the end might force a quit – and if sailfish-qml/qmlscene/qml is waiting for Python, then the whole app process tree might quit, maybe.
@otsaloma, its also not clear where to invoke the hammer. At the end of quit?
For what it's worth, I did test http.pool.terminate with online providers in different connection states and it seemed to work fine, but it's possible I missed something or OSM Scout behaves differently. Also, if there's a problem in the http module, one solution would be to just swap it for requests (plus its dependencies). I was reluctant to bundle stuff, but I also think I underestimated the difficulty of writing a custom HTTP connection pool, there's been various corner case issues.
| The Following 7 Users Say Thank You to otsaloma For This Useful Post: | ||
|
|
2018-09-07
, 05:14
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#154
|
Originally Posted by otsaloma
When searching for solution, I looked into requests as well. But it had the same issue as HTTPConnection - its using blocking calls and would require the same threaded approach as used in http.py now. There was an issue filed in requests repo with the similar problem as we have (cannot find it now). One way would be to go for something async, but I think we will be able to stick to the threading approach and resolve it around it.
Yes, I figured if all the function calls under Application.quit pass, but maybe a subprocess or thread is misbehaving, a "raise SystemExit(0)" at the end might force a quit – and if sailfish-qml/qmlscene/qml is waiting for Python, then the whole app process tree might quit, maybe.
For what it's worth, I did test http.pool.terminate with online providers in different connection states and it seemed to work fine, but it's possible I missed something or OSM Scout behaves differently. Also, if there's a problem in the http module, one solution would be to just swap it for requests (plus its dependencies). I was reluctant to bundle stuff, but I also think I underestimated the difficulty of writing a custom HTTP connection pool, there's been various corner case issues.
Let's see what @pichlo's testing will bring. There is one candidate for blocking - closing connections that I considered idle. That should come out in testing messages. If it is, its simple to "fix" by making Pure Maps bad netizen and just forgetting the connections.
As for OSM Scout Server differences: it mainly allows you to suspend the server process while keeping network stack of the device intact. So, it allows to test for some weird conditions that is harder to do with the online services.
| The Following 5 Users Say Thank You to rinigus For This Useful Post: | ||
 |
|
2018-09-07
, 10:39
|
|
Posts: 6,450 |
Thanked: 20,982 times |
Joined on Sep 2012
@ UK
|
#155
|
I made the log this morning. I navigated from home to Place A, then changed the route to Place B. I was looking for parking around Place B, which Pure Maps interpreted as I overshot the destination and was trying to reroute me.
In the end, I closed the GUI but the CLI kept going, continually printing the same two lines over and over, until I closed that too. I can PM you the whole log (I do not want to share it here in full for privacy reasons as it contains my entire route), but the tail looks like this:
In the end, I closed the GUI but the CLI kept going, continually printing the same two lines over and over, until I closed that too. I can PM you the whole log (I do not want to share it here in full for privacy reasons as it contains my entire route), but the tail looks like this:
Code:
[W] unknown:0 - QMetaMethod::invoke: Unable to handle unregistered datatype 'QGeoPositionInfo' [D] unknown:0 - Geoclue client path: "/org/freedesktop/Geoclue/Master/client52" [W] unknown:0 - QMetaMethod::invoke: Unable to handle unregistered datatype 'QGeoPositionInfo' [D] unknown:0 - Geoclue client path: "/org/freedesktop/Geoclue/Master/client53" [W] unknown:0 - QMetaMethod::invoke: Unable to handle unregistered datatype 'QGeoPositionInfo' [D] unknown:0 - Geoclue client path: "/org/freedesktop/Geoclue/Master/client54" [W] unknown:0 - QMetaMethod::invoke: Unable to handle unregistered datatype 'QGeoPositionInfo' [D] unknown:0 - Geoclue client path: "/org/freedesktop/Geoclue/Master/client55" [W] unknown:0 - QMetaMethod::invoke: Unable to handle unregistered datatype 'QGeoPositionInfo' [D] unknown:0 - Geoclue client path: "/org/freedesktop/Geoclue/Master/client56" [W] unknown:0 - QMetaMethod::invoke: Unable to handle unregistered datatype 'QGeoPositionInfo' [D] unknown:0 - Geoclue client path: "/org/freedesktop/Geoclue/Master/client57" [W] unknown:0 - QMetaMethod::invoke: Unable to handle unregistered datatype 'QGeoPositionInfo'
__________________
Русский военный корабль, иди нахуй!
Русский военный корабль, иди нахуй!
| The Following 6 Users Say Thank You to pichlo For This Useful Post: | ||
|
|
2018-09-07
, 10:42
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#156
|
Please send by PM. These error messages seem to come from SFOS backend, as far as I can see. I presume that the interesting part is before the tail 
.
So, you could look up where this tail starts and send some lines before that. In particular, starting from line with "Quitting".
Edit: And thank you very much!
. So, you could look up where this tail starts and send some lines before that. In particular, starting from line with "Quitting".
Edit: And thank you very much!
| The Following 7 Users Say Thank You to rinigus For This Useful Post: | ||
|
|
2018-09-07
, 10:57
|
|
Posts: 6,450 |
Thanked: 20,982 times |
Joined on Sep 2012
@ UK
|
#157
|
No, I thank you!
PM sent. Sadly, the whole log did not fit due to the message length limit. I can email it to you if you PM me your address.
Sadly, there was no "Quitting" in the log
PM sent. Sadly, the whole log did not fit due to the message length limit. I can email it to you if you PM me your address.
Sadly, there was no "Quitting" in the log
__________________
Русский военный корабль, иди нахуй!
Русский военный корабль, иди нахуй!
| The Following 5 Users Say Thank You to pichlo For This Useful Post: | ||
|
|
2018-09-08
, 12:58
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#158
|
@pichlo has been doing lots of driving with the hope that we can fix the shutdown bug. So far, no luck. But there are things we learned about Pure Maps.
The debug version had each Python call wrapped, so we could see entry and exit of each call to ensure that all calls returned. There were messages added to several Component.onDestruction signal handlers to see whether destructors are called.
@pichlo got some runs that were fine, some hanged on exit. This did not depend on whether voice prompts were used - same behavior was observed in the presence and absence of voice. Outcome of the tests:
* In all runs, successful or hanging exit, python calls always returned.
* In unsuccessful runs, no destructors were called
While not, many destructors were marked by printouts and it looks like, for some reason, closing the app did not start destructors.
Has anyone observed something like it? I am going to summarize it at sailfish-devel list as well.
Would like to thank @pichlo for the work!
The debug version had each Python call wrapped, so we could see entry and exit of each call to ensure that all calls returned. There were messages added to several Component.onDestruction signal handlers to see whether destructors are called.
@pichlo got some runs that were fine, some hanged on exit. This did not depend on whether voice prompts were used - same behavior was observed in the presence and absence of voice. Outcome of the tests:
* In all runs, successful or hanging exit, python calls always returned.
* In unsuccessful runs, no destructors were called
While not, many destructors were marked by printouts and it looks like, for some reason, closing the app did not start destructors.
Has anyone observed something like it? I am going to summarize it at sailfish-devel list as well.
Would like to thank @pichlo for the work!
| The Following 10 Users Say Thank You to rinigus For This Useful Post: | ||
|
|
2018-09-08
, 14:40
|
|
Posts: 141 |
Thanked: 1,530 times |
Joined on May 2011
@ Finland
|
#159
|
Originally Posted by rinigus
Interesting. Sounds like the problem is on the QML side, I don't really know much about how it handles these things. It might help to check which top-level signals do get fired: there's onApplicationActiveChanged, which is apparently deprecated in favor of Qt.application.active; then there's at least onActiveChanged and Window.onClosing in QML Window, which Silica ApplicationWindow inherits.
While not, many destructors were marked by printouts and it looks like, for some reason, closing the app did not start destructors
| The Following 7 Users Say Thank You to otsaloma For This Useful Post: | ||
|
|
2018-09-08
, 16:22
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#160
|
Originally Posted by otsaloma
Strange, I cannot attach any of these:
Interesting. Sounds like the problem is on the QML side, I don't really know much about how it handles these things. It might help to check which top-level signals do get fired: there's onApplicationActiveChanged, which is apparently deprecated in favor of Qt.application.active; then there's at least onActiveChanged and Window.onClosing in QML Window, which Silica ApplicationWindow inherits.
Code:
onClosing: Window.onClosing: onActiveChanged
Any idea how to attach them? As for onApplicationActiveChanged, I am quite sure that one was
called before hanging on @pichlo - corresponding keep_alive update was in the logs.
| The Following 5 Users Say Thank You to rinigus For This Useful Post: | ||
Except one thing: there is a short (like half a second or less) fade-in on every spoken instruction, meaning you can miss the beginning if you don't expect it. Is it deliberate or just an artifact of how picotts works?
I will try the command line thing tomorrow morning, thanks rinigus.
Русский военный корабль, иди нахуй!