Description: When opening a Calc document with a user-defined function that calls some Python code from location=document, the following error message will be shown: BASIC runtime error. An exception occurred Type: com.sun.star.script.provider.ScriptFrameworkErrorException Message: ProviderCache::createProvider() Error creating provider from factory. <class 'KeyError'>: 'document’, traceback follows File "/usr/lib/libreoffice/program/unohelper.py”, line 295, in createInstanceWithArgumentsAndContext return self.clazz(context, *args) File "/usr/lib/libreoffice/program/pythonscript.py”, line 999, in __init__ raise e File "/usr/lib/libreoffice/program/pythonscript.py”, line 975, in __init__ urlHelper = MyUriHelper(ctx, storageType) File "/usr/lib/libreoffice/program/pythonscript.py”, line 189, in __init__ self.m_baseUri = expandUri(self.s_UriMap[location]) I have attached a sample document "HelloWorld.ods" with a minimal Python hello world function, that is wrapped with a BASIC macro as a user-defined function. This Calc document works fine with LibreOffice version up to 6.1.3.2. Newer versions show the error message as described above when the file is opened. Tested versions that are affected from this bug: * 6.1.4.2 (Arch Linux 64 bit) * 6.1.4.2 (Windows 32 bit) * 6.2.0.1 (Linux 64 bit AppImage) * 6.3.0.0.alpha0_2018-12-29 (Linux 64 bit AppImage) Steps to Reproduce: 1. Allow execution of macros (changing "Macro Security" setting to "Medium") 2. Open the attached document "HelloWorld.ods" 3. Select "Enable Macros" Actual Results: The error message described above will be shown. The =HELLOWORLD() function in cell "B3" is not evaluated. Expected Results: The formula in cell "B3" should evaluate to "Hello world". Reproducible: Always User Profile Reset: Yes Additional Info:
Created attachment 148113 [details] HelloWorld.ods test file
By the way, recalculating the formula in cell "B3" of the test file works just fine after the error message appeared and the document was loaded completely.
bibisection on bibisect-linux-64-6.1 ee9a64227e53eb0788cae2de947a41d0b3185b92 is the first bad commit commit ee9a64227e53eb0788cae2de947a41d0b3185b92 Author: Jenkins Build User <tdf@pollux.tdf> Date: Tue Oct 23 00:07:51 2018 +0200 source 693953dd4699887bd3f5bca2c3582b5fae1d6992 source 693953dd4699887bd3f5bca2c3582b5fae1d6992 :040000 040000 40b493510419848fb351479712cf4696d2b59fd5 36e28337ad421851044ed76fce156ddaa7f2121c M instdir $ git bisect log # bad: [342f2f26f2f0e06a2128d0ae2c1478e0461551f0] source d6f563b37d8a694c6c1d4c9ef3ba746c7f019517 # good: [2c1cccc19f9e70d2ecbc9ba7815abd674ab6d858] source 6eeac3539ea4cac32d126c5e24141f262eb5a4d9 git bisect start 'origin/master' 'oldest' # good: [e538cd24944f4ec8fafeac82a3d3b39f1cae88ee] source e4b13d90bfe99428564fba147e9b00210de341b2 git bisect good e538cd24944f4ec8fafeac82a3d3b39f1cae88ee # good: [322b3e22d920a1984c0ee50d962c3c4d88e1d9c2] source b00d6854f88bb9f071095c89bf2c6d4ded6b4ec6 git bisect good 322b3e22d920a1984c0ee50d962c3c4d88e1d9c2 # good: [8205842e59def4b439903d671dcc9b5332da799d] source 8b96445766efe237eb47608ade6c147673466e2e git bisect good 8205842e59def4b439903d671dcc9b5332da799d # good: [3dea3eb23623fb1885cf9af5195701fc410bb77c] source 2000a0d6d4a0d130a7ff822d64ba941de1c761e0 git bisect good 3dea3eb23623fb1885cf9af5195701fc410bb77c # good: [3a808b207967368ec23ba4bc318199ff876dfa26] source e9e18b5a3a0e9651b7161278a61c6a7ce0b9df0b git bisect good 3a808b207967368ec23ba4bc318199ff876dfa26 # good: [e6ede5d5cc4b51bde1526ce5357d047625569a55] source 4d3a7335c6a5f38feac0e10d17e5f5c0f7390f2c git bisect good e6ede5d5cc4b51bde1526ce5357d047625569a55 # good: [50fc6b3a372f744565d0aa3fc25eb0ff150e8b0c] source f19cba204552ecb11b97c8047320733c498cf518 git bisect good 50fc6b3a372f744565d0aa3fc25eb0ff150e8b0c # good: [ea834c2d6a0b159e801ec4795729231e0a8e9eb7] source b3b52643983ec28838eeeed9f841b0918dc745be git bisect good ea834c2d6a0b159e801ec4795729231e0a8e9eb7 # good: [f6de0c95847352c1bf6bb2965cd4bc1c34fe7fe7] source ac39aba9b2d08b061b0eef651f5ebc7a84391171 git bisect good f6de0c95847352c1bf6bb2965cd4bc1c34fe7fe7 # good: [be8cae86f4c3ccb86c2546a22824ee682c0df00b] source e67ca59e293c4dd37795150cf871e36ca1affb76 git bisect good be8cae86f4c3ccb86c2546a22824ee682c0df00b # bad: [788b421bab3d0570bcbae3ac85d95258f0554f3d] source 5de85be43198804573787d4186b156b5931c4a9f git bisect bad 788b421bab3d0570bcbae3ac85d95258f0554f3d # good: [220a224a1aa9ade1015e7f4f5ddfdf0778a3d1ae] source fad764c02c7a9cd210bfa44ea0ce1ac5354d6427 git bisect good 220a224a1aa9ade1015e7f4f5ddfdf0778a3d1ae # bad: [ee9a64227e53eb0788cae2de947a41d0b3185b92] source 693953dd4699887bd3f5bca2c3582b5fae1d6992 git bisect bad ee9a64227e53eb0788cae2de947a41d0b3185b92 # first bad commit: [ee9a64227e53eb0788cae2de947a41d0b3185b92] source 693953dd4699887bd3f5bca2c3582b5fae1d6992
bibisection on bibisect-linux-64-6.2 5d007cfc8733799cf0535eac3e482eb8cae4b908 is the first bad commit commit 5d007cfc8733799cf0535eac3e482eb8cae4b908 Author: Jenkins Build User <tdf@pollux.tdf> Date: Fri Jun 8 00:50:11 2018 +0200 source 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b source 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b :040000 040000 cba7bb3b1fe4d7c4d0646add404a9a347441f0b0 fb0b3eaece364eff62dc6d1c27bb8a6d41bf8968 M instdir $ git bisect log # bad: [81932e2da4ad9fd889ca65cab4b3178dac680b8d] source a63cd8bbe7cf881daa8dc7a7f32f3e5ac384e902 # good: [f741463dfe1900d3acf87b538c0c043e42bc523d] source 3a801799536e6870f2fb111b1cc00b9575a35a39 git bisect start 'origin/master' 'oldest' # bad: [a0b4eac825df0b65480600742b99c1892f0e2e69] source 7b52990a234bfd6d4efcbc9fe51e240e065faeea git bisect bad a0b4eac825df0b65480600742b99c1892f0e2e69 # bad: [3608d377acb76beb2e5ec9e094c2d0f0b4df7aa3] source 510209df4bcf457cac819e75889d564d620f119d git bisect bad 3608d377acb76beb2e5ec9e094c2d0f0b4df7aa3 # bad: [8cfe6975aa90f40ebf4f667f066fced309426c93] source c8a739a2c84f45f878d2ae75eaf16a2f814d1c6e git bisect bad 8cfe6975aa90f40ebf4f667f066fced309426c93 # good: [6db7254d8afc955065fb37ce0c412b5c06e00601] source 5525c1f871a4e810dfad7f4e96b6c439f4c6afe2 git bisect good 6db7254d8afc955065fb37ce0c412b5c06e00601 # bad: [2898bbd268f98f46eb05344482c374a521df3031] source a3c07b06127f33dddbdf718dc997d4554d1503f5 git bisect bad 2898bbd268f98f46eb05344482c374a521df3031 # bad: [22931eadd535a5a498e62783345451a039d2e68f] source 63e404e4105cee07c9e58760cdc4ad7e917fa3de git bisect bad 22931eadd535a5a498e62783345451a039d2e68f # good: [c77bed9e18e4a2c9dab4619b66460260361da9d9] source a96a260a5fd6303eeebb26aee4be24ddf88391d1 git bisect good c77bed9e18e4a2c9dab4619b66460260361da9d9 # good: [1315825f86ced94bec15e62059571e0d3d62db43] source 576f899811a22e83b6fb6a120c8da303b1f4cac1 git bisect good 1315825f86ced94bec15e62059571e0d3d62db43 # good: [7c857de06ff5c6a1e7663a5fe057ba284726a6af] source f6134b153a0b172e6f8f0a8e76985bd6a7848692 git bisect good 7c857de06ff5c6a1e7663a5fe057ba284726a6af # good: [13760daeb59ff9bd2e4ecc973e108fea7a418b55] source fccc7aebb5285e36530b14001e37b33b586365f9 git bisect good 13760daeb59ff9bd2e4ecc973e108fea7a418b55 # good: [2fee85293f3c389834856f15f96e86ff537cee82] source 2a7f74900fb646235b74d4c9bd4690e44edc3ed4 git bisect good 2fee85293f3c389834856f15f96e86ff537cee82 # bad: [e93e82d56e216e067ba056d8eb96b75ef990a74f] source 5708534b942c1d0ce384f6a8473da6bb569410e7 git bisect bad e93e82d56e216e067ba056d8eb96b75ef990a74f # bad: [5d007cfc8733799cf0535eac3e482eb8cae4b908] source 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b git bisect bad 5d007cfc8733799cf0535eac3e482eb8cae4b908 # first bad commit: [5d007cfc8733799cf0535eac3e482eb8cae4b908] source 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b
The error is caused by commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=693953dd4699887bd3f5bca2c3582b5fae1d6992 I think there's an indirect connection between this commit and the error. Maybe the evaluation of the cell and the calculation of the row height is done before the Python scripts inside the document actually are loaded: * The test document works fine and opens without any error if the row height for cell "B3" (with the user-defined function calling the Python code) is changed from optimal to a fixed value. * It also works and opens without error if the script is changed to location=user and the appropriate Python file is copied to the user profile directory.
i can confirm the problem, but also with lo 5.4.7.2 and 6.0.7.3 (Win 10) error messsage appear during load, a full hard recalc works.
Thanks for looking into this. Strange that these older LO version shows the same problem for you on Windows 10. As far as I could see, the commit mentioned above that introduced the recalculation of the row heights was not backported to these older versions. Thus, there's probably another reason for this. I have tested the same LO versions 5.4.7.2 and 6.0.7.3 both as official Linux AppImage x86_64 and each time with fresh user profile. With these older versions I cannot reproduce the bug. The test file works fine in both versions without error message at opening. I have also tried another bibisection for older versions with the bibisect-linux-64-6.0 repo. The oldest commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=9feb7f7039a3b59974cbf266922177e961a52dd1 (libreoffice-5-4-branch-point) and the latest commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=c6c82096301180cfa7942dd9fb9d1cb66c7ecc04 of that binary repo works fine for me.
(In reply to spinnau from comment #7) > Strange that these older LO version shows the same problem for you on > Windows 10. As far as I could see, the commit mentioned above that > introduced the recalculation of the row heights was not backported to these > older versions. Thus, there's probably another reason for this. Could you please try LO 5.4.7.2 with Tools/Options.../LibreOffice Calc/Formula Recalculation on File Load ODF [Always Recalculate] with default setting [Never Recalculate] there is no error.
Good catch! With the "Recalculate on File Load | ODF spreadsheet" option set to "Never recalculate" the test document works fine with the older versions 5.4.7.2, 6.0.7.3 and 6.1.3.2. Changing this option to "Always recalculate" triggers the error message (Error creating provider from factory!) at opening of the test file on all these versions. All the tests were done with Linux AppImages. Thus, I think the recalculation of the cells will be done too early before the Python scripts from loaction=document were available. But at testing I have also found another problem. If the "Always recalculate" option is set in version 6.1.4.2 then at opening the test file the error message dialog appears twice. I think in this case the recalculation will be done twice, once through the "Always recalculate" option and once for determining the optimal cell heights. This assumption can be verified by changing the height for cell "B3" in the test file from optimal to a fixed height. In that case at opening the test file the error message appears only once with "Always recalculate" option, and no error message is shown with "Never recalculate". Independent of this bug, a recalculation of the cells shouldn't happen twice when a document is opened. Maybe another bug report should be opened for this.
Adjust version according to comment 9, needs another round of bibisecting now.
if recalculation on File Load for ODF files is set to Always Recalculate in Tools/Options.../LibreOffice Calc/Formula the problem can also be reproduced in Version: 5.2.0.0.alpha1+ Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; Locale: ca-ES (ca_ES.UTF-8) thus, this is not a regression per se. 1e55a47e89a9d9d6cf9cb3993484022aaf2c097b just made this problem more visible
I have the same problem: Error when opening a calc file with an embedded python script. LO Version: 6.3.5.2 Build ID: 1:6.3.5-0ubuntu0.19.10.1
Dear spinnau, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still repro with: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e46e663cc350d89e4997095466d675b875eb2e04 CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win
Probably the same bug as Bug 158417 reported by me the 28-11-2023. Always repro too. Windows 10 x64 OS. I do not know the internals of LibreOffice but seems like a process or thread sync problem. If the autocalculate is disables during file loading, the error do not appear. This seem to prove that it is a timing problem. Perhaps a missing check before to run Basic scripts.
Same problem in AOO 4.1.0, and in OOo 3.2.0.
*** Bug 158417 has been marked as a duplicate of this bug. ***