374731 - Thunderbird crashes with LDAP in opensolaris build 60

Status: RESOLVED WORKSFORME

(Directory :: LDAP C SDK, defect)

Description

[Boying Lu]

Re-produce steps:
1. Install latest opensolaris build which is build 60
2. start thunderbird and setup a mail account then quit
3. start thunderbird again
4. select "Edit" -->"Account Settings..."
5. select "Composition & Addressing" on the left panel of the popup window
6. select "Use a different LDAP server" and click "Edit Directories..." button on the right panel
7. setup LDAP then click "OK" button

Thunderbird crashes

Comment 1

[Boying Lu]

Attachment: Add $ORIGIN into the RUNPATH of libprldap50.so

Comment 2

[Mark Banner (:standard8)]

How does adding $ORIGIN fix this? Which versions of Thunderbird crash?

I presume you are able to build Thunderbird yourself? If so, could you try the patch on bug 359716 - this upgrades the LDAP c-sdk version that Thunderbird uses (so you'll need to pull again before recompiling), I'm planning on getting it into trunk within the next couple of weeks, so it may be a better resolution to the problem.

Moving to Directory/LDAP c-sdk as its the better location for this bug.

Comment 3

[Mark Smith [:mcs]]

Adding Anton and Rich to the bug CC.  Please provide more information, as requested.

Comment 4

[Anton Bobrov]

please provide backtrace from the crash. i suspect that wrong version/s of
some deps being fetched on Solaris or something but its just a guess which
is solely based on the problem description. btw there is no need for the
patch provided as we have --with-rpath switch to LDAP C-SDK configure that
can be used to set custom runpath as desired, given runtime linker support
.

Comment 5

[Alfred Peng]

Attachment: core stack

This bug is first introduced in Solaris Nevada b60 x86 for Thunderbird 2.0b2. The bundled binary is made by the source checked out from CVS directly with sun cc compiler.

Truss TB outputs the following message:
xstat(2, "/lib/libldap50.so", 0x080452F8)       Err#2 ENOENT
xstat(2, "/usr/lib/libldap50.so", 0x080452F8)   Err#2 ENOENT
xstat(2, "/usr/local/lib/libldap50.so", 0x080452F8) Err#2 ENOENT
xstat(2, "/usr/sfw/lib/libldap50.so", 0x080452F8) Err#2 ENOENT
xstat(2, "/opt/sfw/lib/libldap50.so", 0x080452F8) Err#2 ENOENT
munmap(0xCA6B0000, 11362)                       = 0
munmap(0xCA6C2000, 4284)                        = 0
     Incurred fault #6, FLTBOUNDS  %pc = 0xD13DC9D5
       siginfo: SIGSEGV SEGV_MAPERR addr=0x00006F58
     Received signal #11, SIGSEGV [caught]
       siginfo: SIGSEGV SEGV_MAPERR addr=0x00006F58

The library "libldap50.so" is in /usr/lib/thunderbird on Solaris and is skipped.

Brian has a detail linking output which shows that libprldap50.so doesn't contian $ORIGIN in its RUNPATH. When libprldap50.so tries to load libldap50.so, it fails and a SEGV happens.

Comment 6

[Mark Banner (:standard8)]

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/configure.in&rev=1.1776#2253 may be of interest

Comment 7

[Anton Bobrov]

(In reply to comment #5)

well it seems that Nevada b60 userland runtime linker shot itself in the foot
in this case probably due to lazy loading stuff getting too tangled up there
at that point. you should be getting "cant find symbol" message from runtime 
linker and exit or something like that not SEGV inside runtime linker code.
please do file a bug on Solaris side as well so this can be investigated for
good, i'm certainly no expert on that stuff.

regarding truss output. is that all about libldap there is ? can you do truss 
-f right from the start and grep for libldap til crash ? i wonder if it does
fetch something else eg diff version or something. worth a quick check.

as for runpath and origin i reckon its a good idea if Thunderbird build does
LDAP C-SDK configure with --with-rpath switch that includes $ORIGIN, at least
on Solaris. i'm not sure about Thunderbird itself, if it needs it or not and
i leave this further to Mark and other folks to comment on.

Comment 8

[Boying Lu]

(In reply to comment #4)
> please provide backtrace from the crash. i suspect that wrong version/s of
> some deps being fetched on Solaris or something but its just a guess which
> is solely based on the problem description. btw there is no need for the
> patch provided as we have --with-rpath switch to LDAP C-SDK configure that
> can be used to set custom runpath as desired, given runtime linker support
> .
> 

I think "--wth-rpath" is used for customize the runpath. But for this bug, $ORIGIN should be set even without this option. (BTW: how can i use this option when building ThunderBird?).  

The point is that '$ORIGIN' should be in the runpath of libprldap50.so because it depends on libldap50.so which is under same directory.  Currently the runpath of libprldap50.so is empty and it can't find libldap50.so (you can verify this by running ldd -u -r libprldap50.so).

Comment 9

[Anton Bobrov]

(In reply to comment #8)

$ORIGIN tag is part of runpath. i have no idea how you can tweak it from
within the Thunderbird build tho, i suspect you will have to manually 
hack some build scripts/files there.

> I think "--wth-rpath" is used for customize the runpath. But for this bug,
> $ORIGIN should be set even without this option. (BTW: how can i use this option
> when building ThunderBird?).  
> 
> The point is that '$ORIGIN' should be in the runpath of libprldap50.so because
> it depends on libldap50.so which is under same directory.  Currently the
> runpath of libprldap50.so is empty and it can't find libldap50.so (you can
> verify this by running ldd -u -r libprldap50.so).

Comment 10

[Boying Lu]

(In reply to comment #9)
> (In reply to comment #8)
> 
> $ORIGIN tag is part of runpath. i have no idea how you can tweak it from
> within the Thunderbird build tho, i suspect you will have to manually 
> hack some build scripts/files there.
> 

No, I didn't do any hack work on Thunderbird. Download nightly build and run 
"ldd libprldap60.so" on ubuntu, you will find the error message "libldap60.so ==> not found"

Check the runpath of libprldap60.so by running "chrpath -l libprldap60.so", you will find that libprldap60.so has no runpath.

So  libprldap60.so depends on libldap60.so, but it doesn't contain any runpath to locate the libldap60.so.

My patch is to add '$ORIGIN' to shared libraries's runpath.

Comment 11

[Anton Bobrov]

(In reply to comment #10)

> My patch is to add '$ORIGIN' to shared libraries's runpath.

this is not needed. use --wth-rpath flag when doing C-SDK configure to
specify whatever runpath suits you, include ORIGIN in there or pretty
much anything you like. this is what i do for in house C-SDK builds
that require custom JES runpath and i dont see why you cannot do
the same for TBird.

Comment 12

[Boying Lu]

(In reply to comment #11)
> (In reply to comment #10)
> 
> > My patch is to add '$ORIGIN' to shared libraries's runpath.
> 
> this is not needed. use --wth-rpath flag when doing C-SDK configure to
> specify whatever runpath suits you, include ORIGIN in there or pretty
> much anything you like. this is what i do for in house C-SDK builds
> that require custom JES runpath and i dont see why you cannot do
> the same for TBird.
> 

Since libprldap60.so always depends on libldap60.so, it should contain path ($ORIGIN) to locate libldap60.so. Why I need to remember to use --with-rpath to do this?

Comment 13

[Anton Bobrov]

(In reply to comment #12)

if you wanna have $ORIGIN defined in the default rpath for libs, without
explicitly specifying it using --with-rpath flag during configuration,
you need to modify DEFAULT_RPATHFLAG in configure/in.

Comment 14

[Boying Lu]

(In reply to comment #13)
> (In reply to comment #12)
> 
> if you wanna have $ORIGIN defined in the default rpath for libs, without
> explicitly specifying it using --with-rpath flag during configuration,
> you need to modify DEFAULT_RPATHFLAG in configure/in.
> 

If I use DEFAULT_RPATHFLAG, I still need to use "--with-rpath" option though I don't need to provide a value for this option and other paths in DEFAULT_RPATHFLAG will be added to RUNPATH which is not necessary.

So I still prefer to use DSO_LDOPTS instead of DEFAULT_RPATHFLAG.

The key point is that libprldap60.so should locate libldap60.so by itself when it is loaded by ld.so.1 and set $ORIGIN in its RUNPATH is a reasonable solution. I think.

Comment 15

[Anton Bobrov]

(In reply to comment #14)

i dont like DSO_LDOPTS approach. i'm not against having $ORIGIN in default rpath
and also having default rpath enabled by default, both seems reasonable to me,
however we need to make sure that :

- rpath is configurable and therefore predictable, from a single point in the
  configuration not spread across popping up in various places making a mess.

- if default rpath is enabled by default something like --without-rpath should
  disable it completely if needed.

further to this bear in mind that you are not the only one with rpath reqs and
also that we have a single rpath for both tools and libraries.

Comment 18

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 259182 [details] [diff] [review]
Add $ORIGIN into the RUNPATH of libprldap50.so

First off, apologies for letting this fall on the floor.  That said, I'm no longer active in the LDAP C SDK code.  According to <http://www.mozilla.org/owners.html>, Anton, who has already weighed in, would be a good reviewer, so I'm going to mark it r- on his behalf.

Comment 19

[Boying Lu]

In thunderbird3, since thunderbird-bin depends on libldap60.so directly, the crash doesn't exist any more.  Close the bug

Comment 20

[Mark Banner (:standard8)]

(In reply to comment #19)
> In thunderbird3, since thunderbird-bin depends on libldap60.so directly, the
> crash doesn't exist any more.  Close the bug

=> WFM as we haven't got a reference as to which bug did the rename.