#3286 closed defect (invalid)
(RACE CONDITION, only happens for files of small size, < ~ 10KB) No file-completion signal at the receiver
Reported by: | ajay_garg | Owned by: | |
---|---|---|---|
Priority: | Unspecified by Maintainer | Milestone: | |
Component: | Sugar | Version: | 0.94.x |
Severity: | Major | Keywords: | olpc, dx3 |
Cc: | Distribution/OS: | ||
Bug Status: | Unconfirmed |
Description
- Initiate a file-transfer from the sender XO.
- "Accept" the invitation at the receiver XO.
- File gets transmitted (almost instanataneously) (note that it must be a file of small size). The file is also seen received in the journal at the receiving end.
- However, at the receiving or the sending end, there is no "Dismiss" option (that signifies end-of-transfer).
- Left with no choice, the receiver is forced to click the "Cancel" button.
- The received file in the journal, gets deleted.
Again note, that this happens only for files of small size, and that too intermittently.
The issue did not surface even once, when I tested with MP3s (of the order of Megabytes.)
This (intermittent behaviour for small files) occurs on both os883.img and dx3g091.img.
Also, see screenshots.
Attachments (6)
Change History (14)
Changed 12 years ago by ajay_garg
Changed 12 years ago by ajay_garg
comment:1 Changed 12 years ago by sascha_silbe
- Component changed from untriaged to sugar
- Distribution/OS Unspecified deleted
- Milestone changed from Unspecified by Release Team to 0.94
- Severity changed from Unspecified to Major
- Version changed from Unspecified to 0.94.x
Changed 12 years ago by ajay_garg
Changed 12 years ago by ajay_garg
comment:2 Changed 12 years ago by ajay_garg
comment:3 follow-up: ↓ 4 Changed 12 years ago by ajay_garg
Attaching the "culprit" file "init.py" (size : 860 bits), that has been used for testing.
Changed 12 years ago by ajay_garg
comment:4 in reply to: ↑ 3 Changed 12 years ago by ajay_garg
Replying to ajay_garg:
Attaching the "culprit" file "init.py" (size : 860 bits), that has been used for testing.
Pardon me.. the size is 860 bytes.
comment:5 Changed 12 years ago by ajay_garg
The changed definition for "class StreamSplicer" does work (earlier I had replaced the file only at the receiving side). After replacing the file at both the sending, AND the receiving side, I did not face the issue, even after about 30 quick-succession tests of sending and receiving the same 860 bytes "init.py" file.
The patch has been posted at http://patchwork.sugarlabs.org/patch/1132/
comment:6 Changed 12 years ago by ajay_garg
Attaching the patch, after changing patch description (courtesy Sascha)
Changed 12 years ago by ajay_garg
comment:7 Changed 10 years ago by dnarvaez
- Resolution set to invalid
- Status changed from new to closed
We are not taking patches in trac anymore. Please submit a pull request.
I need some help.
=================================================================================
Please find attached the following ::
=================================================================================
I have figured out the workflow disruption that happens in the case when the race condition is hit. It happens in
of file
After the first successful "data = input_stream.read_finish(result)" that reads in 860B, the call never comes again to "data = input_stream.read_finish(result)" that should try to read in the next (zero) bits - which would then cause the input_stream to be closed.
I tried simplifying the class definition of "class StreamSplicer(gobject.GObject)" from
#############################################################
class StreamSplicer(gobject.GObject):
#############################################################
to
#############################################################
class StreamSplicer(gobject.GObject):
#############################################################
but i still managed to get the same intermittent buggy behaviour.
=================================================================================
I am now trying to understand the backend-architecture of send-to-friend feature, and I am not able to figure out the following ::
In the call
and
in "class IncomingTransferButton" in "install/lib/python/site-packages/jarabe/frame/activitiestray.py"
we don't seem to pass any bytes, that could be written on the datastore. I have the intuition that at the time of creating the "self._ds_object" when the OPEN state callback is called, there is somehow a link established between the "self._ds_object" and the "file-transfer" channel; however, I am not sure, and neither am I able to "find" any code which might give a clue to this. (I only see "self._ds_object = datastore.create()" in "class IncomingTransferButton", with absolutely no hint of the linkage between the self._ds_object and the file-transfer-channel/socket/bytes-read-in.).
I will be grateful, if someone could please point me to any information regarding the architecture of this feature (at a technical/code level; however, I do not need any step-by-step code explanation :) ). In particular, if I can know how the linkage to "datastore.write()" and the bytes-read-in-from-the-gio.Unix.InputStream-socket is done, the pieces will fit in together.
Meanwhile, I will continue looking for any "hints in the code" to see the linkage between the "self._ds_object" and the bytes-read-in-from-the-socket.
=================================================================================