Description: When a cell range is selected in a sheet and Ctrl+P shortcut is used to call a print configuration dialog, while in other sheets there are user defined print ranges, LibreOffice either displays a "Fatal Error" window, which says "vector<T> too long" and almost always program crashes, or hangs. Steps to Reproduce: 1.Setup new calc document, setup multiple sheets (say 10) with random content 2.In some sheets define a print range, in some remove 3.Select a cell range in any and press Ctrl+P Actual Results: Program usually displays an error window saying "vector<T> too long" or hangs, sometimes print configuration dialog opens, but after cancelling the dialog, error window pops up and program crashes afterwards Expected Results: A print configuration dialog should open, and if cancelled program should continue to operate. Reproducible: Sometimes User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Wersja: 6.1.3.2 (x64) Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb Wątki CPU: 8; OS:Windows 6.1; UI render:domyślny; Ustawienia regionalne: pl-PL (pl_PL); Calc: CL
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.) I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Created attachment 146664 [details] Document set-up to reproduce the bug
I have just confirmed, that even, if only a single cell instead of a cell range is selected, the bug will also be reproducible just as often. I have also found, that calling print from file menu will reproduce the bug.
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
I have already checked that as per instructions before posting the bug (I have restarted Libreoffice in safe mode and reproduced the bug with attached file). Also this bug is reproducible on multiple machines across the company I work for.
Repro; hangs (pressing CTRL+P for attached document) Version: 6.2.0.0.alpha1+ Build ID: 397dd8a5f7694540f31f32759c2c915d63506ccd CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-11-07_23:58:04 Locale: nl-NL (nl_NL); Calc: CL but not with Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
Created attachment 146700 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I got an assertion.
Eike: thought you might be interested in this one since assert quoted in provided bt has been added with fd5e480eaf78c8bd2ea4315649fcbd5b8edaa3da
In Windows, "Fatal Error"with "vector<T>. In Linux, crash happens later. CrashReport doesn't have link again.
I can't reproduce it in Version: 6.3.0.0.alpha0+ Build ID: bdc82e277759a2df68855fce0a3fdd58f9b1ea66 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded nor in Versión: 6.1.3.2 Id. de compilación: 86daf60bf00efa86ad547e59e09d6bb77c699acb Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; Configuración regional: es-ES (es_ES); Calc: group threaded I just need to open the file, and go to File - Print?
Created attachment 147628 [details] select cells reproducible with: Version: 6.1.4.2 (x64) Build ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: de-DE (de_DE); Calc: open attached file, select cell range, select print
just received same error with issue: https://bugs.documentfoundation.org/show_bug.cgi?id=122141 Calc crashed in time PDF export file from 122130 (Crash in: libc-2.26.so)
crashes also with: Version: 6.3.0.0.alpha0+ (x64) Build ID: 21b81b07b01e4482a80ced8dcdf48c480031c3c8 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded please try several times: - select cell range - ctrl+p - close dialog - ctrl+p
seem to have started with: https://gerrit.libreoffice.org/plugins/gitiles/core/+/5217a2a0bf27e496cc429ee45dff7c239b466ae6 commit 5217a2a0bf27e496cc429ee45dff7c239b466ae6 [log] author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> Tue Dec 12 22:22:32 2017 +0900 committer Tomaž Vajngerl <quikee@gmail.com> Wed Dec 13 00:54:48 2017 +0100 tree b103a823e8c4bb144ea28c9d15286721088f16b9 parent eb002da913cd1745b039bbc7e519542d7990fb49 [diff] tdf#114256 add cache criterium when to recalculate page range size Page range size can only be valid for the input parameters, which includes the document size, which was not taken into account at all before. Now we look at all this parameters to decide if we need to recalculate or not. Change-Id: Ic52ad7516189b395c66f59aabc374c3da85f6a89 Reviewed-on: https://gerrit.libreoffice.org/46300 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> $ git bisect log # bad: [1d66cc00ca6fd2e562cbed88704051b2f5d989e3] source 8d2abb388b0a2423c9b7e1f52373e1b06dd9786f # good: [29d08f54c2f71ffee4fe12dbb24c5f5cbedecfd2] source 6eeac3539ea4cac32d126c5e24141f262eb5a4d9 git bisect start 'master' 'oldest' # bad: [3ac46f6c41b5044f162a451b10af0dc5afdcc113] source 22c7c3f54dbb93f856190c561b2540064c5a767d git bisect bad 3ac46f6c41b5044f162a451b10af0dc5afdcc113 # bad: [aa87e2b4fca257b364e56d731159caf9884e32dd] source 7970cca95027cca9847202c6e8263124a4eb30a6 git bisect bad aa87e2b4fca257b364e56d731159caf9884e32dd # bad: [c76d72527c9591f94ec82f87130c10fe600502f0] source a5be07d6b627a18f104e2feed063ff9020e8c610 git bisect bad c76d72527c9591f94ec82f87130c10fe600502f0 # good: [29511c6b4a1b32ee7152a65c936b19264d5fb0ed] source 7cbedaa94f23a1f7676ff649ee6c19eb3a42dfb0 git bisect good 29511c6b4a1b32ee7152a65c936b19264d5fb0ed # bad: [e288f27cd67026a1f41ffd9a6cbafe6202f5e87c] source fd88c4b45426600bd09fc47f8df9ac1cb8030e95 git bisect bad e288f27cd67026a1f41ffd9a6cbafe6202f5e87c # good: [31719d5e3c36ef3d7969d4a3bb40ee8286efb866] source ce652a7f0d2745143a3e1078607a72695ce124f9 git bisect good 31719d5e3c36ef3d7969d4a3bb40ee8286efb866 # good: [d4082b3041b5152309148c6651b62a6a490768ca] source 5de99031fa31eaf78d92cf5aa8de6cac8f2f8782 git bisect good d4082b3041b5152309148c6651b62a6a490768ca # good: [15bd15429debfa798d971cfed7e210503fb5e732] source 810b5f6491850d70bfe2da1f58927a3404d37d49 git bisect good 15bd15429debfa798d971cfed7e210503fb5e732 # good: [da9859bf1a7b4a268eaee75ee5cdea8b1bef7b52] source 1e70464c380ecc0756ea29098632c503a60aec71 git bisect good da9859bf1a7b4a268eaee75ee5cdea8b1bef7b52 # bad: [0d1dcd0a2a05805c513399989da0efb89aa8d396] source 8782ea036e97c383e0a979ed30c8da955c56877b git bisect bad 0d1dcd0a2a05805c513399989da0efb89aa8d396 # bad: [37bbce04ad7b4918998cf7c8759b17a32d06b3b9] source 5217a2a0bf27e496cc429ee45dff7c239b466ae6 git bisect bad 37bbce04ad7b4918998cf7c8759b17a32d06b3b9 # good: [40453ff4aef102d094beacd57a2c2a6cf4c6c013] source dcdaca599987ded1577bd04ed1e70f5bd02e943f git bisect good 40453ff4aef102d094beacd57a2c2a6cf4c6c013 # good: [e5ff358709ef06ab837a5c75dabf3693f526d8a8] source eb002da913cd1745b039bbc7e519542d7990fb49 git bisect good e5ff358709ef06ab837a5c75dabf3693f526d8a8 # first bad commit: [37bbce04ad7b4918998cf7c8759b17a32d06b3b9] source 5217a2a0bf27e496cc429ee45dff7c239b466ae6
Created attachment 147632 [details] another error message
(In reply to Oliver Brinzing from comment #14) > seem to have started with: > > https://gerrit.libreoffice.org/plugins/gitiles/core/+/ > 5217a2a0bf27e496cc429ee45dff7c239b466ae6 > > commit 5217a2a0bf27e496cc429ee45dff7c239b466ae6 [log] > author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> Tue Dec 12 22:22:32 > 2017 +0900 > committer Tomaž Vajngerl <quikee@gmail.com> Wed Dec 13 00:54:48 2017 +0100 > tree b103a823e8c4bb144ea28c9d15286721088f16b9 > parent eb002da913cd1745b039bbc7e519542d7990fb49 [diff] > > tdf#114256 add cache criterium when to recalculate page range size > > Page range size can only be valid for the input parameters, which > includes the document size, which was not taken into account at all > before. Now we look at all this parameters to decide if we need to > recalculate or not. > > Change-Id: Ic52ad7516189b395c66f59aabc374c3da85f6a89 > Reviewed-on: https://gerrit.libreoffice.org/46300 > Tested-by: Jenkins <ci@libreoffice.org> > Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> > I was bisecting it right now as well ;-) i do confirm the problem is caused by the mentioned commit Adding Cc: to Tomaž Vajngerl
*** Bug 122141 has been marked as a duplicate of this bug. ***
*** Bug 122130 has been marked as a duplicate of this bug. ***
*** Bug 122337 has been marked as a duplicate of this bug. ***
Users may not able to solve or fix up the setup and configuration of Printer with a MAC OS based system. There are several queries with providing all the possible solutions has already given in https://applesupportnumber.net/blog/error-connecting-to-apple-id-server/ that will provide an actual solution.
Possible fix: https://gerrit.libreoffice.org/#/c/68739/
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/9432bab9f8f4a246d205ff2a460f60aeedba8ce1%5E%21 do not access uninitialized values when printing (tdf#121439) It will be available in 6.3.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.
Would be great to confirm the fix - if someone can with a nightly build ... is this gone ?
On pc Debian x86-64 with master sources updated today, I don't reproduce this anymore. I opened the Julian's attachment, selected a range from sheet1 and typed "Ctrl-P", no assertion or crash, the print dialog appeared normally.
With Version: 6.3.0.0.alpha0+ (x64) Build ID: 91cdf22b88a4f7bec243c8fb187627e766d3294c CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-08_00:38:10 Locale: pl-PL (pl_PL); UI-Language: en-US Calc: CL I was not able to reproduce the error.
Thank you Julian for your feedback. Let's put this one to FIXED then.
then Verified since you confirmed it's ok.
Verified in Version: 6.3.0.0.alpha0+ Build ID: c196d70337f6b755cfc4c34beda05554c6fab114 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
Cherry-picked to 6.2 https://gerrit.libreoffice.org/#/c/69261/ 6.1 https://gerrit.libreoffice.org/#/c/69262/
Luboš Luňák committed a patch related to this issue. It has been pushed to "libreoffice-6-1": https://git.libreoffice.org/core/+/b0464b42d1416a521e6ce0e492f1628b5fb46910%5E%21 do not access uninitialized values when printing (tdf#121439) It will be available in 6.1.6. 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.
Luboš Luňák committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/9e9fb722f10a7e49093566e746ed50632895344c%5E%21 do not access uninitialized values when printing (tdf#121439) It will be available in 6.2.3. 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.
El problema se daba con un archivo que tenía en algunas celdas enlaces a celdas de otro archivo. Había copiado el contenido de la celda y vuelto a pegar como solo valores. Luego eliminado el archivo con el que estaba enlazada. Buscando imprimir el archivo, lo subí a Google Drive y lo abrí con aplicación de Google. Allí se mostró el error comentado. Borré el contenido de la celda y lo volví a bajar. El archivo que bajé lo pude imprimir sin problema. ¡Solucionado!