Open jcatta opened 7 years ago
xhaakon
commented
7 years ago Do you have a complete log from this session?
Please note that for the log to be useful, you have to run Pidgin like this:
PURPLE_UNSAFE_DEBUG=1 pidgin --debug
You can send the log (compressed pls.) to the mail address in my profile rather than posting it here publicly.
tmuehlhoff
commented
7 years ago I'll have a crash logged here as well, I sent the chopped log to xhaakon via E-Mail. I'm not sure they are the same crash. /t.
xhaakon
commented
7 years ago @tmuehlhoff Your crash likely too concerns populating the contact list because if happened very shortly after connecting to the Lync server. The messages, however, don't match @jcatta's original report - no assert errors in purple_status_get_id() etc. Actually, I don't see indication of any problem in the file at all. If Pidgin crashed right after (11:35:21) sipe: transport_deferred_destroy: 0x1f3b100, the cause wasn't logged.
(11:35:21) sipe: Read error: No such file or directory (2)
(11:35:21) sipe: sipe_http_transport_drop: dropping connection 'www.external-user-photo-catalog.com:443': Read error
(11:35:21) sipe: sipe_http_transport_free: destroying connection 'www.external-user-photo-catalog.com:443'
(11:35:21) sipe: sipe_schedule_remove: action name=<+http-timeout>
(11:35:21) sipe: sipe_schedule_allocate timeouts count 10 after addition
(11:35:21) sipe: scheduling action <+http-timeout> timeout 16 seconds
(11:35:21) sslconn: Connection closed.
(11:35:21) sipe: transport_deferred_destroy: 0x1f3b100Those final messages in the output had me wondering if there was some problem with downloading user images from external URLs (i.e. from a different source than Active Directory). I tried using some of the logged photo URLs in my Sipe and got the same Read error: No such file or directory (2), apparently because some of the photos have been removed from the server, but I wasn't able to make Pidgin crash this way. Thus, there must be some different cause.
If you're able to reproduce the crash, could you please use gdb to capture the stack trace as described in our wiki? The original bug report above has a good stack trace, but no corresponding log. Having both from a single user could help us pinpoint what's happening.
tmuehlhoff
commented
7 years ago @xhaakon,
in fact I did only walk through the log in order to shorten it by time code, so it could indeed be another crash. In fact I think it crashed around 10:34 (I removed the stuff before in hour 9:xx). I restarted it on the same log file (append) so the snippet you quote probably was not a crash rather me Ctrl-C'ing the stuff in order to collect the log.
Since it has happened earlier, I will eventually be able to reproduce with gdb. /t.
Submitter ################################################################## thomas.lindberg@ericsson.com ################################################################## Software versions ################################################################## Package: pidgin-sipe
Version: 1.21.1+sipe-0+201612161030~ubuntu14.04.1
Package: pidgin
Version: 1:3.0.0~collab-1+201612222033~ubuntu14.04.1 ################################################################## Symptom ################################################################## Pidgin craches during connection phase. It handles alot of process_incoming_notify_rlmi and craches due to a NULL reference ##################################################################
################################################################## STACK TRACE ##################################################################