Hi, We also observed this problem in Wengo, and the difficulty of debugging what happens after a suspend got in the way of solving the problem. gdb does not give particularly useful information.
The only way I can think of to debug these kinds of threading issues is an old method I cann "pepper printfs everywhere". You need to identify key entry points, have printfs for when you enter & leave, from which thread, and see where your assumptions are wrong. I am interested in what makes you think that the majority of users are laptop users. Cheers, Dave. Roland Alton-Scheidl wrote: > We have done some long-term observations both with kvats and qutecom. > > In most cases, freeze happens after a longer suspend period. This annoys all > people, who run kvats or qutecom on a laptop, and this will be the majority > of > users. > > After some discussions with Laurent in Krems, it seems like a deadlock > between > boost and Qt. > > How can we debug this? Neither gdb does not throw any useful information nor > do we have an indicator in the log files with OWLOGGER_DEFAULT set to 0. Can > we turn on debugging for the semaphores? > > Our observation is, that a network change does most time not result in a > freeze, however, SIP does not re-connect properly in most cases. > > --RAS > -- maemo.org docsmaster Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] _______________________________________________ QuteCom-dev mailing list [email protected] http://lists.qutecom.org/mailman/listinfo/qutecom-dev
