Bug 361461

Created attachment 245471 [details]
back trace

It segfaults in libldap, which is the "openldap" package.
Please reproduce with an installed openldap-debuginfo package
to complete the missing details in the backtrace.

Created attachment 245551 [details]
backtrace with openldap-debuginfo installed

Now this was my test-case:

1. start Sylpheed (gdb `which sylpheed`; run --disable-crash-dialog), go to
address-book, select LDAP source
2. search for "Chris"
   # I got expected results
3. search for "Chris" again
   # crash

That's a completely different backtrace, which really ends in
Sylpheed's code. I'm reassigning the ticket once more.

The other segfault that happens in libldap is worth examining, too,
however, since a library ought to protect itself from crashing.

That place in the code where the backtrace from comment 3 points at
has only few reasons to crash (e.g. memory corruption or junk
returned by libldap). It retrieves entry attributes from OpenLDAP
and stores them, properly checking for NULL pointers.

Upstream has been notified. I've tried to reproduce it on i686/athlon
with lots of ldap lookups, but cannot reproduce it.

[...]

However, I've found a memory leak and the cause of the GLib
critical warning. A fix for that can be found here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=23184

There is sylpheed-2.4.7-1.3 in updates-testing. Are you still
able to reproduce these LDAP related problems?

Created attachment 292500 [details]
Stability seems better to me

Stability seems better to me, but I just got this crash (generated by
bug-buddy).

Created attachment 292501 [details]
Stability seems better to me

Err, sorry, now with correct -debuginfo installed (from
http://koji.fedoraproject.org/koji/buildinfo?buildID=28328)

Where's the segmentation fault or fatal error condition?

With the word "crash" do you mean something different again?
For example, do you mean that you see network I/O time-outs as
you also did with IMAP before? That is something entirely different
from the initial comment in this ticket.

In both cases you traced into a running Sylpheed. That Sylpheed's
network access is imperfect is no secret. You can configure the
LDAP access timeout in Sylpheed's addressbook settings for your
LDAP Server.

Traceback in Comment #8 was generated by bug-buddy - I was searching through 
LDAP and bug-buddy suddenly appeared, so I think this is because Sylpheed core-
dumped.

To be sure it is not a problem with some specific LDAP settings, I have created 
new LDAP connection in address-book:

http://www.emailman.com/ldap/public.html
Baylor University
LDAP server = ldap.baylor.edu
LDAP base = ou=People,o=Baylor University,c=US

BTW: "--disable-crash-dialog" had no effect and bug-buddy appeared again.



$ sylpheed --disable-crash-dialog

(sylpheed:9351): LibSylph-WARNING **: pobox-2.corp.redhat.com: SSL certificate 
verify failed (20: unable to get local issuer certificate)


warning: Missing the separate debug info file: /usr/lib/debug/.build-id/1f/
c12f77d41b9459cc0e771ed23a04a20938445f.debug

...

warning: Missing the separate debug info file: /usr/lib/debug/.build-id/f5/
f3b510af236cf3bc203da03affc9fdf05bbb58.debug

warning: Missing the separate debug info file: /usr/lib/debug/.build-
id/37/7603ca19da31ceaf621233f0c4d86e0c9d8d69.debug
Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve 
property `GtkTreeView::odd-row-color' of type `GdkColor' from rc file value 
"((GString*) 0x8398c0)" of type `GString'



Thank you for all your effort you are putting into this.

Created attachment 292516 [details]
With LDAP from Baylor University

#4  <signal handler called>
#5  ldap_search_ext (ld=0xffffffffb0000960, 
#6  0x00000030b140f5b2 in ldap_search_ext_s (ld=0xffffffffb0000960, 

That is in OpenLDAP again, not in Sylpheed.

When syldap_add_list_values calls ldap_get_values, ldap_get_values returns
correct char** pointer [1], but gchar** vals in syldap_add_list_values is
sometimes not valid [2]- the value is mangled somewhere between libldap and
sylpheed. 

[1]: if I set breakpoint at 'return' statement in ldap_get_values, I can see
valid pointer being returned (with some data inside)

[2]: if I set breakpoint at syldap.c:422 (just after the ldap_get_values call),
I *sometimes* can see in the debugger that the value of 'vals' is different to
value seen at breakpoint [1]

I tried to recompile everything with -O0, with the same result, I'll investigate
it further.

The sylpheed is wrongly compiled. If you compile it with -Wall, you can see:

syldap.c: In function 'syldap_add_list_values':
syldap.c:421: warning: implicit declaration of function 'ldap_get_values'
syldap.c:421: warning: assignment makes pointer from integer without a cast
syldap.c:427: warning: implicit declaration of function 'ldap_value_free'
syldap.c: In function 'syldap_add_single_value':
syldap.c:438: warning: assignment makes pointer from integer without a cast
syldap.c: In function 'syldap_search':
syldap.c:521: warning: implicit declaration of function 'ldap_init'
syldap.c:521: warning: assignment makes pointer from integer without a cast
syldap.c:532: warning: implicit declaration of function 'ldap_simple_bind_s'
syldap.c:536: warning: implicit declaration of function 'ldap_unbind'
syldap.c: In function 'syldap_read_basedn_s':
syldap.c:785: warning: assignment makes pointer from integer without a cast
syldap.c:815: warning: assignment makes pointer from integer without a cast
syldap.c:850: warning: assignment makes pointer from integer without a cast
syldap.c: In function 'syldap_read_basedn':
syldap.c:910: warning: assignment makes pointer from integer without a cast
syldap.c:944: warning: assignment makes pointer from integer without a cast
syldap.c:981: warning: assignment makes pointer from integer without a cast
syldap.c: In function 'syldap_test_connect_s':
syldap.c:1027: warning: implicit declaration of function 'ldap_open'
syldap.c:1027: warning: assignment makes pointer from integer without a cast
syldap.c: In function 'syldap_test_connect':

These undefined functions return some kind of pointer, but gcc uses default
prototype (=returning int). Int has 32 bites, pointer 64 -> additional warnings
+ crash.

Note: all these missing functions are deprecated by ldap, you can define
LDAP_DEPRECATED for quick&dirty fix or start using new functions (see ldap.h).

Thanks! That explains why it cannot be reproduced at run-time
on 32-bit. However, it's obvious when seeing the warnings and
the broken return values in the debugger.
-Wall is Fedora default (see "rpm --eval %optflags"), and these
warnings are in the official build logs, too. I can see them
when using rpmbuild directly.

Going to fix this with LDAP_DEPRECATED for now. Whether to port
to the current OpenLDAP API or wait for upstream, I don't know
yet.

sylpheed-2.3.1-6 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update sylpheed'

sylpheed-2.4.8-1.1 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update sylpheed'

Thank you very much for such a quick response and fix!

sylpheed-2.4.8-1.1 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

sylpheed-2.3.1-6 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.