openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: Profile.c bugs (was RE: Some thoughts on the learning curve)
Date Thu, 03 Mar 2016 19:14:34 GMT
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


Mime
View raw message