2014/1/15 Frank Shearar <frank.shearar at gmail.com>

> On 14 January 2014 19:10, 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.
>
>
Yeah, that's the problems that I most often encounter with changes files,
and for a long time:
 'no such file or directory' when opening the changes failed
I agree, most probably a simple problem of limited resources (like too many
readOnlyCopy files were opened, but not yet closed/reclaimed).
Eliot, isn't it your fault? The faster the VM, the sooner we hit the
resource limits

But I also managed to get a corrupt change log recently, could not trace
it...
I suspect that closing the original changes is a bit different than
starving of new readOnlyCopy, but who knows...


> Thanks, Eliot. From what I can make out, the MCPackage >> #snapshot in
> this filein differs from trunk's only in the "reject: [:ea | [ea
> methodClass language isNewspeakLanguage3]ifError:[false]" guard. So
> the significant part of the changeset is PackageInfo >>
> #changeRecordForOverriddenMethod:, which I've submitted to the Inbox
> as an mcz so we can all have a look.
>
> Thanks!
>
> frank
>
> > HTH
> > --
> > best,
> > Eliot
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140115/3581b851/attachment.htm