Apache OpenOffice (AOO) Bugzilla – Issue 74950
General input/output error while using linked JPG file in OLE object
Last modified: 2017-05-20 10:22:39 UTC
Steps to replicate(m201): 1) Start impress. 2) Select layouts "Title, Object". 3) Click "Object" and select "Create from file". Check "Link to file" and insert a jpg file. Click "OK" button. Then get a dialog with message "Graphics filter not found", and others dialog. And OOo crash.
Reassigned. Not reproducible here. Did you send an error report? Which email or description did you use? Thanks in advance.
No error report. And I find if you insert an invalid file(with *.jpg, but not one good file), OOo Crash. If you insert other file before, all file size become to zero.
I can reproduce a similar bug but not a crash. Do you also get the crash when you insert the graphic as ole without 'linking' it? which OLE server do you use for .jpg? - insert a jpg as ole - double click the inserted ole - the program which opens now to show the ole is the ole server.
I can reproduce a similar bug. 1) Start impress. 2) Select layouts "Title, Object". 3) Click "Object" and select "Create from file". Check "Link to file" and insert a jpg file. Click "OK" button. 4) save the document 5) load the document again 6) You get a dialog with message "Graphics filter not found", and others dialog -> I don't get a crash afterwards. -> I can't load the document.
I get a crash when I take the document and try to insert it as file to another document. Please tell me if this is the same bug or if I should write a new issue for this behaviour.
I'm able to reproduce the crash on my OpenSuSE-10.2-64bit-box with KDE 3.5.6. Here my description of my steps to the crash: I opened a new presentation, changed the layout to "Title, Object". Then I dubble-click on the Object-area on the slide. In the following dialog I selected a jpeg-file from my box as object. The jpg-file was shown as object in the slide. When I tried to save the presentation-file (with the jpg-object inside) OOo crashed. I sent a crashreport with my OOo-Mailadress. Version: OOo_2.2.0rc2_20070223_LinuxIntel_install_de.tar.gz
The ID of the error report is r8j7ub.
I get the "Graphicsfilter not found" Errormessage and the crash only if I link the JPG-File. No problems at all with the JPG embedded into the presentation.
I tried to reproduce the crash again (description from "cgu" above). I'm now able to save the new presentation-file with the jpg-object. But when I closed the presentation afterwards OOo crashes and the crashreporter starts.
Thats the stack of andreas crash report: /so/ws/OOF680/src.m9/sal/osl/unx/signal.c:478 SignalHandlerFunction /so/ws/OOF680/src.m9/sal/osl/unx/signal.c:813 Window::ImplCallInitShow() /so/ws/OOF680/src.m9/vcl/source/window/window.cxx:1634 Window::ImplCallInitShow() /so/ws/OOF680/src.m9/vcl/source/window/window.cxx:1648 Window::Show(unsigned char, unsigned short) /so/ws/OOF680/src.m9/vcl/source/window/window.cxx:6425 SfxWorkWindow::ShowChilds_Impl() /so/ws/OOF680/src.m9/sfx2/source/appl/workwin.cxx:1185 SfxSplitWindow::SetFadeIn_Impl(unsigned char) /so/ws/OOF680/src.m9/sfx2/source/dialog/splitwin.cxx:1183 SfxSplitWindow::FadeOut_Impl() /so/ws/OOF680/src.m9/sfx2/source/dialog/splitwin.cxx:1224 SfxSplitWindow::RemoveWindow(SfxDockingWindow*, unsigned char) /so/ws/OOF680/unxlngi6.pro/inc.m9/vcl/window.hxx:771 SfxDockingWindow::ReleaseChildWindow_Impl() /so/ws/OOF680/src.m9/sfx2/source/dialog/dockwin.cxx:906 SfxDockingWindow::~SfxDockingWindow()� /so/ws/OOF680/src.m9/sfx2/source/dialog/dockwin.cxx:897 sd::PaneDockingWindow::~PaneDockingWindow() /so/ws/OOF680/src.m9/sd/source/ui/dlg/PaneDockingWindow.cxx:98 SfxChildWindow::~SfxChildWindow() /so/ws/OOF680/src.m9/sfx2/source/appl/childwin.cxx:230 sd::LeftPaneChildWindow::~LeftPaneChildWindow() /so/ws/OOF680/src.m9/sd/source/ui/dlg/PaneChildWindows.cxx:106 SfxChildWindow::Destroy() /so/ws/OOF680/src.m9/sfx2/source/appl/childwin.cxx:220 SfxWorkWindow::DeleteControllers_Impl() /so/ws/OOF680/src.m9/sfx2/source/appl/workwin.cxx:770 SfxFrame::DoClose_Impl() /so/ws/OOF680/src.m9/sfx2/source/view/frame.cxx:239 SfxBaseController::dispose() /so/ws/OOF680/src.m9/sfx2/source/view/sfxbasecontroller.cxx:1252 sd::DrawController::dispose() /so/ws/OOF680/src.m9/sd/source/ui/unoidl/DrawController.cxx:184 framework::Frame::setComponent(com::sun::star::uno::Reference const&, com::sun::star::uno::Reference const&) /so/ws/OOF680/unxlngi6.pro/inc.m9/com/sun/star/uno/Reference.h:339 framework::Frame::close(unsigned char) /so/ws/OOF680/unxlngi6.pro/inc.m9/com/sun/star/uno/Reference.hxx:137 DocumentHolder::CloseFrame() /so/ws/OOF680/unxlngi6.pro/inc.m9/com/sun/star/uno/Reference.h:339 OCommonEmbeddedObject::Deactivate() /so/ws/OOF680/unxlngi6.pro/inc.m9/com/sun/star/uno/Reference.h:214 OCommonEmbeddedObject::SwitchStateTo_Impl(long) /so/ws/OOF680/src.m9/embeddedobj/source/commonembedding/embedobj.cxx:342 OCommonEmbeddedObject::changeState(long) /so/ws/OOF680/src.m9/embeddedobj/source/commonembedding/embedobj.cxx:522 SfxInPlaceClient::SetObjectState(long) /so/ws/OOF680/unxlngi6.pro/inc.m9/com/sun/star/uno/Reference.h:115 SfxInPlaceClient::SetObject(com::sun::star::uno::Reference const&) /so/ws/OOF680/src.m9/sfx2/source/view/ipclient.cxx:746 SfxInPlaceClient::~SfxInPlaceClient() /so/ws/OOF680/unxlngi6.pro/inc.m9/com/sun/star/uno/Reference.hxx:137 sd::Client::~Client() /so/ws/OOF680/src.m9/sd/source/ui/docshell/sdclient.cxx:112 SfxViewShell::DisconnectAllClients() ../../inc/viewsh.hxx:177 sd::DrawController::dispose() /so/ws/OOF680/src.m9/sd/source/ui/unoidl/DrawController.cxx:178 framework::Frame::setComponent(com::sun::star::uno::Reference const&, com::sun::star::uno::Reference const&) /so/ws/OOF680/unxlngi6.pro/inc.m9/com/sun/star/uno/Reference.h:339 framework::Frame::close(unsigned char) /so/ws/OOF680/unxlngi6.pro/inc.m9/com/sun/star/uno/Reference.hxx:137 framework::CloseDispatcher::implts_closeFrame() /so/ws/OOF680/unxlngi6.pro/inc.m9/com/sun/star/uno/Reference.h:339 framework::CloseDispatcher::impl_asyncCallback(void*) /so/ws/OOF680/src.m9/framework/source/dispatch/closedispatcher.cxx:400 framework::CloseDispatcher::LinkStubimpl_asyncCallback(void*, void*) /so/ws/OOF680/src.m9/framework/source/dispatch/closedispatcher.cxx:288 vcl::EventPoster::LinkStubDoEvent_Impl(void*, void*) /so/ws/OOF680/unxlngi6.pro/inc.m9/tools/link.hxx:157 ImplWindowFrameProc(void*, SalFrame*, unsigned short, void const*) /so/ws/OOF680/unxlngi6.pro/inc.m7/tools/link.hxx:157 SalDisplay::DispatchInternalEvent() ../../../inc/salframe.hxx:315 SalX11Display::Yield() /so/ws/OOF680/src.m9/vcl/unx/source/app/saldisp.cxx:2358 DisplayYield /so/ws/OOF680/src.m9/vcl/unx/source/app/saldisp.cxx:732 SalXLib::Yield(bool, bool) /so/ws/OOF680/src.m9/vcl/unx/source/app/saldata.cxx:616 X11SalInstance::Yield(bool, bool) ../../../unx/inc/saldata.hxx:124 Application::Yield(bool) /so/ws/OOF680/src.m7/vcl/source/app/svapp.cxx:559 Application::Execute() /so/ws/OOF680/src.m7/vcl/source/app/svapp.cxx:517 desktop::Desktop::Main() /so/ws/OOF680/src.m9/desktop/source/app/app.cxx:1810 ImplSVMain() /so/ws/OOF680/src.m7/vcl/source/app/svmain.cxx:255 SVMain() /so/ws/OOF680/src.m7/vcl/source/app/svmain.cxx:295 main /so/ws/OOF680/src.m9/desktop/source/app/main.cxx:80
cl->cd: one for you
cd: Accepted. Must check why we crash in vcl. Looks like a problem with the window hierachie or a destroyed window.
*** Issue 75254 has been marked as a duplicate of this issue. ***
MD: Added md to cc, added keyword regression since the issue does not occur with 2.1, see my detailed findings in 75254.
*** Issue 75262 has been marked as a duplicate of this issue. ***
target 3.0
target 3.1 as we can't invest much time in debugging ATM.
We are short before code freeze for OOo 3.1. As time is running out I have to shift this issue to 3.2.
cd: This issue needs a big amount of time to find the root cause. I haven't been able to find the root cause. Due to missing time I have to shift this patch to the next release. If one thinks that this issue is a very important then raise it as a show stopper.
cd: Cannot reproduce the crash in DEV300m79. The following steps produce a "General input/output error" message. I can reproduce a similar bug. 1) Start impress. 2) Select layouts "Title, Object". 3) Click "Object" and select "Create from file". Check "Link to file" and insert a jpg file. Click "OK" button. 4) save the document 5) load the document again 6) Activate the object 7) You get a dialog with message "General input/output error" There is no crash, the document can be loaded and the object is visible after some scrolling. Therefore I lower the priority to 3 and change the summary. cd->mav: Please take over.
Changing the title according to the comment from cd. There is no resource to fix the issue for OOo 3.3, changing the target to OOo 3.4 If you believe that this issue should be fixed for OOo 3.3 as a showstopper, please send the request to the releases mailing list. If it is accepted as showstopper the target can be set to OOo3.3 again.
I can not reproduce the crash also. When I introduce a jpg file as a linked object directly, it can not indeed be stored after activation and deactivation. The problem seems to be that import jpg-filter and export jpg-filter are two different filters, so we need additional logic in the linked embedded object implementation, so that in case a pure import filter is used, the related export filter could be found. Another possibility would be to insert such linked objects as readonly.
It looks like the linked objects based on pure import filters should be opened readonly. It is no problem to find the related export filter usually, but most of them need additional filter options, and the default set is very often not the base choice. Thus, such overwriting could lead to information loss. I am not sure that we need the possibility to edit such links at all ( it was never possible till now ), but if we need it, it would be actually a new feature. For now the only acceptable fix for the bug that I see, is to let the pure import filter based links be opened readonly. Fixed in fwk160.
mav->cgu: Please verify the issue.
Verified in CWS.