Created attachment 105124 [details] this file causes LO to crash when opening Problem description: when opening attached file Windows 7 SP1 reports Libreoffice stop working Steps to reproduce: 1. open cmd.exe window 2. cd to a directory you downloaded the ODS file 3. enter follwing in cmd.exe window "test.ods" where test.ods is the name of the file you downloaded 4. windows reports "Libreoffice stop working" 5. the ".~lock.Multimeters xls.ods#" is created on disk. However there is no error when I double click on "Multimeters xls.ods" in windows explorer. Current behavior: windows reports Libreoffice stop working Expected behavior: display odt document Operating System: Windows 7 Version: 4.3.0.4 release
Hi, I don't reproduce. Following your steps, this file is correctly opened with LO 4.3.0.4 and Windows 7 Home Premium. Did you get this behaviour each time? Have a nice day, Jacques
@Bogdan which Win7 version do you use? 32 or 64 bit?
The computer has windows 7 Pro, SP1, 64bit. I will try to locate another win7 computer and attempt to reproduce the problem.
The visible difference is that after launching the file by Command Prompt the soffice.bin command line has this parameter: "-env:OOO_CWD=2<user profile directory>" and by Explorer this one: "-env:OOO_CWD=2<directory containing the file>"
Other filetypes are affected too.
1) From CMD.exe window (when crashing) Process tree (shown by procexp) explorer.exe/cmd.exe/scalc/soffice.exe/soffice.bin "C:\Program Files (x86)\LibreOffice 4\program\scalc.exe" "-o" "D:\meme2\rozne\miernik\test.ods" "--calc" "-env:OOO_CWD=2D:\\meme2\\rozne\\miernik" working dir C:\Program Files (x86)\LibreOffice 4\program\ 2) From Windows explorer (when OK) process tree services.exe/svchost.exe(dcom launchner)/explorer.exe/scalc/soffice.exe/soffice.bin "C:\Program Files (x86)\LibreOffice 4\program\scalc.exe" "-o" "D:\meme2\rozne\miernik\test.ods" "--calc" "-env:OOO_CWD=2D:\\meme2\\rozne\\miernik" working dir C:\Program Files (x86)\LibreOffice 4\program\ 3) From cmd.exe using "start test.ods" OK, no problem tree/args/env like in 1) 3) when started like 2), then close the document but calc stays up, then from cmd.exe window "test.ods", works OK, tree/args/env like in 2) Should I be testing this on another win7 64bit box or have you manage to reproduce ?
Probbably similair problem like bug 85777
I am able to reproduce this problem with multiple types of files, regardless of which LO application is used (eg. Calc, Writer, etc...) LO Version: 4.3.6.2 Build ID: d50a87b2e514536ed401c18000dad4660b6a169 System Info: OS Name: Microsoft Windows 7 Professional Version: 6.1.7601 Service Pack 1 Build 7601 System Type: x64-based PC
Problem signature: Problem Event Name: APPCRASH Application Name: soffice.bin Application Version: 4.3.6.2 Application Timestamp: 54c9c54c Fault Module Name: MSVCR110.dll Fault Module Version: 11.0.51106.1 Fault Module Timestamp: 5098858e Exception Code: 40000015 Exception Offset: 000a327c OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1033 Additional Information 1: 5e16 Additional Information 2: 5e168df8b69b13422ad1f4accf7cfdeb Additional Information 3: 51ed Additional Information 4: 51ed4a2606dfcf707b72d07b66ccf875
Created attachment 115000 [details] Backtrace from crash generated from WinDbg
*** Bug 85777 has been marked as a duplicate of this bug. ***
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=be3e1d65f50fe8b4ce5e4a87a82ff231c00aae79 tdf#82968: python3: fix stdio detection on WNT harder It will be available in 5.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.
Py_Initialize() ends up calling abort() because it can't set up stdio stuff. similar to bug 77891, but the difference is that this bug is about starting soffice.exe from a cmd.exe console. can reproduce this on master. the upstream bug has a new patch that appears to fix this problem. upstream bug is: http://bugs.python.org/issue17797 - bugzilla doesn't allow to add it to "see also" :( probably it's a regression since the upstream bug says the issue did not exist with Visual Studio 2010 which was used for LO 4.0-4.1 builds. fixed on master
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b424497fa2d7391857915bc1beb08918b37cd755&h=libreoffice-4-4 tdf#82968: python3: fix stdio detection on WNT harder It will be available in 4.4.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.
Version 4.4.4.1.0 appears to work now: Version: 4.4.4.1.0+ Build ID: 24c5f9979e61fde7b098af60756a4890e5713390
See also https://bugs.documentfoundation.org/show_bug.cgi?id=85777
*** Bug 90368 has been marked as a duplicate of this bug. ***
*** Bug 85191 has been marked as a duplicate of this bug. ***
As someone who is involved in developing software for our tree service company Columbus that's url is https://arboristcolumbusohio.com/ (for your reference), I recently came across an issue that I believe some of you might have faced too. When running a Python script from the Windows cmd.exe command prompt, I encountered frequent crashes and aborts due to what seems to be a problem related to Python stdio initialization. I wanted to reach out to this community to see if anyone else has experienced a similar problem and if there are any insights or solutions you might be able to offer. It's quite frustrating to have our development workflow disrupted by these unexpected crashes, and I believe that sharing our experiences could help all of us find a way forward. From what I've gathered so far, this issue might be tied to how Python initializes its standard I/O streams in the Windows command prompt environment. I've tried various workarounds, including adjusting buffering settings and examining potential conflicts with other software, but I haven't yet found a definitive solution. If any of you have successfully tackled this problem or have suggestions on how to address it, I would greatly appreciate your input. Our goal is to ensure a smooth development process as we continue to enhance our tree service company's software tools. Thank you in advance for your expertise and insights. Let's collaborate to overcome this obstacle and continue delivering high-quality software solutions.