Re: Issues building LibreOffice 4.0.0.1

On 01/29/2013 01:53 PM, Stephan Bergmann wrote:
> On 01/24/2013 10:43 PM, Henrik /KaarPoSoft wrote:
> > On 01/24/2013 10:09 AM, Stephan Bergmann wrote:
> > > On 01/24/2013 12:33 AM, Henrik /KaarPoSoft wrote:
> > > > On 01/23/2013 04:54 PM, Stephan Bergmann wrote:
> > > > > On 01/23/2013 08:31 AM, Henrik /KaarPoSoft wrote:
> > > > > Your strace lines like
> > > > >
> > > > > > 9579  08:05:59.537424 openat(AT_FDCWD,
> > > > > > "/opt/kaarpux/libreoffice-4.0.0.1/lib/libreoffice/program/../program/r",
> > > > > >
> > > > > >
> > > > > >
> > > > > > O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file
> > > > > > or directory)
> > > > > > 9579  08:05:59.537514 open("dkten-US.res", O_RDONLY) = -1 ENOENT (No
> > > > > > such file or directory)
> > > > > > 9579  08:05:59.537672
> > > > > > access("/opt/kaarpux/libreoffice-4.0.0.1/lib/libreoffice/program/../progra",
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > F_OK) = -1 ENOENT (No such file or directory)
> > > > > > 9579  08:05:59.537725
> > > > > > access("/opt/kaarpux/libreoffice-4.0.0.1/lib/libreoffice/program/unorc",
> > > > > >
> > > > > >
> > > > > >
> > > > > > F_OK) = 0
> > > > > > 9579  08:05:59.537767
> > > > > > access("/opt/kaarpux/libreoffice-4.0.0.1/lib/libreoffice/program/../program/boot",
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > F_OK) = -1 ENOENT (No such file or directory)
> > > > >
> > > > > look oddly truncated.  For example, there should be a
> > > > > .../program/boostraprc file that soffice.bin would indeed try to open
> > > > > early on.
> > > >
> > > > Sorry, I just ran LO with --strace option.
> > > > Attached is the corresponding output with strace -s2048
> > > >
> > > > Apart from not finding "libreoffice/program/../program/boot"
> > > > the search for "libreoffice/program/../progra" (without trailing m)
> > > > looks suspicious
> > >
> > > With "oddly truncated" I did mean the filenames in the strace output
> > > (which should never be truncated by strace, regardless of any -s
> > > settings).  (And there's a typo in what I wrote, the non-truncated
> > > filename is "bootstraprc", not "boostraprc".)
> >
> > Sorry about the confusion, my bad.
> > I guess that misunderstandings aside we agree, that the paths looks
> > oddly truncated.
> > I have no clue why this would happen.
> > Any ideas?
>
> So I just ran into a problem with a libreoffice-4-0-0 build of mine on
> Mac OS X whose symptoms looked very much like the above, expanding LO
> bootstrap variables ($UserInstallation from bootstraprc in my case) to
> pathnames that were oddly truncated.  I tracked that down to bad calls
> to putenv (the code to expand bootstrap variables in
> sal/rtl/source/bootstrap.cxx tries to obtain values for that variables
> via getenv, among others, so it is susceptible to problems resulting
> from a broken environment), see
> <http://cgit.freedesktop.org/libreoffice/core/commit/?id=d841273ba54b173020aa8da18ba7841cf950c13c>
> "Do not call putenv with a temporary string argument."
>
> While that fix is in Mac OS X specific code (so cannot be the cause of
> your Linux problems), there are more calls to putenv in the LO code
> base, and some of the might be broken in a similar way.
>
> Stephan

Thank you very much for pointing out this problem, Stephan!!

grep shows 40 files containing "putenv"

android/Bootstrap/src/org/libreoffice/android/Bootstrap.java
android/experimental/LibreOffice4Android/src/org/libreoffice/ui/LibreOfficeUIActivity.java
android/experimental/LibreOffice4Android/src/org/libreoffice/android/DocumentLoader.java
android/experimental/DocumentLoader/src/org/libreoffice/android/examples/DocumentLoader.java
ChangeLog
cppuhelper/test/loader/loader.test.cxx
crashrep/source/unx/main.cxx
crashrep/source/win32/soreport.cpp
dmake/unix/bsdarm32/config.mk
dmake/unix/bsdarm32/make.sh
dmake/unix/bsdarm32/putenv.c
dmake/unix/sysvr1/putenv.c
dmake/unix/bsd43/uw/make.sh
dmake/unix/bsd43/vf/make.sh
dmake/unix/bsd43/config.mk
dmake/unix/bsd43/make.sh
dmake/unix/bsd43/putenv.c
dmake/tos/config.mk
dmake/tos/make.sh
dmake/tos/putenv.c
dmake/sysintf.c
dmake/ChangeLog
extensions/test/ole/OleConverterVar1/convTest.cxx
jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
odk/source/unoapploader/unx/unoapploader.c
odk/source/unoapploader/win/unoapploader.c
sal/qa/rtl/bootstrap/rtl_Bootstrap.cxx
sal/qa/rtl/logfile/rtl_logfile.cxx
sal/android/lo-bootstrap.c
sal/osl/w32/process.cxx
sal/osl/unx/process_impl.cxx
sal/osl/unx/process.cxx
sal/osl/unx/signal.c
stoc/test/testsmgr.cxx
stoc/test/testregistry.cxx
svtools/bmpmaker/bmp.cxx
svtools/bmpmaker/bmpsum.cxx
ucb/workben/ucb/ucbdemo.cxx
vcl/aqua/source/app/salinst.cxx
vcl/ios/source/app/salinst.cxx

I am starting to look through those that looks relevant to my problem:

cppuhelper/test/loader/loader.test.cxx
putenv usage seems wrong; it is auto allocated.
But does not seem to be related to my problem, so I will leave it for now.

jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
Has strdup; so probably OK (although leaking)

odk/source/unoapploader/unx/unoapploader.c
Has malloc; so probably OK (although leaking)

sal/qa/rtl/bootstrap/rtl_Bootstrap.cxx
Only for #if (defined WNT) || (defined SOLARIS)
so not relevant; other targets have setenv

sal/qa/rtl/logfile/rtl_logfile.cxx
As sal/qa/rtl/bootstrap/rtl_Bootstrap.cxx

sal/osl/unx/process_impl.cxx
Only for #if defined (SOLARIS)
so not relevant

sal/osl/unx/signal.c
has
putenv( rtl_string_getStr( strEnv ) );
I have no clue about rtl_string_getStr
maybe OK maybe not ?

sal/osl/unx/process.cxx
has
putenv(data.m_pszEnv[i]);

THIS MIGHT BE RELEVANT

We have

static void ChildStatusProc(void *pData)
{
...
    ProcessData  data;
    ProcessData *pdata;
...
    pdata = (ProcessData *)pData;
    /* make a copy of our data, because forking will only copy
       our local stack of the thread, so the process data will not be 
accessible
       in our child process */
    memcpy(&data, pData, sizeof(data));
...
    if ( (status == 0) && ((pid = fork()) == 0) )
    {
...
                if (strchr(data.m_pszEnv[i], '=') == NULL)
                {
                    unsetenv(data.m_pszEnv[i]); /*TODO: check error 
return*/
                }
                else
                {
                    putenv(data.m_pszEnv[i]); /*TODO: check error return*/
                }
            }

It looks to me like the comment intends a deep copy, whereas the memcpy 
only does a shallow copy.

I do not have enough knowledge of LibreOffice to figure out how to solve 
this without introducing bugs of my own.

Any input on this would be most appreciated...

/Henrik