#257 Windows 7: SIPE crashes after a minute

[Stefan Becker]

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.

[Stefan Becker]

@reporters: please try the following thing: make sure you have the Pidgin debug symbol files installed and then copy

<your Pidgin install directory>\plugins\libsipe.dll

to

<your Pidgin install directory>\pidgin-2.10.9-dbgsym\plugins\libsipe.dll.dbgsym

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.

[Stefan Becker]

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.

[tony]

thanks, that NSIS fix worked for me too after the upgrade from an older version to 1.18.2 resulted in crashes.

[Stefan Becker]

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.

[Stefan Becker]

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.

[Stefan Becker]

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