Opened 14 years ago
Closed 14 years ago
#140 closed defect (fixed)
crash when joining a shared Read
Reported by: | gdesmott | Owned by: | tomeu |
---|---|---|---|
Priority: | blocker | Milestone: | |
Component: | Read | Version: | |
Severity: | Keywords: | ||
Cc: | morgs, marcopg | Distribution/OS: | |
Bug Status: |
Description
Got this crash when joining a shared instance. Something *could* have been wrong during the transfer (I'm debugging sock5 stream tubes) but Read shoudn't crash anyway.
Attachments (1)
Change History (5)
Changed 14 years ago by gdesmott
comment:1 Changed 14 years ago by morgs
- Cc tomeu added
comment:2 Changed 14 years ago by morgs
- Cc morgs marcopg added; tomeu removed
- Owner changed from morgs to tomeu
- Status changed from new to assigned
comment:3 Changed 14 years ago by tomeu
- Priority changed from minor to blocker
comment:4 Changed 14 years ago by tomeu
- Resolution set to fixed
- Status changed from assigned to closed
I think I got it, please retest.
Note: See
TracTickets for help on using
tickets.
This seems to be an issue in the (new) datastore.
I reproduced it now with Read, using two sugar-jhbuild sessions.
Session A shared Read with a PDF file, over salut. Session B joined, and failed. The following is all from session B.
The top of the Read log contained:
The first issue is that the file referenced is left over from a previous activity - note the earlier date of d62..ee.txt:
It contains metadata from Browse:
The next problem is that Read tries to resume this entry, even though we are joining a different activity. The Read log shows:
This all might be the same issue as when we saw recent problems with Marco sharing Write, and me seeing Browse metadata in the document when joining instead of the Write document. It seems the datastore is providing a file to resume from some unrelated previous activity, when you are expecting to join an activity and start a new file.
Anyway, evince fails to load the document so we continue. The failure which Guillaume and I ultimately experienced seems to be a result of the above, as Read has the following code:
The expected code path on joining is the first option, creating a temporary filename for the download to be saved as, but the second option happened, populating the filename with the existing datastore entry.
Read then downloaded the PDF into that file. I expected it to be ~/.sugar/two/org.laptop.sugar.ReadActivity/instance/tmp1230065496 but the file was saved as ~/.sugar/two/data/d6244570-41a2-4857-8bf2-e208b94505ee_3.txt which was then presumably clobbered by the datastore write. That file was then presumed to be intact, which it normally is at that point, and evince failed to load it.
Read log:
So in summary: The Read sharing download worked fine, but something provided the activity with the wrong datastore id when it wasn't supposed to be resuming at all, leading to all kinds of fail.