Double free from UTF
Hi, I am seeing a double free when using boost-test on: - FreeBSD 7.2-STABLE, amd64 (gcc 4.2.1) with boost 1.39 - Mac OSX 10.6.1, x86_64 (XCode 3.2, gcc 4.2) with boost 1.40 I don't see the problem on Windows XP with Visual C++ 2005 Express. A simple test case is below, just run. The _malloc_options is to make the system malloc() fill memory with 0xa5 on allocation and 0x5a on deallocation. #define BOOST_TEST_MAIN #include <boost/test/included/unit_test.hpp> #include <stdlib.h> const char* _malloc_options = "J"; BOOST_AUTO_TEST_CASE(broken) { BOOST_CHECK(true); } Output: Running 1 test case... *** No errors detected zsh: bus error (core dumped) ./a.out Stack Trace: #0 0x0000000800b1bdee in free () from /lib/libc.so.7 #1 0x000000000043e51c in boost::unit_test::framework_impl::clear (this=0x55ad20) at framework.ipp:133 #2 0x000000000043e652 in ~framework_impl (this=0x55ad20) at framework.ipp:122 #3 0x00000000004110c6 in __tcf_1 () at framework.ipp:222 #4 0x0000000800b6dbb6 in __cxa_finalize () from /lib/libc.so.7 #5 0x0000000800b1f7c7 in exit () from /lib/libc.so.7 #6 0x0000000000404595 in _start () Any ideas? Thanks, Jan Mikkelsen
janm-boost-devel@transactionware.com wrote:
Hi,
I am seeing a double free when using boost-test on:
- FreeBSD 7.2-STABLE, amd64 (gcc 4.2.1) with boost 1.39 - Mac OSX 10.6.1, x86_64 (XCode 3.2, gcc 4.2) with boost 1.40
Hi! I tried your example on 32bit Linux with boost 1.38 and 1.40 and gcc 4.4.1, 4.3.2 and 4.1.2. Everything works fine. Results are: krivenok@develop2 17:22:16 /tmp/test_bug $ cat test.cpp #define BOOST_TEST_MAIN #include <boost/test/included/unit_test.hpp> #include <stdlib.h> const char* _malloc_options = "J"; BOOST_AUTO_TEST_CASE(broken) { BOOST_CHECK(true); } krivenok@develop2 17:22:31 /tmp/test_bug $ g++-4.4.1 -Wall -I /usr/local/dev/boost-1.40.0/include/ test.cpp -o test krivenok@develop2 17:22:45 /tmp/test_bug $ ./test Running 1 test case... *** No errors detected krivenok@develop2 17:22:48 /tmp/test_bug $ g++-4.3.2 -Wall -I /usr/local/dev/boost-1.40.0/include/ test.cpp -o test krivenok@develop2 17:23:02 /tmp/test_bug $ ./test Running 1 test case... *** No errors detected krivenok@develop2 17:23:04 /tmp/test_bug $ g++-4.1.2 -Wall -I /usr/local/dev/boost-1.40.0/include/ test.cpp -o test krivenok@develop2 17:23:16 /tmp/test_bug $ ./test Running 1 test case... *** No errors detected krivenok@develop2 17:23:18 /tmp/test_bug $ g++-4.4.1 -Wall -I /usr/local/dev/boost-1.38.0/include/ test.cpp -o test /usr/local/dev/boost-1.38.0/include/boost/test/floating_point_comparison.hpp:224: warning: 'boost::test_tools::<unnamed>::check_is_close' defined but not used /usr/local/dev/boost-1.38.0/include/boost/test/floating_point_comparison.hpp:246: warning: 'boost::test_tools::<unnamed>::check_is_small' defined but not used krivenok@develop2 17:23:41 /tmp/test_bug $ ./test Running 1 test case... *** No errors detected krivenok@develop2 17:23:43 /tmp/test_bug $ g++-4.3.2 -Wall -I /usr/local/dev/boost-1.38.0/include/ test.cpp -o test /usr/local/dev/boost-1.38.0/include/boost/test/floating_point_comparison.hpp:224: warning: 'boost::test_tools::<unnamed>::check_is_close' defined but not used /usr/local/dev/boost-1.38.0/include/boost/test/floating_point_comparison.hpp:246: warning: 'boost::test_tools::<unnamed>::check_is_small' defined but not used krivenok@develop2 17:23:54 /tmp/test_bug $ ./test Running 1 test case... *** No errors detected krivenok@develop2 17:23:56 /tmp/test_bug $ g++-4.1.2 -Wall -I /usr/local/dev/boost-1.38.0/include/ test.cpp -o test krivenok@develop2 17:24:10 /tmp/test_bug $ ./test Running 1 test case... *** No errors detected krivenok@develop2 17:24:15 /tmp/test_bug $ I will try it on amd64 later.
I don't see the problem on Windows XP with Visual C++ 2005 Express.
A simple test case is below, just run. The _malloc_options is to make the system malloc() fill memory with 0xa5 on allocation and 0x5a on deallocation.
#define BOOST_TEST_MAIN #include <boost/test/included/unit_test.hpp> #include <stdlib.h>
const char* _malloc_options = "J";
BOOST_AUTO_TEST_CASE(broken) { BOOST_CHECK(true); }
Output:
Running 1 test case...
*** No errors detected zsh: bus error (core dumped) ./a.out
Stack Trace:
#0 0x0000000800b1bdee in free () from /lib/libc.so.7 #1 0x000000000043e51c in boost::unit_test::framework_impl::clear (this=0x55ad20) at framework.ipp:133 #2 0x000000000043e652 in ~framework_impl (this=0x55ad20) at framework.ipp:122 #3 0x00000000004110c6 in __tcf_1 () at framework.ipp:222 #4 0x0000000800b6dbb6 in __cxa_finalize () from /lib/libc.so.7 #5 0x0000000800b1f7c7 in exit () from /lib/libc.so.7 #6 0x0000000000404595 in _start ()
Any ideas?
Thanks,
Jan Mikkelsen _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sep 22, 2009, at 09:30 , Dmitry V. Krivenok wrote:
janm-boost-devel@transactionware.com wrote:
Hi, I am seeing a double free when using boost-test on: - FreeBSD 7.2-STABLE, amd64 (gcc 4.2.1) with boost 1.39 - Mac OSX 10.6.1, x86_64 (XCode 3.2, gcc 4.2) with boost 1.40
Hi!
I tried your example on 32bit Linux with boost 1.38 and 1.40 and gcc 4.4.1, 4.3.2 and 4.1.2. Everything works fine.
Known issue on Mac OS X 10.6. I have the same problem. https://svn.boost.org/trac/boost/ticket/3432 Stephen
S Roderick wrote:
On Sep 22, 2009, at 09:30 , Dmitry V. Krivenok wrote:
janm-boost-devel@transactionware.com wrote:
Hi, I am seeing a double free when using boost-test on: - FreeBSD 7.2-STABLE, amd64 (gcc 4.2.1) with boost 1.39 - Mac OSX 10.6.1, x86_64 (XCode 3.2, gcc 4.2) with boost 1.40
Hi!
I tried your example on 32bit Linux with boost 1.38 and 1.40 and gcc 4.4.1, 4.3.2 and 4.1.2. Everything works fine.
Known issue on Mac OS X 10.6. I have the same problem.
I believe this is now resolved. Gennadiy
Hi Gennadiy, On Tuesday 29 September 2009, Gennadiy Rozental wrote:
I believe this is now resolved.
No, after your last commit I get: /home/hunold/packages/boost/boost/test/impl/framework.ipp: In member function 'void boost::unit_test::framework_impl::clear()': /home/hunold/packages/boost/boost/test/impl/framework.ipp:131: error: 'test_id_2_unit_type' was not declared in this scope Seems something is still missing... And as mentioned in another thread, using virtual destructors and getting rid of the (now even old-style casts :-(( ) might be a much better idea. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
Hi Gennadiy, On Tuesday 29 September 2009, Juergen Hunold wrote:
No, after your last commit I get:
/home/hunold/packages/boost/boost/test/impl/framework.ipp: In member function 'void boost::unit_test::framework_impl::clear()': /home/hunold/packages/boost/boost/test/impl/framework.ipp:131: error: 'test_id_2_unit_type' was not declared in this scope
Seems something is still missing...
I should first grep and then mail ;-)) Please find the patch attached, test_id_2_unit_type was not fully qualified with the "ut_detail::" namespace. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
On Tue, Sep 29, 2009 at 08:12:39AM +0200, Juergen Hunold wrote:
And as mentioned in another thread, using virtual destructors and getting rid of the (now even old-style casts :-(( ) might be a much better idea.
I second this. The current code using an "if" statement and down casting seems stunningly bad design, to me. What's wrong with the straightforward polymorphic approach? See https://svn.boost.org/trac/boost/attachment/ticket/2647/boost-test-invalid-r... -S
Steve M. Robbins <steve <at> sumost.ca> writes:
On Tue, Sep 29, 2009 at 08:12:39AM +0200, Juergen Hunold wrote:
And as mentioned in another thread, using virtual destructors and getting rid of the (now even old-style casts ( ) might be a much better idea.
I second this. The current code using an "if" statement and down casting seems stunningly bad design, to me. What's wrong with the straightforward polymorphic approach?
Cause there is nothing polymorphic about the test_unit/test_case class usage. Gennadiy
Juergen Hunold <juergen.hunold <at> ivembh.de> writes:
Hi Gennadiy,
On Tuesday 29 September 2009, Gennadiy Rozental wrote:
I believe this is now resolved.
No, after your last commit I get:
/home/hunold/packages/boost/boost/test/impl/framework.ipp: In member function 'void boost::unit_test::framework_impl::clear()': /home/hunold/packages/boost/boost/test/impl/framework.ipp:131: error: 'test_id_2_unit_type' was not declared in this scope
Right. Fixed now. I was testing with 1.39
Seems something is still missing...
And as mentioned in another thread, using virtual destructors and getting rid of the (now even old-style casts ( ) might be a much better idea.
You can read my reply there. By the way, I am not a language lawyer, but it seems that the fact that making destructor virtual resolved the issue is just a coincidence. In other words with slightly different compiler implementation I see nothing preventing it to generate the same problem in case of virtual destructor. Gennadiy
Hi Gennadiy On Tuesday 29 September 2009, Gennadiy Rozental wrote:
Juergen Hunold <juergen.hunold <at> ivembh.de> writes:
And as mentioned in another thread, using virtual destructors and getting rid of the (now even old-style casts ( ) might be a much better idea.
You can read my reply there. By the way, I am not a language lawyer, but it seems that the fact that making destructor virtual resolved the issue is just a coincidence. In other words with slightly different compiler implementation I see nothing preventing it to generate the same problem in case of virtual destructor.
Okay, point taken. But why do you use old-style casts instead of the static_cast<>s you used before ? This will make it difficult to compile the "included"-Variant using "- Wold-style-cast". I'm quite surprised that you use those casts at all. This is worrying me as "modern" casts tend to prevent subtle bugs. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
Hi Gennadiy, On Wednesday 30 September 2009 17:10:45 Gennadiy Rozental wrote:
Juergen Hunold <juergen.hunold <at> ivembh.de> writes:
Okay, point taken. But why do you use old-style casts instead of the static_cast<>s you used before ?
Umm. Not sure. Did I? Ok. I'll change that.
Thanks. Please find a patch attached which my coworker developed for inclusion into our 3rdparty-Repository. Ok to commit ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
participants (6)
-
Dmitry V. Krivenok -
Gennadiy Rozental -
janm-boost-devel＠transactionware.com -
Juergen Hunold -
S Roderick -
Steve M. Robbins