Apache OpenOffice (AOO) Bugzilla – Issue 9662
OpenOffice crashes on inserting a file having MP3 as an OLE object into another file as a linked Object
Last modified: 2013-08-07 14:43:23 UTC
Summary OpenOffice crashes on inserting a file having MP3 as an OLE object into another file as a linked Object System Configuration Platform: PC OS: WinXP, NT 5.01 Version: 2600 Steps to replicate bug 1. Open a new text document 2. Click on Insert->object, sound. 3. A file dialogue box comes up wherein you are asked to insert a file into the current document 4. insert an mp3 file (I have attached one for your convenience) 5. save this file 6. Open a new text document 7. click on Insert-> object ,OLE Object, 8. click on “create from file” and then on “Search” to find the file in which you have inserted the .mp3 object 9. Click on “ok”. This will insert the file containing the .mp3 object into the current text document 10. Click on the .mp3 icon in the current file. It’s probable that you might get an error message stating “your mp3 song’s path/ your mp3 don’t exist”. Click on ok if so 11. Now, click on any space out side the object linked 12. OpenOffice crashes and asks whether you would like to save the current file and restarts. Notes I would like to start of by saying that OLE is not functioning as it should as the object file linked is losing its connection to the destination file .Even though its being mentioned in the documentation about this problem, this should be dealt with, as soon as possible, as the functionality is not abiding by the very fundamental concept of OLE. I haven’t mentioned it as a separate bug as it seems that the developers are aware of this problem. Now, any bug which crashes OpenOffice should be looked into as they have a potential of causing serious problems. This one in particular interests me, as in a possible scenario user might link a .mp3 to his file as an OLE object and use it in some other file to have documentation of some details pertaining to that .mp3. I tried to insert a .mp3 as “OLE Object” rather than selecting “Sound” and no error occurred .But its highly probable that if a user wants to insert a .mp3 file he will use the “sound “ option rather than the “OLE object” .I tried this sequence of operation in following configuration too OS:Windows 2000 Platform: PC Same result was observed. I hope you look into this matter too. I have also tried the same with windows media files but the Writer didn’t crash in this case.
Created attachment 3803 [details] .mp3 file used
Bug replicated using teh following system configuration Platform: PC Operating System: Windows 2000 NT 5.0, WinXP NT 5.01 Version: 2190, 2600 Notes Open office crashes with any multimedia object that is inserted into another file as a linked object. I was able to replicate the author's original steps by inserted files containing the following formats as OLE objects. The formats I used to embed files using the menu sequence metioned within the parentheses a. RealMedia files (Insert->Object->Sound) & (Insert->Object- >Video) b. Quicktime files (Insert->Object->Video) c. Windows Media Player files - .wma extensions (Insert->Object->Video) d. PDF files (Insert->Object- >Plugin) e. Java classes (Insert->Object->Applet) Files containing text seem to be handled properly, although OOo crashes if an attempt is made to change the properties of the text.
Problem replicated on WinXP Home Ooo 643.
Reassigned to Michael.
Take the document I attached below. there just activate the OLE object and de-activate it -> crash. Stack: TL644MI! Container::GetObject(unsigned long) + 132 bytes SFX644MI! SfxViewShell::DiscardClients_Impl(void) + 129 bytes SFX644MI! SfxBaseController::dispose(void) + 472 bytes FWK644MI! framework::Frame::setComponent(class com::sun::star::uno::Reference<class com::sun::star::awt::XWindow> const &,class com::sun::star::uno::Reference<class com::sun::star::frame::XController> const &) + 979 bytes FWK644MI! framework::Frame::close(unsigned char) + 893 bytes SFX644MI! SfxFrame::DoClose(void) + 281 bytes SFX644MI! SfxInPlaceObject::InPlaceActivate(unsigned char) + 463 bytes SO644MI! ImplSvEditObjectProtocol::InPlaceActivate(unsigned char) + 2443 bytes SO644MI! SvEditObjectProtocol::InPlaceActivate(unsigned char) + 35 bytes SO644MI! SvInPlaceObject::DoInPlaceActivate(unsigned char) + 188 bytes SO644MI! ImplSvEditObjectProtocol::Reset2Open(void) + 242 bytes SO644MI! SvEditObjectProtocol::Reset2Open(void) + 31 bytes SW644MI! SwFEShell::FinishOLEObj(void) + 293 bytes This is a very weird way of getting a crash thus I lowerd the priority.
Created attachment 4267 [details] Test file with OLE with Sound object
It seems that OOo gets confused in its internal object<-->object relationships because embedded objects inside embedded objects are not supported. While the latter one is a fact, it should *never* cause OOo to crash.
Craches should have the highest priority, I set this task to P1.
Fixed in CWS AS5
Reopened to Reassign it.
Teassigned to me.
Reassigned to me.
Set to Fixed (in CWS AS-5)
SBA: Verified in CWS AS5
As mentioned on the qa dev list on March 5th I will close all resolved <wontfix/duplicate/worksforme/invalid> issues. Please see this posting for details.