You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2016/02/29 20:02:07 UTC
Profile.c bugs (was RE: Some thoughts on the learning curve)
Patricia,
Take a look at main/sal/inc/osl/profile.h
Methinks that the code identified in <https://bz.apache.org/ooo/show_bug.cgi?id=126669> might not be built for current releases on Windows or Linux. You'll see that there are filename suffixes such as .rc and .ini used. I doubt that has anything to do with handling profiles now.
Is there a way we can check that the code is not built and/or and these profile functions are not used?
I don't know about builds for OS/2 and other downstream builds that we don't make ourselves.
And if the code is really obsolete, we should prune it from trunk and source releases.
- Dennis
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Saturday, February 20, 2016 20:57
> To: dev@openoffice.apache.org
> Subject: Re: Some thoughts on the learning curve
>
>
>
> On 2/20/2016 8:39 PM, Dennis E. Hamilton wrote:
> > I sympathize with Pedro's observation.
> >
> > Meanwhile, although I am not an expert, I could stand to buddy up on
> > the following profile-related situation:
> > <https://bz.apache.org/ooo/show_bug.cgi?id=126669>.
>
> Looks interesting. I am familiar with pthread and memory management
> issues, so it may be a good area for me to work on.
>
> Patricia
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Oh my,
<http://www.openoffice.org/udk/>
Damjan and Carl will know much more about this. I am a little curious what the Win32 implementations of some of those are. A place I have been avoiding.
This is useful too,
<https://wiki.openoffice.org/wiki/User:Kr>
See the section 10.2 on threading. If there are other broken links in there, there is better information for tracking them down using the bibliographic information Kay Ramme has included. It appears we have found the correct Ousterhout paper.
It looks like the safe thing to do is fix the code rather than remove it. We need to find out more about aquireProfile and put this one to rest.
Thanks for finding this, Patricia.
- Dennis, still wondering when and where those profiles get written by the shipped code.
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Thursday, March 3, 2016 17:43
> To: dev@openoffice.apache.org
> Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning
> curve)
>
> On 3/3/2016 5:00 PM, Dennis E. Hamilton wrote:
> >> -----Original Message-----
> >> From: Patricia Shanahan [mailto:pats@acm.org]
> >> Sent: Thursday, March 3, 2016 14:38
> >> To: dev@openoffice.apache.org
> >> Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning
> >> curve)
> >>
> >> I am seriously considering starting a project to eliminate profile.c
> >> etc. and seeing what, if anything, breaks.
> >>
> >> Before I do that, I have a question about whether it could be
> accessed
> >> through any of OpenOffice's extension or plugin facilities? Even if
> it
> >> can, 14 years seems quite long enough for people to migrate off a
> >> deprecated interface.
> > [orcmid]
> >
> > I think the extensions and plugins depend on UNO objects. So long as
> that is the case, the profile code should be unreachable.
>
> I have found a file main/sal/util/sal.map that begins with:
>
> UDK_3_0_0 {
> global:
> GetVersionInfo;
> osl_acceptConnectionOnSocket;
> osl_acceptPipe;
> osl_acquireSocket;
> osl_acquirePipe;
> osl_acquireMutex;
> osl_acquireSemaphore;
> osl_addSignalHandler;
> osl_addToSocketSet;
> osl_assertFailedLine;
> osl_bindAddrToSocket;
> osl_breakDebug;
> osl_checkCondition;
> osl_clearSocketSet;
> osl_closeDirectory;
> osl_closePipe;
> osl_closeProfile;
> ...
>
> and goes on to mention several other profile.c /osl_.*Profile.*/
> function names in the same list.
>
> Unfortunately, I am seeing some indications that "UDK" relates to UNO.
>
> At the worst, the deprecation just means that other modules are supposed
> to access the profile only through UNO, not by including the header file
> and calling the functions directly.
>
> Patricia
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by Patricia Shanahan <pa...@acm.org>.
In the short term, incremental and iterative can go well, but in the
long term it only makes the bit rot worse. I have had bad experiences
both ways, so neither course guarantees success.
Thread synchronization is a particularly dangerous area for not having a
known design, because it can lead to infrequent, timing-dependent bugs.
In this case we can do both. I have seen messages from students wanting
to help. Rather than just asking them what they want to work on, find
out what skills they have and then point them at some of the things
where you think an incremental, local approach will work. Some of them
will be faster at coding C++ than I would be, because I last did
significant C++ programming before most current undergraduates were born.
Meanwhile, I can aim for bigger scope understanding, and may be able to
find ways to simplify some of the code. Even if I don't find
simplifications, once I understand more I'll be able to do a lot more to
debug and fix on a wider scope.
Patricia
On 3/4/2016 11:11 AM, Dennis E. Hamilton wrote:
...
> In my youth, I took the reverse approach a few times. It did not go
> well. I am very incremental and iterative in approaches now, even
> with what can grow into large efforts. Working with a monster
> existing code base which may have some significant bit rot is another
> story. Heroism won't carry the day. I am striving to not be too
> discouraged about that.
...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Patricia,
I do not want to discourage scratching an itch that is important to you.
I do need to express my concern for the limited capacity that we have for development work, and I have done that. Everyone is a volunteer, and at the end of the day we will have whatever we have.
Enough said. I admire your work and enjoy very much our dance through the profile.c threading issues, and also the Windows build setup, if the opportunity returns.
- Dennis
Side comments:
Starting with the least that can possibly work is an important principle for software maintenance, where the greatest fear is a hopeless regression or, worse for open-source especially, an incomplete effort for which the prize is not attained.
It does not mean that major architecture and feature matters cannot also be addressed. But the users won't wait forever to have their bad experiences cured and timely interim solutions (and workarounds) are important.
In my youth, I took the reverse approach a few times. It did not go well. I am very incremental and iterative in approaches now, even with what can grow into large efforts. Working with a monster existing code base which may have some significant bit rot is another story. Heroism won't carry the day. I am striving to not be too discouraged about that.
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Friday, March 4, 2016 10:25
> To: dev@openoffice.apache.org
> Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning
> curve)
>
> On 3/4/2016 9:39 AM, Dennis E. Hamilton wrote:
> > Patricia,
> >
> > Based on Damjan's finding that profile files are read by the
> > application and that some are created during setup, with others
> > copied in from the setup, it is settled that the code is used in
> > current distributions and is also available to extensions.
> >
> > I recommend that we catch our breath over the weekend, take a fresh
> > look at what we know, and then make that smallest repair that will
> > work.
> ...
> >
> > I would defer any extensive threading analysis and work on more
> > pressing maintenance issues first, especially since the UDK is
> > snarled up in this. It's worthwhile but other priorities deserve our
> > attention.
>
> From my point of view there are benefits to me continuing to work on
> threading analysis.
>
> Threading leverages my existing expertise in multiprocessor/multithread
> issues, and therefore might be a good general area for me to work on.
>
> I find it very, very difficult to study a large system in the abstract.
> I need a question I can get my teeth into to inspire reading, grep, etc.
> Learning my way around AOO is key to me becoming productive on it. "Why
> is the 'unx' code bristling with pthread_mutex calls but the 'w32'
> version does not seem to have anything similar?" is just the right sort
> of question to hold my attention. Maybe the 'w32' version needs
> synchronization it lacks. Maybe it has a simpler way of controlling
> access to the profile that could be copied for 'unx'. I want to know,
> and finding out will lead to me learning how AOO works.
>
> I am wary of the "smallest repair" strategy. It tends to avoid ever
> throwing anything out, leading to clutter, and ultimately
> unmaintainability.
>
> Patricia
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by Patricia Shanahan <pa...@acm.org>.
On 3/4/2016 9:39 AM, Dennis E. Hamilton wrote:
> Patricia,
>
> Based on Damjan's finding that profile files are read by the
> application and that some are created during setup, with others
> copied in from the setup, it is settled that the code is used in
> current distributions and is also available to extensions.
>
> I recommend that we catch our breath over the weekend, take a fresh
> look at what we know, and then make that smallest repair that will
> work.
...
>
> I would defer any extensive threading analysis and work on more
> pressing maintenance issues first, especially since the UDK is
> snarled up in this. It's worthwhile but other priorities deserve our
> attention.
From my point of view there are benefits to me continuing to work on
threading analysis.
Threading leverages my existing expertise in multiprocessor/multithread
issues, and therefore might be a good general area for me to work on.
I find it very, very difficult to study a large system in the abstract.
I need a question I can get my teeth into to inspire reading, grep, etc.
Learning my way around AOO is key to me becoming productive on it. "Why
is the 'unx' code bristling with pthread_mutex calls but the 'w32'
version does not seem to have anything similar?" is just the right sort
of question to hold my attention. Maybe the 'w32' version needs
synchronization it lacks. Maybe it has a simpler way of controlling
access to the profile that could be copied for 'unx'. I want to know,
and finding out will lead to me learning how AOO works.
I am wary of the "smallest repair" strategy. It tends to avoid ever
throwing anything out, leading to clutter, and ultimately
unmaintainability.
Patricia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Patricia,
Based on Damjan's finding that profile files are read by the application and that some are created during setup, with others copied in from the setup, it is settled that the code is used in current distributions and is also available to extensions.
I recommend that we catch our breath over the weekend, take a fresh look at what we know, and then make that smallest repair that will work.
I think that will include the following:
1. Moving the bogus unlock in osl_closeProfile to immediately after bIsValid is set false at line 300. We also need to confirm that any other of the exported procedures that synchronize on the mutex immediately release on finding bIsValid set false.
2. Verifying whether the two calls on acquireProfile depend on the mutex and whether any returned pointer is to a locked struct or not.
3. Depending on (2), determine whether or not it is appropriate to have an unconditional unlock at the end of the osl_closeProfile or not. Repair that aspect accordingly.
4. Also determine whether the top *pProfile structure can be deleted or not. Should it be left to guard against the possibility that a subsequent operation on some thread will attempt to use the mutex and check the bIsValid flag? That is the safe approach.
4.1 Find out if osl_openProfile always returns a fresh *oslProfile structure whenever it succeeds.
4.2 If so, the C++ wrapper destructor, ~Profile, can always delete the *profile in its state since it is not shared.
4.3 Any remaining "memory leak" should be cleaned-up at process shutdown.
I have the makings of a nano-branch with only the relevant files. We can use that to chew up and annotate the relevant source without munging the code base. I'll put that on the SVN shortly and we can add our notes and confirmed preconditions before settling on the repair that goes to trunk.
I would defer any extensive threading analysis and work on more pressing maintenance issues first, especially since the UDK is snarled up in this. It's worthwhile but other priorities deserve our attention.
- Dennis
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Friday, March 4, 2016 05:23
> To: dev@openoffice.apache.org
> Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning
> curve)
>
>
>
> On 3/4/2016 4:40 AM, Damjan Jovanovic wrote:
> > On Fri, Mar 4, 2016 at 11:59 AM, Patricia Shanahan <pa...@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/Manua
> l_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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by Patricia Shanahan <pa...@acm.org>.
On 3/4/2016 4:40 AM, Damjan Jovanovic wrote:
> On Fri, Mar 4, 2016 at 11:59 AM, Patricia Shanahan <pa...@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
RE: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Damjan,
A question below.
> -----Original Message-----
> From: Damjan Jovanovic [mailto:damjan@apache.org]
> Sent: Friday, March 4, 2016 04:41
> To: Apache OO <de...@openoffice.apache.org>
> Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning
> curve)
>
> On Fri, Mar 4, 2016 at 11:59 AM, Patricia Shanahan <pa...@acm.org> wrote:
[ ... ]
> 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/Manua
> l_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).
[ ... ]
[orcmid]
On modern installations of Windows, the Program Files (x86) folder is read/read-execute only and requires UAC approval to be written to, in general.
Looking at my machine, I see that only setup.ini and soffice.ini were created at the time of 4.1.2 installation (2015-11-10 for the one I am looking at) and the remainder, including bootstrap.ini, were copied directly from the setup itself and have earlier time stamps (mostly 2015-10-21 when the RC was built).
That answers the question about whether these are actually produced/used. Indeed they are.
Thanks, Damjan, this clears up a great deal.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by Damjan Jovanovic <da...@apache.org>.
On Fri, Mar 4, 2016 at 11:59 AM, Patricia Shanahan <pa...@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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by Patricia Shanahan <pa...@acm.org>.
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.
Patricia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by Damjan Jovanovic <da...@apache.org>.
On Fri, Mar 4, 2016 at 3:43 AM, Patricia Shanahan <pa...@acm.org> wrote:
> On 3/3/2016 5:00 PM, Dennis E. Hamilton wrote:
>>>
>>> -----Original Message-----
>>> From: Patricia Shanahan [mailto:pats@acm.org]
>>> Sent: Thursday, March 3, 2016 14:38
>>> To: dev@openoffice.apache.org
>>> Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning
>>> curve)
>>>
>>> I am seriously considering starting a project to eliminate profile.c
>>> etc. and seeing what, if anything, breaks.
>>>
>>> Before I do that, I have a question about whether it could be accessed
>>> through any of OpenOffice's extension or plugin facilities? Even if it
>>> can, 14 years seems quite long enough for people to migrate off a
>>> deprecated interface.
>>
>> [orcmid]
>>
>> I think the extensions and plugins depend on UNO objects. So long as that
>> is the case, the profile code should be unreachable.
>
>
> I have found a file main/sal/util/sal.map that begins with:
>
> UDK_3_0_0 {
> global:
> GetVersionInfo;
> osl_acceptConnectionOnSocket;
> osl_acceptPipe;
> osl_acquireSocket;
> osl_acquirePipe;
> osl_acquireMutex;
> osl_acquireSemaphore;
> osl_addSignalHandler;
> osl_addToSocketSet;
> osl_assertFailedLine;
> osl_bindAddrToSocket;
> osl_breakDebug;
> osl_checkCondition;
> osl_clearSocketSet;
> osl_closeDirectory;
> osl_closePipe;
> osl_closeProfile;
> ...
>
> and goes on to mention several other profile.c /osl_.*Profile.*/ function
> names in the same list.
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?).
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.
> Unfortunately, I am seeing some indications that "UDK" relates to UNO.
>
> At the worst, the deprecation just means that other modules are supposed to
> access the profile only through UNO, not by including the header file and
> calling the functions directly.
>
> Patricia
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by Patricia Shanahan <pa...@acm.org>.
On 3/3/2016 5:00 PM, Dennis E. Hamilton wrote:
>> -----Original Message-----
>> From: Patricia Shanahan [mailto:pats@acm.org]
>> Sent: Thursday, March 3, 2016 14:38
>> To: dev@openoffice.apache.org
>> Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning
>> curve)
>>
>> I am seriously considering starting a project to eliminate profile.c
>> etc. and seeing what, if anything, breaks.
>>
>> Before I do that, I have a question about whether it could be accessed
>> through any of OpenOffice's extension or plugin facilities? Even if it
>> can, 14 years seems quite long enough for people to migrate off a
>> deprecated interface.
> [orcmid]
>
> I think the extensions and plugins depend on UNO objects. So long as that is the case, the profile code should be unreachable.
I have found a file main/sal/util/sal.map that begins with:
UDK_3_0_0 {
global:
GetVersionInfo;
osl_acceptConnectionOnSocket;
osl_acceptPipe;
osl_acquireSocket;
osl_acquirePipe;
osl_acquireMutex;
osl_acquireSemaphore;
osl_addSignalHandler;
osl_addToSocketSet;
osl_assertFailedLine;
osl_bindAddrToSocket;
osl_breakDebug;
osl_checkCondition;
osl_clearSocketSet;
osl_closeDirectory;
osl_closePipe;
osl_closeProfile;
...
and goes on to mention several other profile.c /osl_.*Profile.*/
function names in the same list.
Unfortunately, I am seeing some indications that "UDK" relates to UNO.
At the worst, the deprecation just means that other modules are supposed
to access the profile only through UNO, not by including the header file
and calling the functions directly.
Patricia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by Patricia Shanahan <pa...@acm.org>.
On 3/3/2016 5:00 PM, Dennis E. Hamilton wrote:
>> -----Original Message-----
>> From: Patricia Shanahan [mailto:pats@acm.org]
>> Sent: Thursday, March 3, 2016 14:38
>> To: dev@openoffice.apache.org
>> Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning
>> curve)
>>
>> I am seriously considering starting a project to eliminate profile.c
>> etc. and seeing what, if anything, breaks.
>>
>> Before I do that, I have a question about whether it could be accessed
>> through any of OpenOffice's extension or plugin facilities? Even if it
>> can, 14 years seems quite long enough for people to migrate off a
>> deprecated interface.
> [orcmid]
>
> I think the extensions and plugins depend on UNO objects. So long as that is the case, the profile code should be unreachable.
>>
>> Meanwhile, can you tell me how to use BitBucket to look at the original
>> version of the w32 profile code? [ ... ]
> [orcmid]
>
> If you go to a page that we already have a link for, such as
> <https://bitbucket.org/mst/ooo340/src/8b564af029aa60259c0d133d7dc37468ef56e4b5/sal/inc/osl/profile.h>
> You'll see the file path "mouse tracks" at the top of the page just above all the information about multiple heads of the default branch. You can walk back up the tree and down to the page you want [;<).
>
>
>> I am curious about whether it started
>> out with pthread_mutex uses and lost them along the way, or whether that
>> difference between unx and w32 is primordial.
> [orcmid]
>
> You made me look :). Apparently sal/osl/w32/profile.cxx sprang primordially from the earth on 2010-01-29. I have to believe there was an older one, possibly named profile.c but deleted and not shown in the bitbucket.
>
I checked the os2 version. It has profile.c BitBucket history back to
2000, presumably because the file did not get renamed. The 2000 version
does not have pthread_mutex calls.
This leaves a serious mystery, and a far bigger problem than the
original null pointer de-reference. It seems very unlikely to me that it
is right for Profile to do its own synchronization in "unx" systems, but
not for "w32" or "os2". Presumably, whatever the thread safety rules are
for Profile, they should be the same on all the systems to avoid
exporting operating system dependency throughout the application.
I think my next step may be to start a wider investigation of where
pthread functions are called directly.
Patricia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by Patricia Shanahan <pa...@acm.org>.
On 3/3/2016 5:00 PM, Dennis E. Hamilton wrote:
>> -----Original Message----- From: Patricia Shanahan
>> [mailto:pats@acm.org]
...
>> I am curious about whether it started out with pthread_mutex uses
>> and lost them along the way, or whether that difference between unx
>> and w32 is primordial.
> [orcmid]
>
> You made me look :). Apparently sal/osl/w32/profile.cxx sprang
> primordially from the earth on 2010-01-29. I have to believe there
> was an older one, possibly named profile.c but deleted and not shown
> in the bitbucket.
BitBucket does have the original w32 profile.c, and I accidentally found
a way of accessing it. This may be useful for other software archeology
expeditions. It may not be the best or simplest way, just something that
works.
Begin from
https://bitbucket.org/mst/ooo340/src/8b564af029aa60259c0d133d7dc37468ef56e4b5/sal/inc/osl/profile.h
Select the initial import version of profile.h. Now you have BitBucket
thinking back to 2000.
Go up to ooo340/sal, and down again to ooo340/sal/osl/w32. You will now
see the list of w32 file names as they were in 2000, including profile.c
rather than profile.cxx.
The original profile.c includes a log going back to "Revision 1.1
1997/07/17 11:02:31".
Do you read German? Some of the log entries are in German, and I don't
have much faith in machine translation of very short snippets of
technical material.
There are mentions of "locking" but I am reasonably sure that means file
locking rather than pthread_mutex.
Patricia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Thursday, March 3, 2016 14:38
> To: dev@openoffice.apache.org
> Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning
> curve)
>
> I am seriously considering starting a project to eliminate profile.c
> etc. and seeing what, if anything, breaks.
>
> Before I do that, I have a question about whether it could be accessed
> through any of OpenOffice's extension or plugin facilities? Even if it
> can, 14 years seems quite long enough for people to migrate off a
> deprecated interface.
[orcmid]
I think the extensions and plugins depend on UNO objects. So long as that is the case, the profile code should be unreachable.
>
> Meanwhile, can you tell me how to use BitBucket to look at the original
> version of the w32 profile code? [ ... ]
[orcmid]
If you go to a page that we already have a link for, such as
<https://bitbucket.org/mst/ooo340/src/8b564af029aa60259c0d133d7dc37468ef56e4b5/sal/inc/osl/profile.h>
You'll see the file path "mouse tracks" at the top of the page just above all the information about multiple heads of the default branch. You can walk back up the tree and down to the page you want [;<).
> I am curious about whether it started
> out with pthread_mutex uses and lost them along the way, or whether that
> difference between unx and w32 is primordial.
[orcmid]
You made me look :). Apparently sal/osl/w32/profile.cxx sprang primordially from the earth on 2010-01-29. I have to believe there was an older one, possibly named profile.c but deleted and not shown in the bitbucket.
>
> Patricia
>
>
> On 3/3/2016 11:14 AM, Dennis E. Hamilton wrote:
> > Patricia,
> >
> > I went back to BitBucket (thanks Pedro) to see exactly how
> sal/inc/osl/profile.h,
> >
> <https://bitbucket.org/mst/ooo340/src/8b564af029aa60259c0d133d7dc37468ef
> 56e4b5/sal/inc/osl/profile.h>
> > became deprecated: The file had only been touched 8 times before the
> form in the AOO repro was imported. Some of those commits are tied to
> issue-tracker numbers too.
> >
> > The deprecation was introduced in both profile.h and profile.hxx on
> 2002-11-28. There is an associated issue number but it is not in our
> bugzilla.
> >
> > There is still no clue what this was deprecated in favor of.
> >
> > - Dennis, still praying this code isn't actually used.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by Patricia Shanahan <pa...@acm.org>.
I am seriously considering starting a project to eliminate profile.c
etc. and seeing what, if anything, breaks.
Before I do that, I have a question about whether it could be accessed
through any of OpenOffice's extension or plugin facilities? Even if it
can, 14 years seems quite long enough for people to migrate off a
deprecated interface.
Meanwhile, can you tell me how to use BitBucket to look at the original
version of the w32 profile code? I am curious about whether it started
out with pthread_mutex uses and lost them along the way, or whether that
difference between unx and w32 is primordial.
Patricia
On 3/3/2016 11:14 AM, Dennis E. Hamilton wrote:
> Patricia,
>
> I went back to BitBucket (thanks Pedro) to see exactly how sal/inc/osl/profile.h,
> <https://bitbucket.org/mst/ooo340/src/8b564af029aa60259c0d133d7dc37468ef56e4b5/sal/inc/osl/profile.h>
> became deprecated: The file had only been touched 8 times before the form in the AOO repro was imported. Some of those commits are tied to issue-tracker numbers too.
>
> The deprecation was introduced in both profile.h and profile.hxx on 2002-11-28. There is an associated issue number but it is not in our bugzilla.
>
> There is still no clue what this was deprecated in favor of.
>
> - Dennis, still praying this code isn't actually used.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Patricia,
I went back to BitBucket (thanks Pedro) to see exactly how sal/inc/osl/profile.h,
<https://bitbucket.org/mst/ooo340/src/8b564af029aa60259c0d133d7dc37468ef56e4b5/sal/inc/osl/profile.h>
became deprecated: The file had only been touched 8 times before the form in the AOO repro was imported. Some of those commits are tied to issue-tracker numbers too.
The deprecation was introduced in both profile.h and profile.hxx on 2002-11-28. There is an associated issue number but it is not in our bugzilla.
There is still no clue what this was deprecated in favor of.
- Dennis, still praying this code isn't actually used.
The TL;DR:
Here is the forensic scoop,
* 2000-09-08 1.1.1.1 already has a history nicely included at the end of the file by CVS (or RCS), that goes back to Revision 1.1 on 1997-07-17. Locking was apparently added in Revision 1.3 on 1997-12-12. Revision 1.6 on 1998-05-04 fixed a Unix threading problem. Flushing was added earlier in 2000 with something about the option to flush without locking.
The history log in the code file ended when the project converted from CVS to SVN (not Hg right away). [Now you know why I habitually write manual histories into code and files of my own.] That history was removed in subsequent maintenance.
NOTE: The annotations, including typos, are already the same as in the AOO copy profile.h.
* 2002-11-28 #90284# (to mark as deprecated). THIS IS WHERE DEPRECATION WAS INTRODUCED. This bug identifier does not correspond to an issue in the AOO bugzilla, unfortunately, so we do not have the reasoning.
* There is a similar history for the profile.hxx that wraps the profile.h signatures in a class wrapper. This also has introduction of the deprecation warning.
The only use of osl_openProfile is in the Profile constructor and that simply holds onto the returned oslProfile (a void*). The constructor throws an exception if the oslProfile value is NULL.
The only use of osl_closeProfile in the defined Profile class is in the destructor and it has no error checking.
Despite the sane class wrapping, there could potentially be multiple Profile instances constructed on the same ProfileName string. Then thread synchronization could still be needed, assuming osl_openProfile succeeds under those conditions.
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Wednesday, March 2, 2016 11:42
> To: dev@openoffice.apache.org
> Subject: RE: Profile.c bugs (was RE: Some thoughts on the learning
> curve)
>
>
>
> > -----Original Message-----
> > From: Patricia Shanahan [mailto:pats@acm.org]
> > Sent: Wednesday, March 2, 2016 10:25
> > To: dev@openoffice.apache.org
> > Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning
> > curve)
> >
> > Dennis,
> >
> > The build output from my Windows build contains the line:
> >
> > Compiling: sal/osl/w32/profile.cxx
> >
> > There appear to be three different implementations of the profile
> > module, profile.c for "os2", profile.c for "unx", and profile.cxx for
> > "w32". Only the "unx" version has pthread_mutex operations, including
> > our null point de-reference.
> >
> > Patricia@Jan2014Desktop /cygdrive/c/OpenOfficeDev/Trunk/main/sal/osl
> > $ grep -c pthread_mutex */profile.c */profile.cxx
> > os2/profile.c:0
> > unx/profile.c:33
> > w32/profile.cxx:0
> >
> > All three are significantly different. I think I should next try to
> > understand the difference in thread operations between them.
> [orcmid]
>
> I looked at the w32 code and the definition of the profile data
> structure and there is no use of locks whatsoever. The w32 code uses an
> oslProfile-reached structure having no mutex field. I see no lock
> checking on the way into the close function that is of concern to us. I
> trust that means there is no multi-threading that can happen into and
> out of the code on Windows [;<).
>
> In all cases, the opening and creation of the profiles apparently
> produces files somewhere. We should see if we can catch those wherever
> they are supposed to be found.
> >
> > I'll look at SVN logs to see if there is any informative history. Is
> > there any write-up I should be reading on how threading is managed on
> > the different systems?
> [orcmid]
>
> There was some conversation, ending back around 2008, on refactoring or
> stabilizing a threading model. Start here:
> <https://wiki.openoffice.org/wiki/Architecture>.
>
> The code has not been touched outside of comments since import to AOO.
> Based on the annotated file that Pedro called up, the bug is in the unx
> version code from Revision 1.1.1.1 of 2000-09-18, including the mutex in
> the struct and the logic that bothers us.
>
> There is no useful annotation whatsoever.
>
> Let's see if we can find the expected files being created/used in a
> running distribution.
>
> Then we might need to do some grep work to find out where the
> osl/profile.h, oslProfileOption type, oslProfile type, and profile
> operation references are found.
>
>
> > Patricia
> >
> >
> > On 2/29/2016 11:02 AM, Dennis E. Hamilton wrote:
> > > Patricia,
> > >
> > > Take a look at main/sal/inc/osl/profile.h
> > >
> > > Methinks that the code identified in
> > <https://bz.apache.org/ooo/show_bug.cgi?id=126669> might not be built
> > for current releases on Windows or Linux. You'll see that there are
> > filename suffixes such as .rc and .ini used. I doubt that has
> anything
> > to do with handling profiles now.
> > >
> > > Is there a way we can check that the code is not built and/or and
> > these profile functions are not used?
> > >
> > > I don't know about builds for OS/2 and other downstream builds that
> we
> > don't make ourselves.
> > >
> > > And if the code is really obsolete, we should prune it from trunk
> and
> > source releases.
> > >
> > > - Dennis
> [ ... ]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Wednesday, March 2, 2016 10:25
> To: dev@openoffice.apache.org
> Subject: Re: Profile.c bugs (was RE: Some thoughts on the learning
> curve)
>
> Dennis,
>
> The build output from my Windows build contains the line:
>
> Compiling: sal/osl/w32/profile.cxx
>
> There appear to be three different implementations of the profile
> module, profile.c for "os2", profile.c for "unx", and profile.cxx for
> "w32". Only the "unx" version has pthread_mutex operations, including
> our null point de-reference.
>
> Patricia@Jan2014Desktop /cygdrive/c/OpenOfficeDev/Trunk/main/sal/osl
> $ grep -c pthread_mutex */profile.c */profile.cxx
> os2/profile.c:0
> unx/profile.c:33
> w32/profile.cxx:0
>
> All three are significantly different. I think I should next try to
> understand the difference in thread operations between them.
[orcmid]
I looked at the w32 code and the definition of the profile data structure and there is no use of locks whatsoever. The w32 code uses an oslProfile-reached structure having no mutex field. I see no lock checking on the way into the close function that is of concern to us. I trust that means there is no multi-threading that can happen into and out of the code on Windows [;<).
In all cases, the opening and creation of the profiles apparently produces files somewhere. We should see if we can catch those wherever they are supposed to be found.
>
> I'll look at SVN logs to see if there is any informative history. Is
> there any write-up I should be reading on how threading is managed on
> the different systems?
[orcmid]
There was some conversation, ending back around 2008, on refactoring or stabilizing a threading model. Start here: <https://wiki.openoffice.org/wiki/Architecture>.
The code has not been touched outside of comments since import to AOO. Based on the annotated file that Pedro called up, the bug is in the unx version code from Revision 1.1.1.1 of 2000-09-18, including the mutex in the struct and the logic that bothers us.
There is no useful annotation whatsoever.
Let's see if we can find the expected files being created/used in a running distribution.
Then we might need to do some grep work to find out where the osl/profile.h, oslProfileOption type, oslProfile type, and profile operation references are found.
> Patricia
>
>
> On 2/29/2016 11:02 AM, Dennis E. Hamilton wrote:
> > Patricia,
> >
> > Take a look at main/sal/inc/osl/profile.h
> >
> > Methinks that the code identified in
> <https://bz.apache.org/ooo/show_bug.cgi?id=126669> might not be built
> for current releases on Windows or Linux. You'll see that there are
> filename suffixes such as .rc and .ini used. I doubt that has anything
> to do with handling profiles now.
> >
> > Is there a way we can check that the code is not built and/or and
> these profile functions are not used?
> >
> > I don't know about builds for OS/2 and other downstream builds that we
> don't make ourselves.
> >
> > And if the code is really obsolete, we should prune it from trunk and
> source releases.
> >
> > - Dennis
[ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by Patricia Shanahan <pa...@acm.org>.
Dennis,
The build output from my Windows build contains the line:
Compiling: sal/osl/w32/profile.cxx
There appear to be three different implementations of the profile
module, profile.c for "os2", profile.c for "unx", and profile.cxx for
"w32". Only the "unx" version has pthread_mutex operations, including
our null point de-reference.
Patricia@Jan2014Desktop /cygdrive/c/OpenOfficeDev/Trunk/main/sal/osl
$ grep -c pthread_mutex */profile.c */profile.cxx
os2/profile.c:0
unx/profile.c:33
w32/profile.cxx:0
All three are significantly different. I think I should next try to
understand the difference in thread operations between them.
I'll look at SVN logs to see if there is any informative history. Is
there any write-up I should be reading on how threading is managed on
the different systems?
Patricia
On 2/29/2016 11:02 AM, Dennis E. Hamilton wrote:
> Patricia,
>
> Take a look at main/sal/inc/osl/profile.h
>
> Methinks that the code identified in <https://bz.apache.org/ooo/show_bug.cgi?id=126669> might not be built for current releases on Windows or Linux. You'll see that there are filename suffixes such as .rc and .ini used. I doubt that has anything to do with handling profiles now.
>
> Is there a way we can check that the code is not built and/or and these profile functions are not used?
>
> I don't know about builds for OS/2 and other downstream builds that we don't make ourselves.
>
> And if the code is really obsolete, we should prune it from trunk and source releases.
>
> - Dennis
>
>> -----Original Message-----
>> From: Patricia Shanahan [mailto:pats@acm.org]
>> Sent: Saturday, February 20, 2016 20:57
>> To: dev@openoffice.apache.org
>> Subject: Re: Some thoughts on the learning curve
>>
>>
>>
>> On 2/20/2016 8:39 PM, Dennis E. Hamilton wrote:
>>> I sympathize with Pedro's observation.
>>>
>>> Meanwhile, although I am not an expert, I could stand to buddy up on
>>> the following profile-related situation:
>>> <https://bz.apache.org/ooo/show_bug.cgi?id=126669>.
>>
>> Looks interesting. I am familiar with pthread and memory management
>> issues, so it may be a good area for me to work on.
>>
>> Patricia
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Profile.c bugs (was RE: Some thoughts on the learning curve)
Posted by Patricia Shanahan <pa...@acm.org>.
I'll take a look at the results of my Windows build. It should be
relatively easy to see if they are built at all. Built but not used is a
bit harder, and may take some experiments.
On 2/29/2016 11:02 AM, Dennis E. Hamilton wrote:
> Patricia,
>
> Take a look at main/sal/inc/osl/profile.h
>
> Methinks that the code identified in
> <https://bz.apache.org/ooo/show_bug.cgi?id=126669> might not be built
> for current releases on Windows or Linux. You'll see that there are
> filename suffixes such as .rc and .ini used. I doubt that has
> anything to do with handling profiles now.
>
> Is there a way we can check that the code is not built and/or and
> these profile functions are not used?
>
> I don't know about builds for OS/2 and other downstream builds that
> we don't make ourselves.
>
> And if the code is really obsolete, we should prune it from trunk and
> source releases.
>
> - Dennis
>
>> -----Original Message----- From: Patricia Shanahan
>> [mailto:pats@acm.org] Sent: Saturday, February 20, 2016 20:57 To:
>> dev@openoffice.apache.org Subject: Re: Some thoughts on the
>> learning curve
>>
>>
>>
>> On 2/20/2016 8:39 PM, Dennis E. Hamilton wrote:
>>> I sympathize with Pedro's observation.
>>>
>>> Meanwhile, although I am not an expert, I could stand to buddy up
>>> on the following profile-related situation:
>>> <https://bz.apache.org/ooo/show_bug.cgi?id=126669>.
>>
>> Looks interesting. I am familiar with pthread and memory
>> management issues, so it may be a good area for me to work on.
>>
>> Patricia
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org