On Wed, 2017-01-25 at 14:31 -0800, James E Keenan via RT wrote: > On Wed, 25 Jan 2017 19:44:02 GMT, john@nixnuts.net wrote: > > On Wed, 2017-01-25 at 08:12 -0800, James E Keenan via RT wrote: > > > > > > On FreeBSD-11, I get the same difference in results between > > > with/without > > > -DDEBUGGING. > > > > > > On Linux, with -DDEBUGGING, the test file eventually completes ... > > > but clearly > > > hangs for some time after 'ok 21' and takes 30s to run. > > > > > > So the patch does not play well with -DDEBUGGING regardless of OS. > > > > > > Thank you very much. > > > > I'm attaching an updated patch that croaks before these oversized > > New() calls > > rather than trying to handle the failures they generate. > > On Linux, with a -DDEBUGGING build, the runtime of the test came down to a > reasonable length. > > However on both FreeBSD 10 and 11, the results under -DDEBUGGING were still > unsatisfactory. Running the test manually on 10.3, I had to Ctrl-C the test > after 2 minutes. Running smoke tests on 11, it appears that the test > completed successfully once but then got the same swap errors previously > reported, leading to the curious result of "PASS-so-far": > http://perl5.test-smoke.org/report/53487 I brought up a FreeBSD 10.3 AMD64 VM to test and saw a similar issue when I ran the new unit test with the older version of Storable. The long pause on BSD seemed to be caused by coredumps being enabled (default on FreeBSD, not default on Linux.) I didn't see any crashes on the FreeBSD VM when testing blead with the new version of the patch. The configure settings I used were: ./Configure -des -DDEBUGGING -Dusedevel Is it possible that some of the failures you're seeing were caused by using the wrong version of Storable?Thread Previous | Thread Next