Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | private:stream - load component from ByteArray crashes aoo34 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | General | Reporter: | Oliver Brinzing <oliver.brinzing> | ||||||||
Component: | scripting | Assignee: | AOO issues mailing list <issues> | ||||||||
Status: | CONFIRMED --- | QA Contact: | |||||||||
Severity: | Normal | ||||||||||
Priority: | P3 | CC: | arielch, Armin.Le.Grand, awf.aoo, doneyourself, hanya.runo, hdu, jsc, oliver.brinzing | ||||||||
Version: | 3.4.0 | Flags: | jsc:
4.0.0_release_blocker-
|
||||||||
Target Milestone: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | All | ||||||||||
Issue Type: | DEFECT | Latest Confirmation in: | 3.4.1 | ||||||||
Developer Difficulty: | --- | ||||||||||
Attachments: |
|
Description
Oliver Brinzing
2012-06-09 14:13:04 UTC
Created attachment 78217 [details]
private-stream-storage-test
added a java example to show the problem
Comment on attachment 78217 [details]
private-stream-storage-test
Confirming the java example.
Besides the fact, that writer and not calc opens the stream, oo is crashing while closing the document.
Created attachment 78267 [details]
stack for the reported crash
The stack points at a malfunction while grammar checking a document that was just closed because of a bad access by SvtListener* methods.
The call in frame 4 at main/sfx2/source/view/viewfrm.cxx:1659 looks suspicious. It should call into SfxViewFrame::GetObjectShell() but since it calls the SvtBroadcaster destructor instead this must mean that the object pointed to by pFrame is already bad. @hdu: do you have a fix for that issue? (In reply to comment #5) > @hdu: do you have a fix for that issue? I don't know where this idea comes from. Providing the stack-trace and doing a first analysis indicated that the crash didn't come from any parts of the code I'm familiar with. could this issue be fixed in aoo3.5? rev 1400866 crashes too. Created attachment 80485 [details]
Basic version of the Java code
The code is the same, but in Basic. It does not crash.
REM ***** BASIC *****
Option Explicit
Sub Main
Dim oFactory as Object
oFactory = CreateUnoService("com.sun.star.embed.StorageFactory")
Dim oStorage as Object
oStorage = oFactory.createInstance()
Dim oStream as Object
oStream = oStorage.openStreamElement("test", com.sun.star.embed.ElementModes.READWRITE)
Dim oOutputStream as Object
oOutputStream = oStream.getOutputStream()
Dim nContent%(8)
nContent(0) = 72
nContent(1) = 9
nContent(2) = 69
nContent(3) = 9
nContent(4) = 76
nContent(5) = 9
nContent(6) = 76
nContent(7) = 9
nContent(8) = 79
oOutputStream.writeBytes(nContent)
oOutputStream.flush()
oOutputStream.closeOutput()
Dim oMediaDesc(2) as new com.sun.star.beans.PropertyValue
oMediaDesc(0).Name = "InputStream"
oMediaDesc(0).Value = oStream.getInputStream()
oMediaDesc(1).Name = "FilterName"
oMediaDesc(1).Value = "Text - txt - csv (StarCalc)"
oMediaDesc(2).Name = "FilterOptions"
oMediaDesc(2).Value = "9,0,0,1"
Dim oDoc
oDoc = StarDesktop.loadComponentFromURL("private:stream","_blank",0,oMediaDesc)
oStream.getInputStream().closeInput()
oStorage.dispose()
End Sub
(In reply to comment #8) > Created attachment 80485 [details] > Basic version of the Java code There are some bugs: a) it opens in Writer, filter settings in the media descriptor are ignored, this is bug 121982 b) the content loaded is more than what there is on the input stream: H E L L O################################### the last characters seem garbage in the buffer used to read from the input stream. ALG: I do not know about this stuff, but is there not a missing nContent(9) = 9 ? @Armin: no, the 9 is a TAB used as separator between characters not as delimiter. @brinzing: Did you, by any chance, use a non-pro version of AOO? I can reproduce a crash in my non-pro developer version but probably not THE crash. My crash comes from the destructor of the VCL Window class and is triggered by the "Window with living Child(s) destroyed" check. Maybe the follow up bug 121982 is the trigger of this bug. The given data (the "72,9,69,9,76,9,76,9,79" array in the first Basic script) is not interpreted as CSV data but as some form of Writer document. The trailing "###################################" is the first indication that something is wrong. My observation of "living Child(s) destroyed" is the second. The crash described in the bug description may just be another one. I am just not convinced that this bug should be a release stopper. It is not something that the ordinary user will experience. We might also try to find out why the first BASIC macro leads to a crash and the second does not. remove showstopper request This problem is triggered by the client code and seems to work in Basic. Needs further investigation and the issues exists already in version 3.3 If a usable and uncritical solution will be provided in time I will grant the showstopper flag. This can open from the bytes into spreadsheet. Sub CSVFromStream aBytes = Array(72,9,69,9,76,9,76,9,79) oInputStream = com.sun.star.io.SequenceInputStream.createStreamFromSequence(aBytes) Dim oMediaDesc(2) as new com.sun.star.beans.PropertyValue oMediaDesc(0).Name = "InputStream" oMediaDesc(0).Value = oInputStream oMediaDesc(1).Name = "FilterName" oMediaDesc(1).Value = "Text - txt - csv (StarCalc)" oMediaDesc(2).Name = "FilterOptions" oMediaDesc(2).Value = "9,0,0,1" Dim oDoc oDoc = StarDesktop.loadComponentFromURL("private:stream","_blank",0,oMediaDesc) End Sub (In reply to hanya from comment #15) > This can open from the bytes into spreadsheet. > > Sub CSVFromStream With this, during the detection of the file type in ScFilterDetect::detect, lcl_MayBeAscii function returns true because rStream.Read results always zero. The passed stream to the lcl_MayBeAscii function is not reset the error happen in SotStorage ctor. In the SotStorage ctor, Storage instance is created and it tries to read file header in StgHeader::Load method. aBytes only have 9 bytes in the macro, and some operator>> call goes to wrong SvStream::nBufActualPos in the StgHeader::Load method. The error code 530 (SVSTREAM_SEEK_ERROR) of the stream is not reset in the detect method. SvStream::GetData method returns zero in lcl_MayBeAscii function because the error is not reset. When I make aBytes longer than about 128 bytes, the error not happen. And with Test_loadComponentFromByteArray in Description, aBytes contains only 9 bytes but rStream.Read method returns 29 bytes in lcl_MayBeAscii funciton. 9-29 bytes contains \0, so the stream is decided as non ascii. Once I made aBytes longer like in the above comment 16, it worked well. |