openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Profile.c bugs (was RE: Some thoughts on the learning curve)
Date Wed, 02 Mar 2016 19:42:24 GMT

> -----Original Message-----
> From: Patricia Shanahan []
> Sent: Wednesday, March 2, 2016 10:25
> To:
> 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.

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?

There was some conversation, ending back around 2008, on refactoring or stabilizing a threading
model.  Start here: <>.

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 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
> <> 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:
For additional commands, e-mail:

View raw message