| Thread Previous • Date Previous • Date Next • Thread Next |
After discussions with Matthias, I have proposed a fix for this problem.
The gist of the problem is that we did not previously have a situation
where two items would both want to claim ownership of the same stream;
in this case, a streamable base64 item was being used to create a
streamable string item. The fix was to introduce a different factory for
StreamableStringItem that takens a 'dependent' streamable item. The new
item shares the istream from the dependent item, but NOT the
StreamReleaser, and so the new item does not attempt to take ownership
of the stream. However, the new item does maintain a reference to the
original item, thus forcing the lifespan of the original item to be as
long as its own. In this way they can share the stream without having to
worry about which one will be destroyed first. I added Dennis's test
case and confirmed that it runs fine with this change.
** Changed in: zorba
Status: New => In Progress
--
You received this bug notification because you are a member of Zorba
Coders, which is the registrant for Zorba.
https://bugs.launchpad.net/bugs/996084
Title:
crash in Streamable*Item with file module
Status in Zorba - The XQuery Processor:
In Progress
Bug description:
I was trying to
1. read a data file
2. get the md5 of the file content
3. return both the md5 and content in one XML node:
<file><md5>...</md5><data>...</data></file>
Executing the complete example (see attachment) with any data.txt file
leads to a crash. It seems that the streamreleaser in
~StreamableBase64BinaryItem() and ~StreamableStringItem() tries to
delete the same ifstream.
To manage notifications about this bug go to:
https://bugs.launchpad.net/zorba/+bug/996084/+subscriptions
| Thread Previous • Date Previous • Date Next • Thread Next |
