I changed the subject:
Followup-to: mozilla.dev.platform

On 2015/05t/29 16:41, ishikawa wrote:
> Hi,
> 
> I have been testing locally built FULL DEBUG C-C thunderbird using |make
> mozmill| test suite.
> 
> When I tinkered with low-level I/O testing by simulating "short read",
> I saw about a couple of dozen new errors in |make mozmill|.
> I already fixed a few to take care of the unhandled "short read" situations.
> 
> (Turns out, "short write" is handled (at least on Posix), by pt_Write by
> retrying automatically.)
> 
> Among the new errors that puzzled me is "Hightail" test.
> When I simulated short reads, I began experiencing errors from
> test-cloudfile-backend-hightail.js.
> 
> Well, I thought that would be another
> debugging session, but I had no idea where to start.
> 
> But then, I noticed a posting in
> mozilla-support-thunderb...@lists.mozilla.org
> (or mozilla.support.thunderbird )
> message ID:
> <mailman.123.1432754945.30853.support-thunderb...@lists.mozilla.org>
> Subject: Re: Have we lost You Send It / Hightail?
> From: WaltS48 <thalion...@removeaim.com>
> 
> That says:
>>
>>> We have reached an agreement with Box to integrate their services directly 
>>> into Thunderbird. The agreement with Hightail is no longer valid.
>>
>> REF: 
>> <https://support.mozilla.org/en-US/kb/filelink-large-attachments#w_filelink-faq>
>>
>> There is a list of extensions for other providers on that page.
> 
> Could that mean I don't have to pay much attention to "hightail" test any 
> more?
> (But |make mozmill| suggests that
> C-C TB seems to talk to the fake simulated hightail server(?) rather well
> if I don't introduce simulated "short read", and that puzzles me to no end.)
> 
> TIA
> 

Hi,

I figured out the particular cause of
test-cloudfile-backend-hightail.js.
experienced during |make mozmill| when I simulated "short read" and
"short write" to files
under the profile directory used by the test was that
*.db files managed by Berkeley DB 1.85 (presumably by the code below
mozilla/security/nss/lib/dbm/src/) experienced failures.

That is, the code in mozilla/security/nss/lib/dbm/src/
does not handle the case such as files in remote mount may experience
short read (read() system call returning shorter than expected
characters although enough octets are there to read), or write() system
call returning before all the characters are written.

As a result of my injection of short read/write, the data in these files
during test set up got messed up, and
the intended test did not run successfully.

The DB files used during tests were three files as follows:
My MOZOBJ is /REF-OBJ-DIR/objdir-tb3:

    "_tests/mozmill/mozmillprofile/cert8.db",
    "_tests/mozmill/mozmillprofile/key3.db",
    "_tests/mozmill/mozmillprofile/secmod.db"

below my MOZOBJ directory.

After exempting these *.db files from my simulated short read/write,
the tests passed (!).

I noticed the strange I/O to secomod.db first, and figured out it can't
cope with short read/write at all
after reading the source code. So I exempted cert8.db and key3.db, too.

I suspect that anyone who has mounted the profile directory from remote
file system may experience such transient short read/wrte failures.
I now recall seeing such bugzilla entries from people who seem to have a
corrupt db(!) Hmm, but I can find a relevant entry now.

I will check if exempting these *.db files cause OTHER new failures,
which were introduced after short read/write emulation, to disappear.

If so, this is a compelling reason to update the dbm (or db) code
to a newer one. ( I noticed we only use HASH version of db.)

However, now that Sleepycat has been bought by Oracle, I am not sure
what is the good option left.

http://www.oracle.com/us/products/database/berkeley-db/overview/index.html

At least, Oracle seems to give us the source code, but the license-wise,
I am not sure if its fits mozilla's needs.

In the meantime, the failure to handle short read/write which may occur
due to remotely mounted file system is very bad considering the effect
it has on |make mozmill| test.

TIA
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to