Issues building LibreOffice 4.0.0.1
Henrik /KaarPoSoft
henrik at kaarposoft.dk
Tue Jan 29 12:31:01 PST 2013
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
More information about the LibreOffice
mailing list