Bug 82326 - FILESAVE: osl::Thread::create failed when saving 32-bit Calc file with conditional formatting open for at while
Summary: FILESAVE: osl::Thread::create failed when saving 32-bit Calc file with condit...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: x86 (IA32) Windows (All)
: high critical
Assignee: fvroman
QA Contact:
URL:
Whiteboard: target:5.4.0 target:5.3.4
Keywords: haveBacktrace
Depends on:
Blocks: Conditional-Formatting
  Show dependency treegraph
 
Reported: 2014-08-08 04:37 UTC by cbent3
Modified: 2017-07-17 09:35 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
A set of sheets containing rows of data for several mutual fund-like financial instruments. Contains daily price, max and min values, plus some conditional formatting. (2.52 MB, application/vnd.oasis.opendocument.spreadsheet)
2014-08-08 04:37 UTC, cbent3
Details
screen capture (3.05 KB, image/png)
2015-02-16 18:11 UTC, PISSOTTE
Details
Backtrace from Libo 4.4 (12.07 KB, text/plain)
2015-02-22 14:07 UTC, Buovjaga
Details
Backtraces from Libo 4.4.3 (9.15 KB, application/zip)
2015-10-14 21:50 UTC, graffity2199
Details
Backtraces from Libo Dev_5.1.0.0.alpha1 2015-10-21_16.55.13 (5.87 KB, text/plain)
2015-10-27 21:14 UTC, graffity2199
Details
Backtraces from Libo Dev_5.1.0.0.alpha1 (29.62 KB, text/plain)
2015-10-28 16:58 UTC, Timur
Details
A set of files created with LO 4.4.3 and the instructions how to reproduce the bug (6.80 MB, application/zip)
2015-11-07 22:28 UTC, graffity2199
Details

Note You need to log in before you can comment on or make changes to this bug.
Description cbent3 2014-08-08 04:37:23 UTC
Created attachment 104253 [details]
A set of sheets containing rows of data for several mutual fund-like financial instruments. Contains daily price, max and min values, plus some conditional formatting.

I've run into this problem since the 4.2.3 releases running Windows Vista 32-bit.

I have a Calc spreadsheet to which I add one row per day. After opening the spreadsheet and leaving it open for a period of time (at least 30 minutes) it will crash with the "osl::Thread::create failed" dialog appearing.  Sometimes I can recover the file immediately and other times I must reboot the computer in order to recover the file.

I've tried using a new user profile, performed a clean uninstall and reinstall of LibreOffice, and still have this issue.
Comment 1 Joel Madero 2014-08-08 04:43:40 UTC
So you literally just open this file and let it sit for 30 minutes and then it crashes?
Comment 2 cbent3 2014-08-08 04:47:34 UTC
No. It's often 30 minutes or longer before I get around to making edits on the file. I'll save my edits but I'll see the failed dialog either at the end of the save or when I close the file.
Comment 3 raal 2014-08-24 11:30:01 UTC
Hello,
Tested on win 7 , Version: 4.3.0.4
ID sestavení: 62ad5818884a2fc2e5780dd45466868d41009ec0
 
I can not reproduce the bug.
I tried following steps:
fill 1 row in sheet TSP
save
wait 50 min (file is open)
fill 1 row in sheet TSP
save
fill 1 row in other sheets 
save
wait 30 min
close file

No crash nor failed dialog appears.
Thank you
Comment 4 cbent3 2014-09-05 03:44:47 UTC Comment hidden (obsolete)
Comment 5 cbent3 2014-09-05 03:50:21 UTC
(In reply to comment #4)
> The "osl::Thread::create failed" failed message error continues with LO
> 4.1.3.2, often upon opening the file for the first time.
> 
> Notes from watching Windows Task Manager (Vista SP2 32-bit)...
> 
> With one 264 KB spreadsheet open soffice.bin is using around 60,000K Memory
> (Private Working Set) and the amount used is stable.
> 
> When opening only the TSP.ods spreadsheet (size now 2,525 KB) soffice.bin
> uses over 240,000K of memory and the amount rapidly climbs to over 450,000K
> (sometimes I can sample values above 480,000K) in the first 15-20 seconds,
> then shrinks to around 210,000K before the error dialog appears.

My system is an aging Dell Studio 1535 laptop with 4 GB RAM.
Comment 6 Joel Madero 2014-09-05 05:33:30 UTC
Version is the oldest version that shows the problem - not the newest. Reverting update.
Comment 7 cbent3 2014-09-05 19:00:56 UTC Comment hidden (obsolete)
Comment 8 cbent3 2014-09-05 19:03:12 UTC Comment hidden (obsolete)
Comment 9 PISSOTTE 2015-02-16 18:11:59 UTC Comment hidden (obsolete)
Comment 10 Joel Madero 2015-02-16 18:52:25 UTC
I can open the attached file fine.
Ubuntu 14.10
LibreOffice 4.4.0.3 release
Comment 11 PISSOTTE 2015-02-16 18:54:35 UTC
(In reply to PISSOTTE from comment #9)
> Created attachment 113436 [details]
> screen capture
> 
> cant open a spreadsheet file whith several tabs one of them is big.
> very annoying i need to do some work this this file.
> any workarround to use or convert the file?

same probleme with LibreOffice_4.4.1.1_Win_x86

i reverted to LibreOffice_4.3.5_Win_x86
who works

also 4.4 selecting a range with mouse is unusable.
Comment 12 Buovjaga 2015-02-22 14:07:20 UTC
Created attachment 113603 [details]
Backtrace from Libo 4.4

(In reply to PISSOTTE from comment #9)
> Created attachment 113436 [details]
> screen capture
> 
> cant open a spreadsheet file whith several tabs one of them is big.
> very annoying i need to do some work this this file.
> any workarround to use or convert the file?

Reproduced crash in 4.4 when opening attachment 104253 [details].
Had to use procdump and then analyze the dump file.

4.5 did not complete the opening of the file - it stayed at approximately 90%.

Win 7 Pro 64-bit, LibO Version: 4.4.0.3
Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7
Locale: fi_FI

Version: 4.5.0.0.alpha0+
Build ID: b13534de022972131b46f93f5ada90af155eec9e
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-02-19_00:21:37
Locale: fi_FI
Comment 13 graffity2199 2015-10-11 19:16:57 UTC
Hello,

I would like to vote and help to solve this bug as I can easily reproduce it and it is quite annoying for me.

For the moment, I have reproduced it on two configurations with the same .ods files :

- Windows 7 32 bits 4 Go RAM with LibreOffice 4.4.3.2, 4.4.5 and 5.0.2
- Windows 7 64 bits 4 Go RAM with LibreOffice 4.4.3.2

The problem doesn't seem to appear with the following configuration : Intel Core 2 duo 6700 Linux Ubuntu 14.04 LTS 32 bits 4 Go RAM with LibreOffice 4.2.8.2 Build ID 420m0 (Build:2)

I could also test other configurations if it can help (I'll try to do it with more RAM).

How can I reproduce it ?
My ods files are quite big and lots of formulas need other files like a tree view.
The problem appears when I opened too many files or when it recalculates formulas with too many files opened.

The same scenario on all configurations I've tested raises the problem :
Step 1 : I open the root ods file (1,3 Mo)
Step 2 : I open the second ods file (2,9 Mo)
Step 3 : I open the third ods file (159 Ko)
Step 4 : I open the fourth ods file (116 Ko)
Step 5 : I open the fith ods file (115 Ko)
Step 6 : I open the sixth ods file (113 Ko)
Step 7 : I open the seventh ods file (113 Ko)
Step 8 : I open the eighth ods file (110 Ko)
Step 9 : I open the nineth ods file (187 Ko)
Step 10 : I open the tenth ods file (200 Ko)
Step 11 : I open the eleventh ods file (186 Ko)
Step 12 : I open the twelfth ods file (187 Ko)
Step 13 : I open the thirteenth ods file (188 Ko)
Step 14 : I open the fourteenth ods file (196 Ko)
Step 15 : I open the fifteenth ods file (195 Ko)
Step 16 : I open the sixteenth ods file (196 Ko)
Step 17 : I open the seventeenth ods file (198 Ko)
Step 18 : I open the eighteenth ods file (191 Ko)
Step 19 : I open the nineteenth ods file (190 Ko)
Step 20 : I open the twentieth ods file (194 Ko)
Step 21 : I open the twenty-first ods file (194 Ko)
Step 22 : I open the twenty-second ods file (192 Ko)
Step 23 : I open the twenty-third ods file (189 Ko)
Step 24 : I go back on the second file and I press F9 for recalculation.

I precise that no other processes are running and that the used memory doesn't reach the system limit (between 1,4 Go and 1,6 Go used by LibreOffice).
I also tried to remove all LibreOffice extensions without any success.
Following the configuration, it may crash before the step 24.

I can't add the files as attachment due to confidentiality and anonymization problems (they are my production files).
I would like to get logs / or backtrace but I don't know to do it... could you tell me ?

Thanks a lot.
Comment 14 Joel Madero 2015-10-11 21:08:25 UTC
I'm not sure what you mean by "vote" to solve the problem - we do not do voting or democratic process for volunteers fixing issues.

As for the backtrace - seems like we already have one so that's not really needed at this point.

Attaching additional documents may help but it seems to me like we have everything in this bug that a non-developer can offer - at this point it's just waiting for a developer to volunteer to fix it, which again, does not rely on "voting" at all. 

Testing older releases might help to find out if this is a regression - if you could try them and if it's a regression let us know what version it worked in, that would be great.
http://downloadarchive.documentfoundation.org/libreoffice/old/
Comment 15 graffity2199 2015-10-14 21:50:20 UTC
Created attachment 119624 [details]
Backtraces from Libo 4.4.3

I've tried to test other configurations :
- Windows 32 bits 4Go RAM LibreOffice 4.2.8.2, 4.3.0.4, 4.3.7.2 => crashes when opening the second or third file (the crash is severe because it is the Windows popup or the recovery popup which is displayed, I'm not sure if the file format and the features I use are supported by these versions)

- Windows 32 bits 4Go RAM LibreOffice 4.4.0.3, 4.4.1.2 => problem reproduced with around 18 files opened

- Windows 64 bits 8 Go RAM LibreOffice 4.4.3.2 => problem reproduced with 24 files opened

I attached backtraces I could get following the [https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg] guide, I'm not sure they can help as it was not always the same crash...

I would like to test the latest daily build under [http://dev-builds.libreoffice.org/daily/master/Win-x86@62-merge-TDF], at last I will try to anonymize my files and join them to the bug report.
Comment 16 graffity2199 2015-10-27 21:14:37 UTC
Created attachment 120017 [details]
Backtraces from Libo Dev_5.1.0.0.alpha1 2015-10-21_16.55.13

"osl::Thread::create failed" crash reproduced with the latest Libre Office Dev_5.1.0.0.alpha1 2015-10-21_16.55.13 version.

I've attached a backtrace generated with procdump.
Comment 17 Timur 2015-10-28 16:58:32 UTC Comment hidden (obsolete)
Comment 18 graffity2199 2015-11-07 22:28:31 UTC
Created attachment 120371 [details]
A set of files created with LO 4.4.3 and the instructions how to reproduce the bug

At last, I've created a set of test files (created with LO 4.4.3.2) to reproduce the "osl::Thread::create failed" bug.

I've also added the instructions in the README.txt file to reproduce the bug as we need to open around 35 files, which raises the RAM up to 1,5 Go.

It is not the fastest way to reproduce it but it crashes (with my production files I also need to open around 20 files).

Thanks a lot.
Comment 19 Gaétan RYCKEBOER 2016-05-18 09:07:38 UTC
It seems that 1.5GiB is the max size of a LibreOffice app (calc or draw) under windows 7 or 8 before raising an osl::Thread::create exception.

The question would be "why are there so much memory allocated for LO Calc".

See bug 99763 opened for Draw, which has a memory leak. You would notice the same memory roof of 1.5GiB
Comment 20 Timur 2016-05-18 09:37:36 UTC
Should valgrind be required and helpful here? There should be wantValgrind keyword anyway.
Comment 21 fvroman 2017-05-10 10:32:10 UTC
The code to build and compute formulas is using an fixed size array. The size of this array has been changed from 512 to 8192 by commit 9c1ca6dca3b553c302a635357e33591605343b99 

This kind of allocation is consuming a LOT of memory while opening scalc files which are making extensive use of formula. 

This is a silent issue when working with a 64bits versions of LO because the memory is immediately released at the end of the load phase. However, with 32bits versions, some files can not be loaded anymore as it can consume the full process memory space (2GB on windows).
Comment 22 Commit Notification 2017-05-15 12:00:02 UTC
frederic vroman committed a patch related to this issue.
It has been pushed to "master":

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

tdf#82326 calc 32bits unable to open files with a lot of cond formatting

It will be available in 5.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 23 Commit Notification 2017-05-15 15:15:55 UTC
frederic vroman committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4366a6bcc175886680ff1b727207ed1ae4f97ce9&h=libreoffice-5-3

tdf#82326 calc 32bits unable to open files with a lot of cond formatting

It will be available in 5.3.4.

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 24 Xisco Faulí 2017-07-14 13:23:23 UTC
Polite ping: is this bug fixed? if so, please close it as RESOLVED FIXED
Comment 25 fvroman 2017-07-17 05:54:24 UTC
Not reproductible with LO 5.3.4 (32bits)