Re: [SailfishDevel] Getting log from a thread
Am Freitag, 31. Juli 2020, 10:04:57 CEST schrieb David Llewellyn-Jones: > One final point: I think these mailing lists are supposed to be on ice > now, so people may not be following them so much. You might get a better > response at forum.sailfishos.org. Just to a some tip to this topic discourse (much like mailman3) can be use via email just like a regular mailing list: https://discourse.mozilla.org/t/how-do-i-use-discourse-via-email/15279[1] Mailman3 also would be pretty close to a forum, an upgrade to this would also help. Br, Björn [1] https://discourse.mozilla.org/t/how-do-i-use-discourse-via-email/15279 signature.asc Description: This is a digitally signed message part. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Getting log from a thread
szo...@gmail.com wrote: > Yeah I'm pretty sure it's the moving stage, hardly anyone reads any > development topics and it will take a while for people to move from this > list probably some won't ever as they will not notice :( as even my very > basic question didn't get any reply in 2 days, maybe jolla can rethink > canning this list as it was a good source of answers in <48h if ever, > there's definitely some talent subbed here that will most likely never > migrate It is classic! It is precious like an old timer - it runs and runs good. It is very simple to use ... almost no gui - pure info. I miss the days when you could find what you were looking for by just using lynx and you did not need google for that. Today everybody takes care about the look and feel but not about the real thing. Obviously I prefer this form of communication :) regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Getting log from a thread
Yeah I'm pretty sure it's the moving stage, hardly anyone reads any development topics and it will take a while for people to move from this list probably some won't ever as they will not notice :( as even my very basic question didn't get any reply in 2 days, maybe jolla can rethink canning this list as it was a good source of answers in <48h if ever, there's definitely some talent subbed here that will most likely never migrate On Friday, 31 July 2020, deloptes wrote: > David Llewellyn-Jones wrote: > > > I'm not fully clear on whether you're after debugging (e.g. using gdb) > > or logging output. > > > > I need log output. Debugger might be a next stage, though in that case > wireshark and log output could help most. The problem is I want to find out > why it is stuck, but it ain't logging anything. > > > For debugging, you should be able to connect gdb to the running process > > (as long as you know the pid) and can then access individual threads > > from there. Something like this: > > > > # ps ax -o "pid command" | grep msyncd > > 4500 /usr/bin/invoker -G -o -s --type=qt5 /usr/bin/msyncd > > 4504 /usr/bin/msyncd > > 13063 grep msyncd > > > > # gdb -p 4504 > > > > (gdb) info threads > > Id Target Id Frame > > * 1LWP 4504 "msyncd" 0xe9bd2da4 > > 2LWP 4513 "QDBusConnection" 0xe9bd2da4 > > 3LWP 4527 "gmain" 0xe9bd2da4 > > 4LWP 4528 "dconf worker"0xe9bd2da4 > > 5LWP 4529 "Qt bearer threa" 0xe9bd2da4 > > 6LWP 4531 "gdbus" 0xe9bd2da4 > > (gdb) > > > > If it's the logging you're after, then the cheatsheet implies increasing > > logging for msyncd should also increase it for the plugins, so it might > > be worth trying something like this: > > > > devel-su -p > > systemctl --user stop msyncd > > MSYNCD_LOGGING_LEVEL=8 msyncd > > > > I didn't test this with OBEX though I'm afraid. > > > > The thing is the OOP is started in a thread which runs the process, so until > I identify the process, it is already stuck > > I start msyncd with EnvironmentFile=/etc/sysconfig/msyncd in the service > # cat /etc/sysconfig/msyncd > QTCONTACTS_SQLITE_TWCSA_TRACE=1 > QTCONTACTS_SQLITE_TRACE=1 > MSYNCD_LOGGING_LEVEL=128 > > This gives very detailed log, but for the OBEX OOP I see only "Starting > thread ..." > > > One final point: I think these mailing lists are supposed to be on ice > > now, so people may not be following them so much. You might get a better > > response at forum.sailfishos.org. > > > > David > > Really ? I was thinking forum.sailfishos.org is too new, cause no one > answered my question on another topic there. May be most of the people are > simply on vacation. > > If you have an idea specifically about the thread, I'ld appreciate it. > Thanks anyway > > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.or -- Sent from my Jolla ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Getting log from a thread
David Llewellyn-Jones wrote: > I'm not fully clear on whether you're after debugging (e.g. using gdb) > or logging output. > I need log output. Debugger might be a next stage, though in that case wireshark and log output could help most. The problem is I want to find out why it is stuck, but it ain't logging anything. > For debugging, you should be able to connect gdb to the running process > (as long as you know the pid) and can then access individual threads > from there. Something like this: > > # ps ax -o "pid command" | grep msyncd > 4500 /usr/bin/invoker -G -o -s --type=qt5 /usr/bin/msyncd > 4504 /usr/bin/msyncd > 13063 grep msyncd > > # gdb -p 4504 > > (gdb) info threads > Id Target Id Frame > * 1 LWP 4504 "msyncd" 0xe9bd2da4 > 2 LWP 4513 "QDBusConnection" 0xe9bd2da4 > 3 LWP 4527 "gmain" 0xe9bd2da4 > 4 LWP 4528 "dconf worker" 0xe9bd2da4 > 5 LWP 4529 "Qt bearer threa" 0xe9bd2da4 > 6 LWP 4531 "gdbus" 0xe9bd2da4 > (gdb) > > If it's the logging you're after, then the cheatsheet implies increasing > logging for msyncd should also increase it for the plugins, so it might > be worth trying something like this: > > devel-su -p > systemctl --user stop msyncd > MSYNCD_LOGGING_LEVEL=8 msyncd > > I didn't test this with OBEX though I'm afraid. > The thing is the OOP is started in a thread which runs the process, so until I identify the process, it is already stuck I start msyncd with EnvironmentFile=/etc/sysconfig/msyncd in the service # cat /etc/sysconfig/msyncd QTCONTACTS_SQLITE_TWCSA_TRACE=1 QTCONTACTS_SQLITE_TRACE=1 MSYNCD_LOGGING_LEVEL=128 This gives very detailed log, but for the OBEX OOP I see only "Starting thread ..." > One final point: I think these mailing lists are supposed to be on ice > now, so people may not be following them so much. You might get a better > response at forum.sailfishos.org. > > David Really ? I was thinking forum.sailfishos.org is too new, cause no one answered my question on another topic there. May be most of the people are simply on vacation. If you have an idea specifically about the thread, I'ld appreciate it. Thanks anyway ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Getting log from a thread
On 31/07/2020 09:11, deloptes wrote: [snip] > I see in buteo-syncml that the mentioned OBEX_HandleInput() is called in a > loop while waiting for input. > My problem is and hence my request here, that there is no debugging log from > the obex transport, because it gets started in a thread by msyncd. > > How do I enable debugging for the process started in the thread? I'm not fully clear on whether you're after debugging (e.g. using gdb) or logging output. For debugging, you should be able to connect gdb to the running process (as long as you know the pid) and can then access individual threads from there. Something like this: # ps ax -o "pid command" | grep msyncd 4500 /usr/bin/invoker -G -o -s --type=qt5 /usr/bin/msyncd 4504 /usr/bin/msyncd 13063 grep msyncd # gdb -p 4504 (gdb) info threads Id Target Id Frame * 1LWP 4504 "msyncd" 0xe9bd2da4 2LWP 4513 "QDBusConnection" 0xe9bd2da4 3LWP 4527 "gmain" 0xe9bd2da4 4LWP 4528 "dconf worker"0xe9bd2da4 5LWP 4529 "Qt bearer threa" 0xe9bd2da4 6LWP 4531 "gdbus" 0xe9bd2da4 (gdb) If it's the logging you're after, then the cheatsheet implies increasing logging for msyncd should also increase it for the plugins, so it might be worth trying something like this: devel-su -p systemctl --user stop msyncd MSYNCD_LOGGING_LEVEL=8 msyncd I didn't test this with OBEX though I'm afraid. One final point: I think these mailing lists are supposed to be on ice now, so people may not be following them so much. You might get a better response at forum.sailfishos.org. David -- Website: https://www.flypig.co.uk ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] Sailfish SDK 3.2 has been released to Early Access
Hello, Yesterday (July 30th) at 08:00 UTC the Sailfish SDK 3.2 was released to Early Access users. Please, check out the release notes from https://forum.sailfishos.org/t/release-notes-sailfish-sdk-3-2-early-access/1241[1] . Attention: This is the last announcement posted in this mailing list. Following the effort to unite the various information sources we have, further announcements will be only done via the new forum at https://forum.sailfishos.org[2] . The installers for this SDK release are now available at https://sailfishos.org/wiki/Application_SDK_Early_Access#Latest_Early_Access_SDK_Release[3] . If you have an older Early Access release of the SDK installed, you should see an update notification in the Sailfish IDE. If you have any questions, feel free to either write it up in https://forum.sailfishos.org/[4] or send an e-mail to developer-care at jolla.com. Happy hacking, Jolla SDK Team [1] https://forum.sailfishos.org/t/release-notes-sailfish-sdk-3-2-early-access/1241 [2] https://forum.sailfishos.org [3] https://sailfishos.org/wiki/Application_SDK_Early_Access#Latest_Early_Access_SDK_Release [4] https://forum.sailfishos.org/ ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] Getting log from a thread
Hi, I am trying to find out why buteo-syncml does not work with openobex-1.7. This has been bugging me for the past few years. According to the developer there are few changes needed to upgrade applications from openobex-1.5 to 1.6 to 1.7. Upgrading to version 1.7 When using an event loop that triggers on incoming data, you must call OBEX_HandleInput() after each call to OBEX_Request() to actually send the request. I see in buteo-syncml that the mentioned OBEX_HandleInput() is called in a loop while waiting for input. My problem is and hence my request here, that there is no debugging log from the obex transport, because it gets started in a thread by msyncd. How do I enable debugging for the process started in the thread? Thank you in advance regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
