Causing segfault in plugin_load

[GoogleCodeExporter]

Installed pidgin-opensteamworks 1.4 on Arch - but haven't used it (It was one 
of the 'I want to give it a try' packages during installation). I DO need 
pidgin-sipe though.
pidgin-sipe failed during ./configure with

configure:14249: error: in 
`/tmp/yaourt-tmp-gottz/aur-pidgin-sipe/src/pidgin-sipe-1.18.0':
configure:14251: error: your purple hasn't been compiled with SSL support. 

quite misleading, since the 'do we have SSL support compiled in' test is a 
small binary that segfaults, as shown in the config.log:

./configure: line 1820: 10670 Segmentation fault (core dumped) 
./conftest$ac_exeext
configure:14245: $? = 139
configure: program exited with status 139

After extracting that binary and running it myself I get this backtrace:

(gdb) bt
#0  0x00007ffff7514696 in __strcmp_ssse3 () from /usr/lib/libc.so.6
#1  0x00007ffff77d2fc9 in g_str_equal () from /usr/lib/libglib-2.0.so.0
#2  0x00007fffe2a1dcd5 in plugin_load (plugin=<optimized out>) at 
libsteam.c:1346
#3  0x00007ffff7b1d78e in purple_plugin_load (plugin=0x706560) at plugin.c:606
#4  0x00007ffff7b1e9dd in purple_plugins_probe (ext=0x7fffe31f7ceb "pl") at 
plugin.c:1419
#5  0x00007ffff7b1ea70 in purple_plugins_probe (ext=0x7ffff1ff35e1 "tcl") at 
plugin.c:1413
#6  0x00007ffff7b1ea70 in purple_plugins_probe (ext=0x400834 "so") at 
plugin.c:1413
#7  0x0000000000400799 in main ()

In other words: This project's initialization seems to break something, which 
in turn breaks the weird way pidgin-sipe detects ssl support. The full test 
program from pidgin-sipe's configure and the resulting backtrace can also be 
found at [1].

Given the stack above I'd say it has to be here [2], although I've no clue 
about the purple api or this project? A quick Google search turns up [3] on the 
first page, so .. maybe this call is broken at the moment/on the major 
architecture? Maybe this needs a Better Way™, given that upstream hasn't 
fixed that bug for years?

1: https://gist.github.com/darklajid/3d8a68db1941493e7f0c
2: 
https://code.google.com/p/pidgin-opensteamworks/source/browse/trunk/steam-mobile
/libsteam.c#1382
3: https://developer.pidgin.im/ticket/15167

Original issue reported on code.google.com by benjamin.podszun@gmail.com on 19 May 2014 at 3:33

[GoogleCodeExporter]

Interesting configure check :-) 

I would presume that the purple_core_get_ui() call is returning null and that 
g_str_equal() doesn't play nice with nulls? 

There's a purple string comparison function that's supposed to handle nulls 
better that I might switch to using. I guess this should also be reported to 
the pidgin-sipe guys too :-) 

Original comment by eionrobb on 19 May 2014 at 7:11

• Changed state: Accepted

[GoogleCodeExporter]

I cannot judge the stuff pidgin-sipe is doing - I'm merely a user.
I DO find this 'test program' a little weird, but I'm not sure if they can take 
the blame here: Any purple-using program (without a UI?) would probably 
segfault as long as pidgin-opensteamworks is available.

Note that in cases like these (and I'd say that's a valid use for libpurple, 
even if the sample program is trivial) there is NO UI at all.

You're the C guy. Can you check what pruple_core_get_ui() returns in the sample 
I pasted (see gist, including the compilation command specific for my Arch 
installation)? I'd guess that it _doesn't_ return null but some weird number 
(see pidgin ticket I linked to) and that leads to the sigsev. I'd be 
disappointed if a simple null would cause this problem. But as I said: You're 
the expert :) My C knowledge is a 1-2 on a scale from 1 to 10, tops, and my 
investigations would probably look more like butchering. Plus, I don't know why 
you need the UI detection (i.e. why the dependency, why is this the way to go 
to detect whether gnome-keyring is required etc) at all.

Thanks for investigating!

Original comment by benjamin.podszun@gmail.com on 20 May 2014 at 5:21