One user had 64-bit environment.
He used 32-bit OOo.
He used ldap.
Unfortunately, he had installed only 64-bit /lib64/libnss_ldap.so.2

After some time, his OOo was unable to start. It seqfaulted, see the attached
back trace and strace.

It crashed in the following code in sal/rtl/source/bootstrap.cxx

--- cut ---
                if( ! *ppValue )
                {
                    if (name.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM("SYSUSERCO
NFIG") ))
                    {
                      ...
                    }
                    else if (name.equalsAsciiL( RTL_CONSTASCII_STRINGPARAM("SYSU
SERHOME") ))
                    {
                        oslSecurity security = osl_getCurrentSecurity();
                        osl_getHomeDir(security, ppValue);
                        EnsureNoFinalSlash(ppValue);
                        osl_freeSecurityHandle(security);
                        further_macro_expansion = false;
                    }
--- cut ---

Why?

1. 'ppValue' must have been NULL to reach the code below.
2. osl_getCurrentSecurity() returned NULL because the 32-bit libnss_ldap.so.2
was not installed and the user was not mentioned in /etc/password
3. osl_getHomeDir(security, ppValue) left the 'ppValue' unchanged because
'security == NULL'.
4. EnsureNoFinalSlash(ppValue) tried to access ppValue without any check. It was
NULL => SIGSEGV


Well, I am not sure if there is any reasonable solution for this situation.
It is low a level bug (one library/module is missing). Maybe, an assert would be
the best solution, for example:

--- cut ---
          oslSecurity security = osl_getCurrentSecurity();
          // password file entry cannot be read only in very strange situations,
for example see i#XXXX  <--- number of this issue ;-)
          OSL_ASSERT(security);
          osl_getHomeDir(security, ppValue);
          EnsureNoFinalSlash(ppValue);
          ...
--- cut ---

It was relatively easy to solve the problem after searching strace.
I think that it would be more complicated if we tried to ignore this problem or
if we tried to print any general user friendly message.

Or we can ignore this problem at all. It is not typical that
osl_getCurrentSecurity fails that the rest of the user desktop is still usable.
I happened this time only because of the strage combination of 64-bit
environment and 32-bit OOo.


What do you think?