On Thu, Jan 2, 2020 at 1:03 PM Daniel Shahaf <d...@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...@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
