openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Date Fri, 04 Mar 2016 13:22:39 GMT


On 3/4/2016 4:40 AM, Damjan Jovanovic wrote:
> On Fri, Mar 4, 2016 at 11:59 AM, Patricia Shanahan <pats@acm.org> wrote:
>> On 3/4/2016 12:54 AM, Damjan Jovanovic wrote:
>>>
>>> ELF binaries (Linux, *BSD) fundamentally use one of the worst ideas of
>>> all time: symbols are process scoped (unlike on Windows and MacOS
>>> where they're library scoped), meaning that symbols with the same name
>>> can clash even if in different libraries loaded through arbitrary
>>> layers of indirection. For example, compiling AOO with GCC on recent
>>> FreeBSD easily crashes AOO because both GCC's and Clang's C++ runtime
>>> libraries are loaded, their symbols clash with each other, and their
>>> ABIs are not fully compatible -> memory corruption -> undebuggable
>>> crash. Symbol map files are supposed to work around the problem
>>> because the UDK_3_0_0 becomes part of the symbol name and makes it
>>> more globally unique.
>>>
>>> I don't know if UDK_3_0_0 is correct since we are on AOO version 4 now
>>> (or do we version UDK differently?).
>>
>>
>> Embedding version numbers in source code should be done very sparingly,
>> because it grows old fast.
>>
>>>
>>> Also UNO is all good in theory, but in practice plugins can always use
>>> run-time dynamic linking to load any library and call any exported
>>> function (which the profile functions are) - even when running in a
>>> separate process, or written a different language (eg. JNA/BridJ for
>>> Java). Whether they actually do this in practice is the more important
>>> question.
>>
>>
>> I have a possibly pathetic hope that the 14 year deprecation of the
>> functions may have discouraged their direct use in plugins.
>>
>>
>
> main/sal/rtl/source/bootstrap.cxx uses osl::Profile().readString() in
> 1 place. osl::Profile found in main/sal/inc/osl/profile.hxx is a thin
> C++ wrapper around the C API. That seems to be the extent of the usage
> of the profile API in SVN trunk. I can't remember where else I found
> them, but on https://wiki.openoffice.org/wiki/Documentation/DevGuide/WritingUNO/Manual_Component_Installation
> there is a brief mention of these ini/rc files that I suspect are
> parsed by the profile API. Examples are in the program/ directory of
> the AOO installation (there is quite a few, all ending in ".ini" on
> Windows and "rc" elsewhere, eg. uno.ini/unorc).
>
> As for locking, all platforms can and do lock the file against access
> from other processes (LockFileEx on Windows, fcntl+F_SETLKW on *nix)
> though on *nix it is only *advisory* locking. The pthread API would
> only be useful to ensure thread safety within the process. I presume
> "bootstrapping" only happens once per process, so it can't really be
> multi threaded anyway?

My current theory is that the "unx" profile.c pthread_mutex uses are 
bogus, and should be removed. It would be better to keep profile 
operations single threaded at the top level, not engage in fine grained 
locking of Profile structs.

I suspect that an attempt to make the Profile code thread-safe was in 
process in 2000 at the time of the snapshot of StarOffice code that 
started OpenOffice. The Sun developers would have been working mainly on 
Solaris, so the "unx" version would be the trailblazer.

Patricia



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message