I found the source of the
MultiByteFileStream(Object)>>primitiveFailed: problem on my system.
A antivirus program was checking the file while it was used by Squeak.

I googled a little and found this clue:
http://marc.info/?l=squeak-dev&m=118046065627943&w=2

All Traits test pass now and much quicker that before :-)

Cheers,
Karl


On Wed, Jan 15, 2014 at 10:24 PM, karl ramberg <karlramberg at gmail.com>wrote:

> I think I found a clue.
> I do not get a prim failed error when I revert the method
> Environment>>forgetClass:logged: to  earlier version than 12/31/2013.
>
>
> Cheers,
> Karl
>
>
>
> On Wed, Jan 15, 2014 at 9:18 PM, karl ramberg <karlramberg at gmail.com>wrote:
>
>> I don't think the issue is file handles.
>> I tested a new trunk image and got the prim failed.
>> I tested an other image I have with literally hundreds (578) of sub
>> instances of streams and got the error.
>>
>> It's just the traits tests that show the error
>>
>> Cheers,
>> Karl
>>
>>
>> On Tue, Jan 14, 2014 at 8:10 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>>
>>> Hi Frank,
>>>
>>>
>>> On Mon, Jan 13, 2014 at 11:20 PM, Frank Shearar <frank.shearar at gmail.com
>>> > wrote:
>>>
>>>> On 13 January 2014 23:42, David T. Lewis <lewis at mail.msen.com> wrote:
>>>> > On Tue, Jan 14, 2014 at 12:28:45AM +0100, Nicolas Cellier wrote:
>>>> >> 2014/1/14 karl ramberg <karlramberg at gmail.com>
>>>> >>
>>>> >> > TraitsFileOutTest is failing
>>>> >> >
>>>> >> > Correct log attached this time
>>>> >> >
>>>> >> > Cheers,
>>>> >> > Karl
>>>> >> >
>>>> >> > id:     #[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0]
>>>> >> means the file was closed...
>>>> >>
>>>> >> I observed increasing failure rate related to randomly closed change
>>>> log
>>>> >> the last few months (particularly when loading/merging with MC), it
>>>> would
>>>> >> be good to identify the root cause...
>>>> >>
>>>> >
>>>> > That sounds like exactly the problem that Frank was describing in
>>>> another
>>>> > thread. He was ending up with a corrupt changes file IIRC, and the
>>>> problems
>>>> > he described seemed to be related to primSize checks on a changes
>>>> file that
>>>> > had been closed (this would presumably be a process trying to append
>>>> to the
>>>> > changes file when some other process had closed the file stream).
>>>>
>>>> I'm relieved it's not just me, but sad that it's not just me
>>>> experiencing this. So my understanding is that changes are stored by
>>>> accessing SourceFiles at: 2. If you want a readonly copy of sources or
>>>> changes, you use CurrentReadOnlySourceFiles at: 2. I suppose the first
>>>> step is verifying that nothing referencing these _directly_ does
>>>> things like closing files (I'd be tempted to look at CROSF first.)
>>>>
>>>
>>> forgive me for not replying earlier but I needed help to track this
>>> down.  We suffered a very similar symptom a while ago at Cadence.  It turns
>>> out that in our case the issue was the system running out of file handles
>>> because it left lots of fils open.  The cause was with Monticello package
>>> loading and the fix was to use CurrentReadOnlySourceFiles more.  I'm
>>> attaching a changeset in the hope that this is the same issue and that our
>>> changeset can point you towards a fix.
>>>
>>> HTH
>>> --
>>> best,
>>> Eliot
>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140201/91d82ca6/attachment.htm