Bug 38835 - strip out non-trivial globals before main
Summary: strip out non-trivial globals before main
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.0
Keywords: difficultyMedium, easyHack, skillCpp, topicCleanup
Depends on:
Blocks:
 
Reported: 2011-06-30 09:18 UTC by Björn Michaelsen
Modified: 2020-05-18 06:42 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Björn Michaelsen 2011-06-30 09:18:06 UTC
strip out non-trivial globals before main

Background: Ordering and running constructors at startup consumes CPU time. Anything larger than a simple string should be switched to use the singleton pattern in 'sal' for this case. Any variable marked 'static' is potentially a problem.

Skills: build, simple C++
Comment 1 Gregory Ngirmang 2012-01-14 13:49:01 UTC
Hi, I'd like to do this. Can you point me where exactly is the singleton pattern you use and which entry point (main) I should look at?
Comment 2 David Tardon 2012-01-16 01:15:58 UTC
Look at the various StaticWhatever templates in sal/inc/rtl/instance.hxx . It is easy to find examples of their use throughout the code, but some really simple are in sal/rtl/source/alloc_fini.cxx .
Comment 3 Florian Reisinger 2012-05-18 08:58:42 UTC
Deteted "Easyhack" from summary
Comment 4 Björn Michaelsen 2013-10-04 18:47:21 UTC
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 5 Gregory Ngirmang 2014-02-22 03:05:35 UTC
Hi ;) It's been a while. I'm starting to have free time again, so I've been poking around trying to find any globals that I can see as causing this issue.

"Any variable marked 'static'" might not really be an issue save that they are global for only globals are constructed at startup but static locals are constructed when the declaration is first passed over.[1]

[1] http://stackoverflow.com/questions/55510/when-do-function-level-static-variables-get-allocated-initialized
Comment 6 Jan Holesovsky 2014-02-27 12:54:37 UTC
Let me add some more information to this Easy Hack, as it would be really quite useful to improve the situation :-)

The simplest way to find global statics is like:

git grep '^static[^(]*$' -- "*.cxx"

and look after those that define a global variable of a more complex type (ie. skip the OUStrings / bools / ints for now).

Then as the first thing, try to make it non-global if it is possible, like here:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=92bede3900e84d4f08efb81757ec95c518c7fa76

because that way this will get initialized when used for the first time.  If that is not possible, or not practical, then you can do what is suggested in the initial comment.  An example can be seen in this commit:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=020e29fb95d742b160feab1df6751e59d4108239

Hope that helps :-)
Comment 7 Jan Holesovsky 2014-02-27 13:00:52 UTC
git grep '^static[^(]*=.*$' -- "*.cxx" | grep -v '\<\(bool\|sal_Bool\|OUString\|char\|int\|short\|long\|double\|sal_Int[0-9]*\|sal_uInt[0-9]*\|sal_Char\|sal_Unicode\)\>' | less

filters out most of the trivial cases...
Comment 8 Caolán McNamara 2014-02-27 20:38:02 UTC
Another approach is to start soffice.bin under gdb and point a breakpoint on __do_global_ctors_aux (I think, something of that nature) and see what gets called during startup.

Here are some other resources that might be useful

http://neugierig.org/software/chromium/notes/2011/08/static-initializers.html

http://stackoverflow.com/questions/335369/finding-c-static-initialization-order-problems
Comment 9 Stephan Bergmann 2014-02-28 08:53:49 UTC
(In reply to comment #6)
> Then as the first thing, try to make it non-global if it is possible, like
> here:
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=92bede3900e84d4f08efb81757ec95c518c7fa76
> 
> because that way this will get initialized when used for the first time.  If
> that is not possible, or not practical, then you can do what is suggested in
> the initial comment.  An example can be seen in this commit:

Note that initialization of local static variables is not thread-safe in C++03, so the above can only be used for cases where the local static variable ends up in code that is synchronized.  Other cases need to use the rtl/instance.hxx idioms.
Comment 10 Lynn 2014-05-09 16:54:20 UTC
Hi, since this one isn't assigned to anyone, can I try to work on this bug?
Comment 11 David Tardon 2014-05-10 05:45:06 UTC
(In reply to comment #10)
> Hi, since this one isn't assigned to anyone, can I try to work on this bug?

Sure you can.
Comment 12 Lynn 2014-05-13 17:00:08 UTC
Do I need to worry about synchronization between multiple threads when I try to create the singleton at the same time?

I don't think I need to do the same for arrays right?
Comment 13 Stephan Bergmann 2014-05-13 17:25:39 UTC
(In reply to comment #12)
> Do I need to worry about synchronization between multiple threads when I try
> to create the singleton at the same time?

Yes, see comment 9.

> I don't think I need to do the same for arrays right?

The destinction wouldn't be so much between array vs. scalar, but whether or not it requires initialization at runtime.
Comment 14 Commit Notification 2014-11-05 06:45:56 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=705c48d32eec0aa5180e60ca157daca4b154e4a3

fdo#38835 strip out OUString globals

It will be available in 4.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 15 Commit Notification 2014-12-05 09:35:58 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0375504f7be34d857859dfbaa312501e0eaaaad1

fdo#38835 strip out OString globals

It will be available in 4.5.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 16 Commit Notification 2014-12-05 13:09:02 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=86b44e8e78716fbfc1783d692debcbb201fb9bd4

fdo#38835 strip out OUString globals

It will be available in 4.5.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 17 Commit Notification 2014-12-08 12:14:46 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2979ff295c9fafdb92cb56cd1f5ddb0a6b56cf20

fdo#38835 strip out OUString globals

It will be available in 4.5.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 18 Karthick Prasad Gunasekaran 2015-03-09 23:54:21 UTC
Has patch been submitted for this problem or can i work around for it?
Comment 19 Shubham Khara 2015-09-03 05:30:32 UTC
Hello everyone, this would be my first easyhack as well as first step in Open Source, I have builded LibreOffice, I would like to start contributing now.
Comment 20 Robinson Tryon (qubit) 2015-12-14 06:34:49 UTC Comment hidden (obsolete)
Comment 21 Björn Michaelsen 2016-02-03 11:22:52 UTC
Note that constants (currently either #defines or "static const ..." can -- with C++11 -- be turned into constexprs:

 http://en.cppreference.com/w/cpp/language/constexpr

which should be generally preferable.
Comment 22 Stephan Bergmann 2016-02-03 17:31:36 UTC
(In reply to Björn Michaelsen from comment #21)
> Note that constants (currently either #defines or "static const ..." can --
> with C++11 -- be turned into constexprs:
> 
>  http://en.cppreference.com/w/cpp/language/constexpr
> 
> which should be generally preferable.

...but isn't available in MSVC 2013 (and reportedly only partially in MSVC 2015, aka MSVC 14, <http://en.cppreference.com/w/cpp/compiler_support>).  That's why SAL_CONSTEXPR (include/sal/types.h), and can only use it in ways that do not /require/ it to expand to "constexpr".
Comment 23 Robinson Tryon (qubit) 2016-02-18 14:51:44 UTC Comment hidden (obsolete)
Comment 24 jani 2016-04-18 07:38:38 UTC
A polite ping, still working on this issue?
Comment 25 Commit Notification 2016-09-27 06:56:34 UTC
Rosen committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b7dfa4d6625d066f5507420089434cb7ac29c968

tdf#38835 - strip out non-trivial globals before main

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 26 jani 2016-10-08 10:11:30 UTC
Is this easy hack still valid ?
Comment 27 Shinnok 2017-08-28 08:17:05 UTC
A polite ping, still working on this issue?
Comment 28 Xisco Faulí 2017-10-28 02:35:24 UTC Comment hidden (obsolete)
Comment 29 Xisco Faulí 2017-12-07 10:48:22 UTC
A polite ping, still working on this bug?
Comment 30 Xisco Faulí 2018-01-07 03:29:37 UTC
A polite ping, still working on this bug?
Comment 31 Xisco Faulí 2018-02-07 03:31:54 UTC Comment hidden (obsolete)
Comment 32 Xisco Faulí 2018-03-10 03:43:29 UTC Comment hidden (obsolete)
Comment 33 Xisco Faulí 2018-04-10 02:30:10 UTC Comment hidden (obsolete)
Comment 34 Xisco Faulí 2018-05-11 02:30:37 UTC Comment hidden (obsolete)
Comment 35 Xisco Faulí 2018-06-11 02:32:40 UTC Comment hidden (obsolete)
Comment 36 Xisco Faulí 2018-07-12 02:42:03 UTC Comment hidden (obsolete)
Comment 37 Xisco Faulí 2018-08-12 02:33:41 UTC Comment hidden (obsolete)
Comment 38 Xisco Faulí 2018-09-12 02:35:39 UTC Comment hidden (obsolete)
Comment 39 Xisco Faulí 2018-10-13 03:12:14 UTC Comment hidden (obsolete)
Comment 40 Xisco Faulí 2018-11-13 03:40:00 UTC Comment hidden (obsolete)
Comment 41 Xisco Faulí 2018-12-14 03:54:05 UTC Comment hidden (obsolete)
Comment 42 Xisco Faulí 2019-01-14 03:50:09 UTC Comment hidden (obsolete)
Comment 43 Xisco Faulí 2019-02-14 03:47:12 UTC Comment hidden (obsolete)
Comment 44 Xisco Faulí 2019-03-17 03:49:52 UTC Comment hidden (obsolete)
Comment 45 Xisco Faulí 2019-06-26 09:51:35 UTC
Dear Gayan Thejawansha,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
Comment 46 Abhishek 2020-01-27 13:02:51 UTC
Hi there, Since this bug wasn't assigned to anyone I would like to work on this. I read all the comments about the development of this bug. But some comments were hidden, so I would like know about the recent development.
Comment 47 Buovjaga 2020-01-28 22:51:52 UTC
(In reply to Abhishek from comment #46)
> Hi there, Since this bug wasn't assigned to anyone I would like to work on
> this. I read all the comments about the development of this bug. But some
> comments were hidden, so I would like know about the recent development.

Yes, please work on it. The status does not have to be changed, because multiple people can work on it at the same time.

You can unhide comments by clicking on the [+] link, but there is nothing of value in them here.

Do read all the visible comments, but note that we are able to use the vast majority of C++17 features at this point.
Comment 48 Hrithik Raj 2020-02-23 17:38:32 UTC
Hi there this is Hrithik Raj And i would like to fix this bug.I have assiged it to me.
What to do next?
Comment 49 Buovjaga 2020-02-23 17:49:01 UTC
(In reply to Hrithik Raj from comment #48)
> Hi there this is Hrithik Raj And i would like to fix this bug.I have assiged
> it to me.
> What to do next?

Please don't change the assignee field. I have now had to change it back twice. See my comment 47.

If you have questions, please be more specific. We assume you have read the description and looked at previous code changes related to this easy hack. Thus, "what to do next" is not an appropriate question to start with.
Comment 50 Hrithik Raj 2020-02-23 19:25:13 UTC
(In reply to Buovjaga from comment #49)
> (In reply to Hrithik Raj from comment #48)
> > Hi there this is Hrithik Raj And i would like to fix this bug.I have assiged
> > it to me.
> > What to do next?
> 
> Please don't change the assignee field. I have now had to change it back
> twice. See my comment 47.
> 
> If you have questions, please be more specific. We assume you have read the
> description and looked at previous code changes related to this easy hack.
> Thus, "what to do next" is not an appropriate question to start with.

Apologies. I am new to open source.Can you tell me where is the code where i have to look for this bug. I can see a directory in comment 2 .
Comment 51 Buovjaga 2020-02-24 06:51:35 UTC
(In reply to Hrithik Raj from comment #50)
> Apologies. I am new to open source.Can you tell me where is the code where i
> have to look for this bug. I can see a directory in comment 2 .

Please read *all* of the comments and not just up to comment 2.
Comment 52 ibarkleyyeung 2020-05-03 01:00:06 UTC
Quick question, is comment 9 still valid?

That is, is LibreOffice still supposed to be compatible with C++03? I don't know what the minimum C++ version is across the various compilers. Is the C++ version documented somewhere? 

I see uses of unique_ptr and unordered_map, so I'm assuming at least C++11. And C++11 ensures function-local statics are initialized exactly once even if multiple threads call the function. 

Just checking before I make a change.
Comment 53 Buovjaga 2020-05-03 06:24:15 UTC
(In reply to ibarkleyyeung from comment #52)
> Quick question, is comment 9 still valid?
> 
> That is, is LibreOffice still supposed to be compatible with C++03? I don't
> know what the minimum C++ version is across the various compilers. Is the
> C++ version documented somewhere? 
> 
> I see uses of unique_ptr and unordered_map, so I'm assuming at least C++11.
> And C++11 ensures function-local statics are initialized exactly once even
> if multiple threads call the function. 
> 
> Just checking before I make a change.

Please refer to the compiler baseline: https://git.libreoffice.org/core/+/master/README.md
Cross-check it with https://en.cppreference.com/w/cpp/compiler_support
LibreOffice can use the vast majority of features in C++17 and its standard library.
Comment 54 Stephan Bergmann 2020-05-03 09:15:31 UTC
(In reply to Buovjaga from comment #53)
> (In reply to ibarkleyyeung from comment #52)
> > Quick question, is comment 9 still valid?
> > 
> > That is, is LibreOffice still supposed to be compatible with C++03? I don't
> > know what the minimum C++ version is across the various compilers. Is the
> > C++ version documented somewhere? 
> > 
> > I see uses of unique_ptr and unordered_map, so I'm assuming at least C++11.
> > And C++11 ensures function-local statics are initialized exactly once even
> > if multiple threads call the function. 
> > 
> > Just checking before I make a change.
> 
> Please refer to the compiler baseline:
> https://git.libreoffice.org/core/+/master/README.md
> Cross-check it with https://en.cppreference.com/w/cpp/compiler_support
> LibreOffice can use the vast majority of features in C++17 and its standard
> library.

...and comment 9 is indeed obsolete since <https://git.libreoffice.org/core/+/6517fd2107a5a71290afad8850da0eab51519bc6%5E!> "HAVE_THREADSAFE_STATICS sould always be true"
Comment 55 Commit Notification 2020-05-11 12:43:23 UTC
Ian Barkley-Yeung committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4ee314959a377031a382b6ba42c6b5d5a0c0a367

tdf#38835: strip out non-trivial globals before main

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 56 Commit Notification 2020-05-12 08:53:18 UTC
Mesut Çifci committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/902e69d1a5473155915522d49f730720797a384f

tdf#38835 strip out OUString globals

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 57 Noel Grandin 2020-05-12 09:06:57 UTC
This has been pretty well covered by now, I think we can close it
Comment 58 Commit Notification 2020-05-18 06:42:34 UTC
Mesut Çifci committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/34b3d1342579791d960d8bc77aa937ead49bd791

tdf38835 Avoid pointless globals

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.