Hi,

I don't know if this bug is an icedove problem or a libnss-ldap problem. I open
the report at icedove since the problem is only triggered with icedove.

The system uses LDAP based user logins and NFS based home directories. It is a
fresh installation, another system is working fine using a simular setup.

Starting icedove results into an immediately crash at *every* run:

thomas@buechse:~$ unset LANG
thomas@buechse:~$ icedove --safe-mode
Segmentation fault (core dumped)
thomas@buechse:~$ gdb /usr/lib/icedove/icedove-bin core
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/lib/icedove/icedove-bin...Reading symbols from /usr/lib/debug/usr/lib/icedove/icedove-bin...done.
done.
[New LWP 5104]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff385fe000
Core was generated by `/usr/lib/icedove/icedove-bin --safe-mode'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007ffb3d9b0fbb in strtok_r () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffb3d9b0fbb in strtok_r () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffb391a9e61 in ldap_str2charray (str=0x7ffb30d4020d "ldap://localhost/", brkstr=0x7ffb30d3ff6e ", ") at charray.c:218
#2  0x00007ffb30d297a5 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#3  0x00007ffb30d2b02f in ldap_int_initialize_global_options () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#4  0x00007ffb30d2b1ad in ldap_int_initialize () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#5  0x00007ffb30d10aab in ldap_create () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#6  0x00007ffb30d1104a in ldap_initialize () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#7  0x00007ffb30f5410a in ?? () from /lib/x86_64-linux-gnu/libnss_ldap.so.2
#8  0x00007ffb30f5545b in ?? () from /lib/x86_64-linux-gnu/libnss_ldap.so.2
#9  0x00007ffb30f56c07 in ?? () from /lib/x86_64-linux-gnu/libnss_ldap.so.2
#10 0x00007ffb30f57197 in _nss_ldap_getpwnam_r () from /lib/x86_64-linux-gnu/libnss_ldap.so.2
#11 0x00007ffb3d9d8ced in getpwnam_r () from /lib/x86_64-linux-gnu/libc.so.6
#12 0x00007ffb36d17d09 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffb36d1884d in g_get_home_dir () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007ffb35f51587 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#15 0x00007ffb35f55eb3 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#16 0x00007ffb35f0703a in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#17 0x00007ffb36cf75d7 in g_option_context_parse () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007ffb35f075be in gtk_parse_args () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#19 0x00007ffb3bb4a4eb in XRE_main (argc=<optimized out>, argv=<optimized out>, aAppData=<optimized out>)
    at /build/icedove-J7T4Xk/icedove-10.0.12/mozilla/toolkit/xre/nsAppRunner.cpp:3051
#20 0x0000000000401f49 in do_main (argv=0x7fff384a00c8, argc=2, exePath=0x7fff3849efb8 "/usr/lib/icedove/libxpcom.so")
    at nsMailApp.cpp:143
#21 main (argc=2, argv=0x7fff384a00c8) at nsMailApp.cpp:226
(gdb)

I'm wondering why the URI 'ldap://localhost/' is printed in the backtrace - the
configuration file generated by debconf does contain the correct ldap server:

thomas@buechse:~$ egrep '(127.0.0.1|localhost|uri|host)' /etc/libnss-ldap.conf
# Multiple hosts may be specified, each separated by a
#host 127.0.0.1
uri ldap://10.0.0.66/
#uri ldap://127.0.0.1/
#uri ldaps://127.0.0.1/
#uri ldapi://%2fvar%2frun%2fldapi_sock/
# Check the 'host' attribute for access control
# value for the host attribute, and pam_ldap is
#pam_check_host_attr yes
#nss_base_hosts         ou=Hosts,dc=padl,dc=com?one
# Disable SASL security layers. This is needed for AD.

Other packages do not hit this problem - even iceweasel is working fine.


Regards,
Thomas

Hello Thomas,

Am 24.03.2013 22:34, schrieb Thomas Liske:

can you please make log with the activity of Icedove itself?

http://wiki.debian.org/Icedove#Debugging_of_Filesystem_Activity
http://wiki.debian.org/Icedove#Debugging_Icedove_Activity

You can combine the two logs into one file please!

Hi Carsten,

I've done the following:

thomas@buechse:~$ unset LANG
thomas@buechse:~$ export NSPR_LOG_MODULES=MCD:5
thomas@buechse:~$ export NSPR_LOG_FILE=/tmp/icedove-mcd.txt
thomas@buechse:~$ strace -e file -f -s2048 -o /tmp/icedove-strace.txt
icedove
Segmentation fault (core dumped)
thomas@buechse:~$ ls -lha /tmp/icedove-*
-rw-r--r-- 1 thomas users   0 Mar 25 20:31 /tmp/icedove-mcd.txt
-rw-r--r-- 1 thomas users 54K Mar 25 20:31 /tmp/icedove-strace.txt

The MCD log is empty, nothing to combine at all.



HTH,
Thomas

Hello Thomas,

you allready use the deprecated version from stable? We wont do any work
on this old ESR version.

If the error happen on the latest 17.0.10 in stable-security please
create a debugging log with the icedove debug package [1]. Without any
output we can't catch anything.
Please try before to start Icedove without any extension in safe-mode.

[1] https://wiki.debian.org/Icedove#Debugging

Regards
Carsten

Hi Carsten,

the issue is still here on stable-security:

thomas@buechse:~/tmp/icedove.crash$ dpkg -l 'icedove*'
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  icedove        17.0.10-1~de amd64        mail/news client with RSS
and int
un  icedove-adbloc <none>                    (no description available)
ii  icedove-dbg    17.0.10-1~de amd64        Debug Symbols for Icedove
un  icedove-gnome- <none>                    (no description available)
ii  icedove-l10n-d 1:17.0.7-1~d all          German language package for
Icedo
un  icedove-nostal <none>                    (no description available)
ii  icedove-quotec 0.3-3        all          Colorize different quoting
levels

thomas@buechse:~$ icedove -safe-modes
Segmentation fault (core dumped)

I've traced the crash with gdb via:

/usr/lib/icedove/run-mozilla.sh -g /usr/lib/icedove/icedove-bin 2>&1 |
tee /tmp/gdb.log

Please find the log attached. It seems that it crashes still the same way.


HTH & TIA,
Thomas

Hi,

Some form of this bug still occurs in icedove 38.1.0-1 in unstable.  Icedove
does not crash at startup, but does when I click the "attach" button in a
compose window.

I dug into it with gdb and found something interesting.  Observe this excerpt
from the gdb session (I have edited the backtrace to keep line lenghts
somewhat sensible):

  (gdb) r
  Starting program: /usr/lib/icedove/icedove-bin
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

  (process:13260): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
  [A bunch of "new thread" messages]

  Program received signal SIGSEGV, Segmentation fault.
  strtok_r () at ../sysdeps/x86_64/strtok.S:186
  186     ../sysdeps/x86_64/strtok.S: No such file or directory.
  (gdb) bt 4
  #0  0x00007ffff6e04c88 in strtok_r () at ../sysdeps/x86_64/strtok.S:186
  #1  0x00007ffff68d14e7 in ldap_str2charray (str=0x7fffc5bd024c "ldap://localhost/", ...)
      at /build/icedove-iBYCQn/icedove-38.1.0/ldap/sdks/c-sdk/ldap/libraries/libldap/charray.c:218
  #2  0x00007fffc5bb86c6 in ldap_url_parselist_int (..., url=0x7fffc5bd024c "ldap://localhost/", ...)
      at url.c:1293
  #3  0x00007fffc5bb87e1 in ldap_url_parselist (..., url=0x7fffc5bd024c "ldap://localhost/")
      at url.c:1318
  #4  0x00007fffc5bba25f in ldap_int_initialize_global_options (...) at init.c:543
  (gdb) info symbol 0x00007ffff68d14e7
  ldap_str2charray + 135 in section .text of /usr/lib/icedove/libldap60.so
  (gdb) info symbol 0x00007fffc5bb86c6
  ldap_url_parselist_int + 86 in section .text of /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2

What's this?  ldap_url_parselist_int and ldap_str2charray are in different
libraries?  Downloading the sources reveals that icedove ships its own copy of
libldap, which interferes with symbol resolution from the system libldap.

Let's dig further.  The relevant line for frame #4 is:

  ldap_url_parselist(&gopts->ldo_defludp, "ldap://localhost/");

The second argument is passed all the way through to the offending
ldap_str2charray function.  The relevant line there reads:

  for ( s = STRTOK( str, brkstr, &lasts ); s != NULL; s = STRTOK( NULL,

With str being the string in question.  For those not familiar with libc,
strtok operates by finding the separator character and then overwriting it
with a nul byte.  But wait, didn't we have a string literal here?  String
literals are usually stored in a read-only section of memory as confirmed by
gdb and /proc/`pidof icedove`/maps:

  0x00007fffc5bcc300 - 0x00007fffc5bd1a69 is .rodata in /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2

  7fffc5b8e000-7fffc5bdb000 r-xp 00000000 08:05 920396  /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.5

So it's trying to write into a read-only section of memory and the kernel says
"no, you can't do that".  By contrast, the system libldap's ldap_str2charray
does this as the first thing upon entry:

  /* protect the input string from strtok */
  str = LDAP_STRDUP( str_in );

I don't have a permanent solution, but as a temporary one the library load
order can be tweaked with LD_PRELOAD:

  LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 icedove

This forces the system libldap to be loaded first, so it resolves with its own
symbols.