Description: after marking at least three complete rows (even in an empty, virgin calc sheet), trying to copy them to the clipboard with CTRL-C makes Calc crash reproducibly. Steps to Reproduce: 1. open new calc sheet (CTRL+N) 2. click and drag on row headers to mark at least three complete rows 3. press CTRL+C Actual Results: CALC crashes reproducibly Expected Results: selection copied to clipboard without crash Reproducible: Always User Profile Reset: No Additional Info: System here is DELL Workstation, SSD, 16 GB RAM, nvidia Quadro K2200 (driver 21.21.13.7563; 1920x1200@32bit), Win 7 Pro 64-bit LibreOffice Info: Version: 5.3.3.2 (x64) Build-ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448 CPU-Threads: 12; BS-Version: Windows 6.1; UI-Render: GL; Layout-Engine: neu; Gebietsschema: de-DE (de_DE); Calc: group Crash report available here: http://crashreport.libreoffice.org/stats/crash_details/cb3385bf-94ed-4bba-b639-a75576ab4d89 This bug might be related to a similar one: 105491 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0
I can't reproduce it in Versión: 5.3.3.2 Id. de compilación: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448 Subproc. CPU: 1; SO: Windows 6.1; Repr. de IU: predet.; Motor de trazado: HarfBuzz; Configuración regional: es-ES (es_ES); Calc: group nor Version: 5.5.0.0.alpha0+ Build ID: 36b1e6270bf2fbb333e2a69c4bb5931eba418289 CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-29_14:06:19 Locale: es-ES (es_ES); Calc: group
I can't reproduce it in Version: 5.5.0.0.alpha0+ Build ID: 066665644b398a882e6cded98af5bb060af41d76 CPU threads: 2; OS: Linux 4.9; UI render: default; VCL: kde4; TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:master, Time: 2017-06-01_01:43:55 Locale: nl-BE (en_US.UTF-8); Calc: group Version: 5.4.0.0.beta1 Build ID: 8672113ead4e403c55e31b1d9a3d1e0f3b299577 CPU threads: 2; OS: Linux 4.9; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group Version: 5.3.3.2 Build ID: SlackBuild for 5.3.3 by Eric Hameleers CPU Threads: 2; OS Version: Linux 4.9; UI Render: default; VCL: kde4; Layout Engine: new; Locale: en-US (en_US.UTF-8); Calc: group
To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
Confirming that LibO keeps running after closing and or crashes with Version: 5.5.0.0.alpha0+ Build ID: 076ed447f694239d5c67adee528ea6e471d909ff CPU threads: 4; OS: Windows 6.19; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2017-06-09_23:54:20 Locale: nl-NL (nl_NL); Calc: CL and with Versie: 5.4.0.0.beta1 Build ID: 8672113ead4e403c55e31b1d9a3d1e0f3b299577 CPU-threads: 4; Besturingssysteem:Windows 6.2; UI-render: GL; Locale: nl-NL (nl_NL); Calc: CL Crash report differs a bit: http://crashreport.libreoffice.org/stats/crash_details/adf24e23-a687-4f93-a5d9-fa8af5fe220c Steps to Reproduce: 1. Enable OpenGL 2. Open new calc sheet (CTRL+N) 3. Click and drag on row headers to mark at least three complete rows 4. Press CTRL+C 5. Close LibO (Click Red Cross right top) 6. LibO Keeps running in the background
"keeps running" is contrary to "crashes" ...
Created attachment 134521 [details] WinDbg stacktrace of manual minidump while hung Confirming with STR of comment 4 WinDbg stack trace of manual dump of running soffice.bin attached. Crash report on manual kill and relaunch as linked below. Look to have the clipboard being held open while closing the session. =-testing-= Version: 5.4.0.1 (x64) Build ID: 962a9c4e2f56d1dbdd354b1becda28edd471f4f2 CPU threads: 8; OS: Windows 6.19; UI render: GL; Locale: en-US (en_US); Calc: CL http://crashreport.libreoffice.org/stats/crash_details/97eb2e10-a189-47a7-a8b7-1f35c57faa31
Humm.. that somehow looks like a dead lock or another endless wait condition, see threads 8 and 31 with sal3!osl_waitCondition(...) Specifically in thread 8 that came from vcl\source\opengl\openglhelper.cxx @ 842 which somewhat confirms the OpenGL relation.
*** Bug 106997 has been marked as a duplicate of this bug. ***
Since nobody confirmed Comment 0, I'll change the title to Comment 4. Crash report as reporter's http://crashreport.libreoffice.org/stats/signature/BitmapReadAccess::GetPixelForN32BitTcRgba%28unsigned%20char%20const%20*,long,ColorMask%20const%20&%29. There are 9788 (!) Windows reports, mostly 5.3, but I confirm same with 6.0+. No repro with 5.2.0, repro with 5.3.0 beta1. I'll mark regression.
The hung soffice.bin does not occur using STR from comment 4 when OpenGL is disabled. Adding the bug 93529 meta.
*** Bug 109088 has been marked as a duplicate of this bug. ***
I can't bibisect this, because GL crashes for me in early 5.3 builds. This is the oldest bad commit before I gave up, from 2016-06-10: a7ce813f4898d99084f2b2929823acc9a2747ad4. Could be anywhere between oldest and that.
*** Bug 111425 has been marked as a duplicate of this bug. ***
I can reproduce the problem already when 2 (!) whole rows are copied. Repro with: - LO 5.4.0.3 (release) - LO 5.3.6.0.0+ (x64) Build-ID: 8cfb5788cc602e0a81ae47832c65cf2402471034 TinderBox: Win-x86_64@62-TDF, Branch:libreoffice-5-3, Time: 2017-07-31_21:50:11 - LO 6.0.0.0.alpha0+ (x64) Build ID: 386fcf9be786b302cd2c6f85ff6d8d97a6777926 TinderBox: Win-x86_64@42, Branch:master, Time: 2017-08-06_03:08:58 No repro with LO 5.3.5.2 (release)!
Correction to Comment 14: Also reproduced with LO 5.3.5! At my first test I haven't seen that OpenGL was not active because of the OpenGL blacklist.
On Windows 10 Home 64-bit en-US with Version: 5.4.0.3 (x64) Build ID: 92c2794a7c181ba4c1c5053618179937228ed1fb CPU threads: 4; OS: Windows 6.19; UI render: GL; Locale: en-US (en_US); Calc: group Same system clean shutdown of soffice.bin when OpenGL rendering not in use. http://crashreport.libreoffice.org/stats/crash_details/d82b6ed0-e6e9-4e4c-aaa4-05f76712b8d4
Submitted gerrit patch : https://gerrit.libreoffice.org/#/c/42013/ (waiting for comments).
*** Bug 112157 has been marked as a duplicate of this bug. ***
Dennis Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=157d1a774086d7344d443005442682f2ca3c01a9 tdf#108299: Limit the size of bitmap created for clipboard... It will be available in 6.0.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.
Dennis, please set as Fixed. And also please see if Bug 104198 is a duplicate.
I'm still looking for a better solution that fixes the root cause, will have some update soon. Till then I'd like to leave this as "assigned".
Tests with Version: 6.0.0.0.alpha0+ (x64) Build ID: bc9714fefb2dd2ad55a92aaacb6b246f354ed2c0 CPU threads: 4; OS: Windows 6.19; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-09-11_23:29:52 Locale: de-DE (de_DE); Calc: CL was succesful: LO was no longer running after Exit when 3 whole rows were copied into the clipboard. I have also tested for the behavior described in the duplicate Bug 111425: Problem exists no longer.
Created attachment 136192 [details] Call trace leading to the allocation of huge bitmap in opengl Attached the call trace leading to the allocation of huge bitmap in opengl in ImplOpenGLTexture::ImplOpenGLTexture()
Dennis Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8a70142223049f98a9c6f91130ecdc87a2a9becf Revert "tdf#108299: Limit the size of bitmap created for clipboard..." It will be available in 6.0.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.
Please wait till https://gerrit.libreoffice.org/#/c/42194/ gets accepted before testing daily builds, because I have reverted previous fix just now. Thanks.
Dennis Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=de55aa0f639a451aae05ec515cfa58d4bbdd8816 tdf#108299: Limit the width and height of opengl bitmap to... It will be available in 6.0.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.
Dennis Francis committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6d5d07c1ac00af40858effe8d075a16c016a08fc&h=libreoffice-5-4 tdf#108299: Limit the width and height of opengl bitmap to... It will be available in 5.4.2. 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.
Tests from Comment 22 repeated with Version: 6.0.0.0.alpha0+ (x64) Build ID: 33ead25229d308f98fa171412f2937ca0ba976e9 CPU threads: 4; OS: Windows 6.19; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-09-13_01:25:46 Locale: de-DE (de_DE); Calc: CL Result: OK
Tests from Comment 22 repeated with Version: 5.4.2.1 (x64) Build-ID: dfa67a98bede79c671438308dc9036d50465d2cb CPU-Threads: 4; Betriebssystem:Windows 6.19; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: group Result: OK
Stefan, feel free to set Verified in that case. I did it now.
(In reply to Timur from comment #30) > Stefan, feel free to set Verified in that case. I did it now. Hi, I didn't know that I am authorized to do this.
*** Bug 113917 has been marked as a duplicate of this bug. ***
*** Bug 114253 has been marked as a duplicate of this bug. ***