Created from forum discussion: at least two Windows 7 users have reported the same crash during Calendar update initialization/EWS Autodiscover with SIPE 1.18.2:
(06:15:40) sipe: sipe_core_update_calendar: started. (06:15:40) sipe: sipe_ews_update_calendar: started. (06:15:40) sipe: sipe_ews_autodiscover_url: trying 'https://Autodiscover.mycompany.com/Autodiscover/Autodiscover.xml' (06:15:40) sipe: sipe_http_parse_uri: host 'Autodiscover.mycompany.com' port 443 path 'Autodiscover/Autodiscover.xml' (06:15:40) sipe: sipe_http_transport_new: new autodiscover.mycompany.com:443 (06:15:40) sipe: transport_connect - hostname: autodiscover.mycompany.com port: 443 (06:15:40) sipe: using SSL (06:15:40) dnsquery: Performing DNS lookup for autodiscover.mycompany.com ... (06:15:40) sipe: sipe_core_update_calendar: finished. (06:15:40) dnsquery: Error resolving autodiscover.mycompany.com: 11001 (06:15:40) proxy: Connection attempt failed: Error resolving autodiscover.mycompany.com: 11001 (06:15:40) sipe: sipe_http_transport_drop: dropping connection 'autodiscover.mycompany.com:443': SSL Connection Failed (06:15:40) sipe: sipe_http_transport_free: destroying connection 'autodiscover.mycompany.com:443' (06:15:40) sipe: sipe_ews_autodiscover_redirect: trying 'http://Autodiscover.mycompany.com/Autodiscover/Autodiscover.xml' (06:15:40) sipe: sipe_http_parse_uri: host 'Autodiscover.mycompany.com' port 80 path 'Autodiscover/Autodiscover.xml' (06:15:40) sipe: sipe_http_transport_new: new autodiscover.mycompany.com:80 (06:15:40) sipe: transport_connect - hostname: autodiscover.mycompany.com port: 80 (06:15:40) sipe: using TCP (06:15:40) dnsquery: Performing DNS lookup for autodiscover.mycompany.com (06:15:40) sipe: transport_deferred_destroy: 06D9CB08 (06:15:40) dnsquery: Error resolving autodiscover.mycompany.com: 11001 (06:15:40) proxy: Connection attempt failed: Error resolving autodiscover.mycompany.com: 11001 (06:15:40) sipe: sipe_http_transport_drop: dropping connection 'autodiscover.mycompany.com:80': Could not connect (06:15:40) sipe: sipe_http_transport_free: destroying connection 'autodiscover.mycompany.com:80' (06:15:40) sipe: sipe_ews_autodiscover_url: trying 'http://Autodiscover.mycompany.com/Autodiscover/Autodiscover.xml' (06:15:40) sipe: sipe_http_parse_uri: host 'Autodiscover.mycompany.com' port 80 path 'Autodiscover/Autodiscover.xml' (06:15:40) sipe: sipe_http_transport_new: re-establishing autodiscover.mycompany.com:80 (06:15:40) sipe: transport_connect - hostname: autodiscover.mycompany.com port: 80 (06:15:40) sipe: using TCP (06:15:40) dnsquery: Performing DNS lookup for autodiscover.mycompany.com (06:15:40) sipe: sipe_ews_autodiscover_url: trying 'https://mycompany.com/Autodiscover/Autodiscover.xml' (06:15:40) sipe: sipe_http_parse_uri: host 'mycompany.com' port 443 path 'Autodiscover/Autodiscover.xml' (06:15:40) sipe: sipe_http_transport_new: new mycompany.com:443 (06:15:40) sipe: transport_connect - hostname: mycompany.com port: 443 (06:15:40) sipe: using SSL (06:15:40) dnsquery: Performing DNS lookup for mycompany.com (06:15:40) sipe: transport_deferred_destroy: 06D9CB58 (06:15:40) dnsquery: Error resolving autodiscover.mycompany.com: 11001 (06:15:40) proxy: Connection attempt failed: Error resolving autodiscover.mycompany.com: 11001
Unfortunately no debugger stack backtrace is available, just a RPT
printout (Pidgin crash report?) which doesn't provide enough information:
Error occured on Tuesday, June 10, 2014 at 12:49:11. Windows Version 6.1 Build 7601 Service Pack 1 C:\Program Files (x86)\Pidgin\pidgin.exe caused an Access Violation at location 5882871f in module C:\Program Files (x86)\Pidgin\plugins\libsipe.dll Reading from location 6f72735d. Registers: eax=5886d535 ebx=06316290 ecx=7efdd000 edx=6f727245 esi=58828700 edi=686591d8 eip=5882871f esp=0028ecd0 ebp=0028edd8 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210206 Call stack: C:\Program Files (x86)\Pidgin\plugins\libsipe.dll [1.18.2.0] 5882871F C:\Program Files (x86)\Pidgin\plugins\libsipe.dll C:\Program Files (x86)\Pidgin\Gtk\bin\libglib-2.0-0.dll [2.28.8.0] 685EB167 C:\Program Files (x86)\Pidgin\Gtk\bin\libglib-2.0-0.dll g_main_context_dispatch 685EB90D C:\Program Files (x86)\Pidgin\Gtk\bin\libglib-2.0-0.dll g_main_context_dispatch 685EBD9D C:\Program Files (x86)\Pidgin\Gtk\bin\libglib-2.0-0.dll g_main_loop_run C:\Program Files (x86)\Pidgin\Gtk\bin\libgtk-win32-2.0-0.dll [2.16.6.0] 025C4260 C:\Program Files (x86)\Pidgin\Gtk\bin\libgtk-win32-2.0-0.dll gtk_main
I'm not sure how to create a dbgsym
file for libsipe.dll.
This needs more input from a Windows user who can run Pidgin under a debugger to see the real call stack at the point of crash.
Forums: Pidgin crashes with an Access Violation after a few minutes of operation after logging in
Forums: Pidgin crashes with an Access Violation after a few minutes of operation after logging in
Release Notes: 2014/08/pidgin-sipe-release-1183
@reporters: please try the following thing: make sure you have the Pidgin debug symbol files installed and then copy
to
The libsipe.dll from the SIPE release is not stripped and therefore copying the file into the Pidgin debug symbol directory will make sure that more detailed information will be available from the RPT printout.
I will improve the SIPE Windows release package to do this automatically in the future.
While trying to simulate the same error situation I noticed a slight difference in the debug logs. I can only explain this difference with an obscure race condition that only exists on Windows 7.
I have implemented a work around in git commit 3893f95
I've created a NSIS package for that git commit to make it easier for you to test the fix.
Your feedback is appreciated.
thanks, that NSIS fix worked for me too after the upgrade from an older version to 1.18.2 resulted in crashes.
The race condition can only occur with GLIB 2.28.x or earlier versions. Windows Pidgin uses GLIB 2.28.0 which explains why this problem is only visible there.
Now that the root cause is understood I was able to reproduce the crash and verify that git HEAD fixes the problem.
CLOSING as fixed.
This was a regression introduced in 1.18.1. It was triggered by the changes in git commit 04e87de on all systems that use glib2 2.28.x or older, when the first 3 EWS types failed to create a connection.
See also glib2 bug #650459 which was fixed by this git commit
Last edit: Stefan Becker 2014-06-29