segfault in pthread_mutex_lock using python bindings

[GoogleCodeExporter]

gwibber-service crashes reliably when downloading avatars for facebook 
accounts.  The crash happens in px_proxy_factory_get_proxies, regardless if you 
have a proxy configured or not.  

What steps will reproduce the problem?
1. bzr branch lp:gwibber
2. cd gwibber
3. ./bin/gwibber-service -d -o
4. run ./bin/gwibber-accounts and add a facebook account
5. let it do a few refreshes until it segfaults

Downstream bug report can be found at 
https://bugs.launchpad.net/ubuntu/+source/libproxy/+bug/651761

#0  pthread_mutex_lock() at :0
#1  px_proxy_factory_get_proxies(self = 0xd801a2b0, url = 0x1183c8c 
\"https://fbcdn-profile-a.akamaihd.net/hprofile-ak-snc4/hs478.snc4/50101_2738056
_7419_q.jpg\") at proxy.c:237
#2  ffi_call_unix64() at :0
#3  ffi_call() at :0
#4  _call_function_pointer() at 
/build/buildd/python2.6-2.6.6/Modules/_ctypes/callproc.c:816
#5  _CallProc(pProc = <value optimized out>, argtuple = <value optimized out>, 
flags = <value optimized out>, argtypes = <value optimized out>, restype = 
<value optimized out>, checker = <value optimized out>) at 
/build/buildd/python2.6-2.6.6/Modules/_ctypes/callproc.c:1163
#6  CFuncPtr_call(self = 0xb7f2c0, inargs = 0x124add0, kwds = <value optimized 
out>) at /build/buildd/python2.6-2.6.6/Modules/_ctypes/_ctypes.c:3860
#7  PyObject_Call() at :0
#8  PyEval_EvalFrameEx() at :0
#9  PyEval_EvalFrameEx() at :0
#10  PyEval_EvalCodeEx() at :0
#11  ??() at :0
#12  PyObject_Call() at :0
#13  ??() at :0
#14  PyObject_Call() at :0
#15  PyEval_CallObjectWithKeywords() at :0
#16  PyInstance_New() at :0
#17  PyObject_Call() at :0
#18  PyEval_EvalFrameEx() at :0
#19  PyEval_EvalFrameEx() at :0
#20  PyEval_EvalCodeEx() at :0
#21  ??() at :0
#22  PyObject_Call() at :0
#23  ??() at :0
#24  PyObject_Call() at :0
#25  PyEval_CallObjectWithKeywords() at :0

What version of the product are you using? On what operating system?
0.3.1-1ubuntu1, Ubuntu 10.10.  I have reproduced the same crash in 0.4.6, but 
we really need a fix for 0.3.1 for Ubuntu.

Please provide any additional information below.

API calls to facebook and everything for the other services gwibber supports 
seem to be unaffected.  But avatar downloads from facebook seems to trigger it 
pretty often.  The weird thing about the avatar downloads from facebook is on 
facebook's side, I think there is a certificate problem and if i try to 
download some of them with curl I randomly get TLS errors.

Not sure if that is related or not, but something I observed.  Regardless of 
the brokeness of facebook, libproxy shouldn't segfault.

Original issue reported on code.google.com by OXtVXL3...@gmail.com on 11 Oct 2010 at 3:01

[GoogleCodeExporter]

If I attempt to download the same image with wget, I get this error:

ERROR: certificate common name `a248.e.akamai.net' doesn't match requested host 
name `fbcdn-profile-a.akamaihd.net

Original comment by OXtVXL3...@gmail.com on 11 Oct 2010 at 3:09

[GoogleCodeExporter]

The common name mismatch isn't related, it is the mutex.

Gwibber gets a list of new_messages, and iterates over them and if 
notifications are enabled it do a gobject.idle_add to handle the notification.  
Part of the function called handles the avatar caching.  I think it is firing 
these off very close together and libproxy isn't handling that well.  If I add 
a time.sleep(3) before the idle_add, it doesn't crash.  

Original comment by OXtVXL3...@gmail.com on 11 Oct 2010 at 4:08

[GoogleCodeExporter]

Could you run it into valgrind and attach the report ? This looks like memory 
corruption somewhere.

Thanks,
Nicolas

Original comment by nicolas.dufresne@gmail.com on 12 Oct 2010 at 12:13

[GoogleCodeExporter]

I can't reproduce this in valgrind, seems to slow it down enough that it never 
gets triggered.,

Original comment by OXtVXL3...@gmail.com on 13 Oct 2010 at 4:10

[GoogleCodeExporter]

A couple more observations, I haven't reproduced this on i386, it seems to only 
happen on 64 bit.  Also, setting pf = None after each getProxies call helped.

I moved the instantiation of the ProxyFactory object to try to isolate it and 
let the object be long lasting, which helped even more than setting it to None 
each time.  But the crash still happens pretty often.  

I am experimenting with using gtk.gdk.threads_init instead of 
gobject.threads_init then using "with gdk_lock" everywhere we call getProxies, 
and so far this seems to be the best work around I have found.  It has actually 
lasted a couple hours now without a crash.  But it adds a pygtk depends to the 
gwibber-service which we really don't want.

Original comment by OXtVXL3...@gmail.com on 21 Oct 2010 at 4:54

[GoogleCodeExporter]

This is definatly a bug when run with multi-cpu, thus locking issue.

Original comment by nicolas.dufresne@gmail.com on 7 Nov 2010 at 2:17