On Thu, Jan 2, 2020 at 1:03 PM Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>
> Nathan Hartman wrote on Thu, 02 Jan 2020 17:44 +00:00:
> > On Thu, Jan 2, 2020 at 11:35 AM Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > > Nathan Hartman wrote on Thu, Jan 02, 2020 at 10:45:25 -0500:
> > > > Regarding the one test failure I had (autoprop_tests.py 7 with
> > > > [svn x bdb]), I've had two more since, both with bdb. These are
> > > > intermittent database errors and occur in varying places. (All fsfs
> > > > tests have passed every time.)
> > >
> > > Actually, all three backtraces so far are in sbox.build(), so something like
> > > this might be useful:
> >
> > I'm a bit confused here. Yes, the Python backtraces show it coming from
> > sbox.build but aren't these being instigated by the BDB errors/panics
> > (which are reported as a E160029)?
>
> sbox.build() calls svnadmin, which exits with E160029 (and, apparently,
> SIGABRT), which becomes an uncaught Python exception, which triggers the
> stack trace, which lists sbox.build().
>
> The point is, the errors always happened during sbox.build(), never
> during any other part of the test functions [the ones listed in
> «test_list»], so you should be able to reproduce the errors much more
> quickly by running the test suite with that patch. For example, you
> could run the test suite with the older bdb, establish how many FAILs
> you get per 2000 test functions, and then upgrade bdb and try again.
>
> Makes sense?
Yes, this makes sense now. Thank you for explaining in detail.
I'll try it soon and will post my findings...
Thanks,
Nathan
Received on 2020-01-02 19:13:02 CET