Jeff, I modified your test code to move the data internal to the source code. I also added a configuration option to use the bzip2 compressor instead of the zlib compressor. I have attached my version of the test code, along with a Makefile. Here are some specs for my test machine: Platform: Gentoo Linux x86_64 Kernel: 2.6.19-gentoo-r5 Compiler: gcc version 4.1.1 (Gentoo 4.1.1-r3) RAM: 2 GB When I run test_zip_1_33_1, test_bzip2_1_33_1, and test_bzip2_1_34_0, all tests run successfully without any noticeable delay or memory overhead (40000 iterations). When I run test_zip_1_34_0, I see a significant memory spike that eats all of my available RAM. As the iterations increase, the delay between iterations increases. I ran this test for 20000 iterations because 40000 iterations slows my machine to a grinding halt. I did not receive a bad_alloc exception, but I would have preferred that to the near system crash that occurred! This is a showstopper to using boost_1_34_0 on my projects. Thanks for pointing it out! Justin On Thursday 03 May 2007 17:46, Jeff wrote:
Hello,
The code below works fine in 1_33, but throws a bad_alloc exception after some 10-20K iterations in 1_34_0.
Am I doing something wrong? Did the API or usage requirements change?
Thanks, Jeff