Created attachment 116443 [details] fatal error Version: 5.0.0.0.beta3 ID build: 96345c15d8ab19c49014f055fe41ba8e1f421e5c Locale: ru-RU (ru_RU) OS: Windows 7 HB x86-64 1. Open new writer document 2. Menu File-Wizards-Letter 3. Push button "Cancel" 4. LO is crashed with fatal error (see screenshot) It seems that all wizards with a bug. ps: JRE 1.8 is installed
On pc Debian x86-64 with master sources updated yesterday, I don't reproduce the crash but had this on console: warn:fwk:4356:1:framework/source/fwi/threadhelp/transactionmanager.cxx:257: TransactionManager...: Owner instance not correctly initialized yet. Call was rejected! Normally it's an algorithm error ... wrong use of class! warn:fwk:4356:1:framework/source/fwi/threadhelp/transactionmanager.cxx:257: TransactionManager...: Owner instance not correctly initialized yet. Call was rejected! Normally it's an algorithm error ... wrong use of class! warn:ucb.ucp.gio:4356:1:ucb/source/ucp/gio/gio_content.cxx:400: ignoring GError "L'emplacement indiqué n'est pas pris en charge" for <vnd.sun.star.job:alias=UpdateCheck> warn:sw.core:4356:1:sw/source/core/attr/calbck.cxx:155: a 8SwDepend client added as listener to a 12SwCharFormat during client iteration. warn:legacy.osl:4356:1:sw/source/core/attr/format.cxx:228: SwFormat::~SwFormat: Def dependents! warn:sw.core:4356:1:sw/source/core/attr/format.cxx:237: ~SwFormat: parent format missing from: Character style warn:legacy.tools:4356:1:vcl/source/window/window.cxx:525: Window::~Window: inconsistency in top window chain!
Looking for the code in transactionmanager.cxx //ATTENTION: temp. disabled - till all bad code positions are detected and changed! */ gives this: commit 3642f95267df77a383e44cde754e2724e0a70733 Author: Andreas Schlüns <as@openoffice.org> Date: Thu May 2 10:41:31 2002 +0000 #99021# fix static inline problem by outlining See http://opengrok.libreoffice.org/xref/core/framework/source/fwi/threadhelp/transactionmanager.cxx#250
No crash here. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 5fc0cbbc1254223fedf0f78c5e7539219b228697 TinderBox: Win-x86@39, Branch:master, Time: 2015-06-11_04:30:51 Locale: fi-FI (fi_FI)
Created attachment 116492 [details] bt with debug symbols from first message bt from framework/source/fwi/threadhelp/transactionmanager.cxx, line 255
Just some findings. From propertysethelper, I noticed 2 classes which inherit from it: - TabWindowService (see http://opengrok.libreoffice.org/xref/core/framework/source/services/tabwindowservice.cxx#85) - Frame (see http://opengrok.libreoffice.org/xref/core/framework/source/services/frame.cxx#127) In our case, only Frame class is used. Indeed, after some gdb session, I noticed the process went this order: 1) call of Frame ctr 2) call initListeners method 3) 2 same warnings: warn:fwk:3350:1:framework/source/fwi/threadhelp/transactionmanager.cxx:257: TransactionManager...: Owner instance not correctly initialized yet. Call was rejected! Normally it's an algorithm error ... wrong use of class! 4) call of initialize method which itself sets E_WORK So there's a call to "m_aTransactionManager.setWorkingMode( E_WORK );" but too late. Indeed after 2), we're in E_INIT state.
I kept on to dig, here's the pb: 166 try: 167 xFrame = xMSF.createInstance("com.sun.star.frame.Frame") 168 except Exception: 169 traceback.print_exc() 170 171 xFrame.initialize(xPeer) Line 167 calls the Frame ctr, initListeners method and transactionManager (1) 2) and 3)from my previous comment) Line 171 call corresponds to 4) http://opengrok.libreoffice.org/xref/core/wizards/com/sun/star/wizards/document/OfficeDocument.py#167
Stephan: I tried to dig a bit (see my 2 previous comments in this bugtracker) but since the rest of bt is in store or pyuno, so UNO part, thought you might have some thoughts. Now perhaps I'm too focused on this transaction part and it doesn't worth it. BTW: README of store module is really scary! :-)
Argh, I meant "stoc" not "store"
Matthew: noticing http://nabble.documentfoundation.org/PyUNO-usability-improvements-td4151556.html, thought you might be interested in this one.
in LO 5.0.0.1 bug is reproduced! why the error is not confirmed? it's broken functionality! and so you miss it in the release!
Unable to reproduce on: Version: 5.0.0.1 Build ID: 9a0b23dd0ab9652e0965484934309f2d49a7758e Locale: es-ES (es_ES.UTF-8) Debian 8 Jessie with KDE
(In reply to kompilainenn from comment #0) > Version: 5.0.0.0.beta3 > ID build: 96345c15d8ab19c49014f055fe41ba8e1f421e5c > Locale: ru-RU (ru_RU) > OS: Windows 7 HB x86-64 Is that the 32-bit "Windows" or the 64-bit "Windows x86_64 (Vista or newer required)" version of LibreOffice? Did you try to reproduce the problem with only one of those two versions, or with both?
hmmm Версия: 5.0.0.1 (32bit) ID сборки: 9a0b23dd0ab9652e0965484934309f2d49a7758e Локаль: ru-RU (ru_RU) OS: Windows 7 HB (32bit) with JRE 7.45 and JRE 8.51 bug is not reproduced
This should be a problem specific to the 64-bit Windows build of LibreOffice (same underlying problem as bug 92014), and should be fixed now with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa6670764b49a37a82641ae8d9fe77683b820190> "MSVC 64-bit: In queryInterface optimization, copy hidden ret val addr" towards LibreOffice 5.0.