googletest - Project Hosting on Google Code

Last 7 days Dec 23, 2009 r357 (Removes support for MSVC 7.1 from the scons scripts. ) committed by zhanyong.wan - Removes support for MSVC 7.1 from the scons scripts. Removes support for MSVC 7.1 from the scons scripts. Dec 23, 2009 issue 108 (Running with valgrind gives a bunch of errors : Conditional ...) Status changed by w...@google.com - The error comes from strlen(), a standard libc function. I suspect it's caused by compiling gtest and your test using different compiler versions/settings. I recommend to compile your own gtest library with the same compiler settings as you use to compile your test, instead of using the installed gtest. Status: Invalid The error comes from strlen(), a standard libc function. I suspect it's caused by compiling gtest and your test using different compiler versions/settings. I recommend to compile your own gtest library with the same compiler settings as you use to compile your test, instead of using the installed gtest. Status: Invalid Dec 23, 2009 issue 111 (MSVC main project misses some headers) Status changed by w...@google.com - We are switching from manually-maintained VS projects to CMake. Status: WontFix We are switching from manually-maintained VS projects to CMake. Status: WontFix Dec 23, 2009 issue 7 (Add a function with extern "C" linkage) commented on by w...@google.com - @dirk.mst, you are right that the two are different things. That's why I didn't close the issue as "won't fix". Some users of gtest choose autotools because gtest uses it. After we switch away from autotools, such users won't have a reason to use autotools any more. Therefore the priority of this is lowered. @dirk.mst, you are right that the two are different things. That's why I didn't close the issue as "won't fix". Some users of gtest choose autotools because gtest uses it. After we switch away from autotools, such users won't have a reason to use autotools any more. Therefore the priority of this is lowered. Dec 22, 2009 issue 7 (Add a function with extern "C" linkage) commented on by dirk.mst - @w...@google.com The version function is an improvement for uses of gtest that use autotools (or other build tools like scons). As I see it, it is not related to the build system used by gtest itself. @w...@google.com The version function is an improvement for uses of gtest that use autotools (or other build tools like scons). As I see it, it is not related to the build system used by gtest itself. Dec 22, 2009 issue 236 (configure.ac:29: error: possibly undefined macro: AC_PROG_LI...) Status changed by w...@google.com - We are switching away from autotools. Status: WontFix We are switching away from autotools. Status: WontFix Dec 22, 2009 issue 220 (warning: declaration of 'c_str' shadows a member of 'this' ) Status changed by w...@google.com - Status: Fixed Status: Fixed Dec 22, 2009 issue 183 (gtest.m4: configure fails when --enable-gtest is absent) Status changed by w...@google.com - We are switching away from autotools. Status: WontFix We are switching away from autotools. Status: WontFix Dec 22, 2009 issue 168 (Need better test coverage of gtest-death-test.cc) Status changed by w...@google.com - I believe death tests have adequate test coverage. Status: WontFix I believe death tests have adequate test coverage. Status: WontFix Dec 22, 2009 issue 120 (gtest-config man page) Status changed by w...@google.com - No more work on improving the autotools scripts. Status: WontFix No more work on improving the autotools scripts. Status: WontFix Dec 22, 2009 issue 110 (need to speed up the autotools build script) Status changed by w...@google.com - The autotools scripts have already been significantly trimmed. Status: WontFix The autotools scripts have already been significantly trimmed. Status: WontFix Dec 22, 2009 issue 101 (gtest-config does not work with non-absolute prefix path) Status changed by w...@google.com - We are phasing out autotools. Status: WontFix We are phasing out autotools. Status: WontFix Dec 22, 2009 issue 92 (Faulty M4 Macro) Status changed by w...@google.com - We won't spend more time on improving the autotools scripts. Status: WontFix We won't spend more time on improving the autotools scripts. Status: WontFix Dec 22, 2009 issue 44 (uncaught exceptions thrown by a unit test should be reported...) Labels changed by w...@google.com - Increased priority due to user requests. Labels: Priority-High Usability −Priority-Medium Increased priority due to user requests. Labels: Priority-High Usability −Priority-Medium Dec 22, 2009 issue 7 (Add a function with extern "C" linkage) Labels changed by w...@google.com - Lower the priority since autotools is being phased out. Labels: Priority-Low Usability −Priority-Medium Lower the priority since autotools is being phased out. Labels: Priority-Low Usability −Priority-Medium Dec 22, 2009 issue 236 (configure.ac:29: error: possibly undefined macro: AC_PROG_LI...) commented on by w...@google.com - The makefile/ folder contains a Makefile. You can use that instead of autotools. I've made some progress on the CMake scripts. I'll try to commit them to the SVN soon s.t. people can play with them. The makefile/ folder contains a Makefile. You can use that instead of autotools. I've made some progress on the CMake scripts. I'll try to commit them to the SVN soon s.t. people can play with them. Dec 22, 2009 r356 (Adds macro GTEST_DISALLOW_ASSIGN_, needed by gmock. ) committed by zhanyong.wan - Adds macro GTEST_DISALLOW_ASSIGN_, needed by gmock. Adds macro GTEST_DISALLOW_ASSIGN_, needed by gmock. Dec 22, 2009 issue 213 (gtest-port_test.cc uses testing::Types unconditionally) commented on by maciej.blizinski - There might be a problem with test/gtest-port_test.cc: if GTEST_USES_POSIX_RE is set and GTEST_HAS_TYPED_TEST unset, no regex tests are compiled: #if GTEST_USES_POSIX_RE && (GTEST_HAS_TYPED_TEST \|\| GTEST_HAS_TYPED_TEST_P) ...not compiled, because GTEST_HAS_TYPED_TEST is unset #elif GTEST_USES_SIMPLE_RE ...not compiled, because GTEST_USES_SIMPLE_RE is unset #endif // GTEST_USES_POSIX_RE There might be a problem with test/gtest-port_test.cc: if GTEST_USES_POSIX_RE is set and GTEST_HAS_TYPED_TEST unset, no regex tests are compiled: #if GTEST_USES_POSIX_RE && (GTEST_HAS_TYPED_TEST \|\| GTEST_HAS_TYPED_TEST_P) ...not compiled, because GTEST_HAS_TYPED_TEST is unset #elif GTEST_USES_SIMPLE_RE ...not compiled, because GTEST_USES_SIMPLE_RE is unset #endif // GTEST_USES_POSIX_RE Dec 22, 2009 issue 239 (gtest should treat - as _ when parsing command line flags) reported by w...@google.com - --gtest-list-tests should work the same as --gtest_list_tests --gtest-list-tests should work the same as --gtest_list_tests Dec 22, 2009 issue 238 (gtest-port_test.cc tries to use testing::Types without looki...) changed by w...@google.com - Status: Duplicate Status: Duplicate Dec 22, 2009 issue 213 (gtest-port_test.cc uses testing::Types unconditionally) commented on by w...@google.com - Issue 238 has been merged into this issue. Issue 238 has been merged into this issue. Dec 22, 2009 issue 238 (gtest-port_test.cc tries to use testing::Types without looki...) reported by maciej.blizinski - What steps will reproduce the problem? 1a. Set GTEST_HAS_TYPED_TEST to 0 and GTEST_USES_POSIX_RE to 1 1b. ...or try to compile with the Sun Studio compiler What is the expected output? What do you see instead? I would expect the code to check whether it can use testing::Types. The compilation fails, "testing::Types is not a member of testing". What version of the product are you using? On what operating system? Linux, with the Sun Studio 12 compiler. Here's a possible check for the issue: diff --git a/test/gtest-port_test.cc b/test/gtest-port_test.cc index df59f9e..e36cbe4 100644 --- a/test/gtest-port_test.cc +++ b/test/gtest-port_test.cc @@ -164,6 +164,10 @@ TEST(GtestCheckDeathTest, LivesSilentlyOnSuccess) { template <typename Str> class RETest : public ::testing::Test {}; +// testing::Types is only available when GTEST_HAS_TYPED_TEST is set +#if !GTEST_HAS_TYPED_TEST +# error "Need GTEST_HAS_TYPED_TEST for testing::Types" +#endif // Defines StringTypes as the list of all string types that class RE // supports. typedef testing::Types< I also thought of using this: #if GTEST_USES_POSIX_RE && GTEST_HAS_TYPED_TEST ...but if GTEST_USES_POSIX_RE is set and GTEST_HAS_TYPED_TEST unset, no regex tests are compiled: #if GTEST_USES_POSIX_RE && GTEST_HAS_TYPED_TEST ...not compiled, because GTEST_HAS_TYPED_TEST is unset #elif GTEST_USES_SIMPLE_RE ...not compiled, because GTEST_USES_SIMPLE_RE is unset #endif // GTEST_USES_POSIX_RE What steps will reproduce the problem? 1a. Set GTEST_HAS_TYPED_TEST to 0 and GTEST_USES_POSIX_RE to 1 1b. ...or try to compile with the Sun Studio compiler What is the expected output? What do you see instead? I would expect the code to check whether it can use testing::Types. The compilation fails, "testing::Types is not a member of testing". What version of the product are you using? On what operating system? Linux, with the Sun Studio 12 compiler. Here's a possible check for the issue: diff --git a/test/gtest-port_test.cc b/test/gtest-port_test.cc index df59f9e..e36cbe4 100644 --- a/test/gtest-port_test.cc +++ b/test/gtest-port_test.cc @@ -164,6 +164,10 @@ TEST(GtestCheckDeathTest, LivesSilentlyOnSuccess) { template <typename Str> class RETest : public ::testing::Test {}; +// testing::Types is only available when GTEST_HAS_TYPED_TEST is set +#if !GTEST_HAS_TYPED_TEST +# error "Need GTEST_HAS_TYPED_TEST for testing::Types" +#endif // Defines StringTypes as the list of all string types that class RE // supports. typedef testing::Types< I also thought of using this: #if GTEST_USES_POSIX_RE && GTEST_HAS_TYPED_TEST ...but if GTEST_USES_POSIX_RE is set and GTEST_HAS_TYPED_TEST unset, no regex tests are compiled: #if GTEST_USES_POSIX_RE && GTEST_HAS_TYPED_TEST ...not compiled, because GTEST_HAS_TYPED_TEST is unset #elif GTEST_USES_SIMPLE_RE ...not compiled, because GTEST_USES_SIMPLE_RE is unset #endif // GTEST_USES_POSIX_RE Dec 21, 2009 issue 237 (EXPECT_DEATH test passes but leaves a dumped core from spawn...) commented on by nate.bauernfeind - In case anyone else comes here looking for a solution I'll post what I've decided to go with. This works on linux and is likely not portable: Index: gtest-death-test.cpp ==================================================== =============== --- gtest-death-test.cpp (revision 60319) +++ gtest-death-test.cpp (working copy) @@ -990,6 +990,11 @@ // This function is called in a clone()-ed process and thus must avoid // any potentially unsafe operations like malloc or libc functions. static int ExecDeathTestChildMain(void* child_arg) { + rlimit core_limit; + core_limit.rlim_cur = 0; + core_limit.rlim_max = 0; + setrlimit(RLIMIT_CORE, &core_limit); + ExecDeathTestArgs* const args = static_cast<ExecDeathTestArgs>(child_arg); GTEST_DEATH_TEST_CHECK_SYSCALL_(close(args->close_fd)); In case anyone else comes here looking for a solution I'll post what I've decided to go with. This works on linux and is likely not portable: Index: gtest-death-test.cpp ==================================================== =============== --- gtest-death-test.cpp (revision 60319) +++ gtest-death-test.cpp (working copy) @@ -990,6 +990,11 @@ // This function is called in a clone()-ed process and thus must avoid // any potentially unsafe operations like malloc or libc functions. static int ExecDeathTestChildMain(void child_arg) { + rlimit core_limit; + core_limit.rlim_cur = 0; + core_limit.rlim_max = 0; + setrlimit(RLIMIT_CORE, &core_limit); + ExecDeathTestArgs* const args = static_cast<ExecDeathTestArgs>(child_arg); GTEST_DEATH_TEST_CHECK_SYSCALL_(close(args->close_fd)); Dec 21, 2009 issue 237 (EXPECT_DEATH test passes but leaves a dumped core from spawn...) changed by w...@google.com - It's impossible for gtest to anticipate all possible side effects in a death test and clean them up. Instead, it's the test author's responsibility to ensure that the tests clean up after themselves. Some people may even find the core dump useful. Please try to rewrite your test to disable core dump. You can see 'man core' on how to do it. Status: WontFix Labels: Type-Enhancement Priority-Low OpSys-Linux Usability −Type-Defect −Priority-Medium It's impossible for gtest to anticipate all possible side effects in a death test and clean them up. Instead, it's the test author's responsibility to ensure that the tests clean up after themselves. Some people may even find the core dump useful. Please try to rewrite your test to disable core dump. You can see 'man core' on how to do it. Status: WontFix Labels: Type-Enhancement Priority-Low OpSys-Linux Usability −Type-Defect −Priority-Medium Dec 21, 2009 issue 236 (configure.ac:29: error: possibly undefined macro: AC_PROG_LI...) commented on by jeff.science - I find autotools to be a royal pain. It would be great if they died a quick and painful death. While I reported the error on my laptop, I want to use Google's test and perf tools on BlueGene/P, which is a hideous cross-compile unless one spends a few days debugging autoconf. Hence, just about any other build system would be very useful. Thanks, Jeff I find autotools to be a royal pain. It would be great if they died a quick and painful death. While I reported the error on my laptop, I want to use Google's test and perf tools on BlueGene/P, which is a hideous cross-compile unless one spends a few days debugging autoconf. Hence, just about any other build system would be very useful. Thanks, Jeff Dec 21, 2009 issue 236 (configure.ac:29: error: possibly undefined macro: AC_PROG_LI...) changed by w...@google.com - We'll probably switch the build system from autotools to something else, so the priority is low. Chandler, anything obvious? Thanks. Status: Accepted Owner: chandlerc Labels: Priority-Low OpSys-Linux Usability −Priority-Medium We'll probably switch the build system from autotools to something else, so the priority is low. Chandler, anything obvious? Thanks. Status: Accepted Owner: chandlerc Labels: Priority-Low OpSys-Linux Usability −Priority-Medium Dec 21, 2009 issue 235 (奇怪的tuple 编译错误) Status changed by w...@google.com - The user fixed the problem by rebooting. Status: Invalid The user fixed the problem by rebooting. Status: Invalid Dec 21, 2009 issue 237 (EXPECT_DEATH test passes but leaves a dumped core from spawn...) reported by nate.bauernfeind - What steps will reproduce the problem? 1. create a unit tests that contains EXPECTS_DEATH(volatile int rc = strlen(NULL), ""); Yes I know this is uninteresting, but it is equivalent to my real test which asserts a memory mapped block has been released. * 2. Run that test. What is the expected output? What do you see instead? I expect that both the test passes and that nothing additional is left behind. However, the spawned process is leaving behind a core dump. What version of the product are you using? On what operating system? Googletest v.1.3.0 on Linux 2.6.18-128.1.6.el5 (yes I know it's old... not my choice) Is there an easy way to prevent this without forcing my entire test suite to prevent core dumps (which include legacy non-googletest based tests)? What steps will reproduce the problem? 1. create a unit tests that contains EXPECTS_DEATH(volatile int rc = strlen(NULL), ""); * Yes I know this is uninteresting, but it is equivalent to my real test which asserts a memory mapped block has been released. * 2. Run that test. What is the expected output? What do you see instead? I expect that both the test passes and that nothing additional is left behind. However, the spawned process is leaving behind a core dump. What version of the product are you using? On what operating system? Googletest v.1.3.0 on Linux 2.6.18-128.1.6.el5 (yes I know it's old... not my choice) Is there an easy way to prevent this without forcing my entire test suite to prevent core dumps (which include legacy non-googletest based tests)? Last 30 days Dec 20, 2009 issue 236 (configure.ac:29: error: possibly undefined macro: AC_PROG_LI...) reported by jeff.science - What steps will reproduce the problem? 1. svn checkout http://googletest.googlecode.com/svn/trunk/ googletest-read-only 2. cd googletest-read-only 3. autoreconf -fvi What is the expected output? What do you see instead? googletest-read-only> autoreconf -fvi autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf --force configure.ac:29: error: possibly undefined macro: AC_PROG_LIBTOOL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 What version of the product are you using? On what operating system? 64-bit openSUSE 11.1 > uname -srvmpio Linux 2.6.27.37-0.1-default #1 SMP 2009-10-15 14:56:58 +0200 x86_64 x86_64 x86_64 GNU/Linux > /usr/local/bin/aclocal --version aclocal (GNU automake) 1.11 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Tom Tromey <tromey@redhat.com> and Alexandre Duret-Lutz <adl@gnu.org>. > /usr/local/bin/automake --version automake (GNU automake) 1.11 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Tom Tromey <tromey@redhat.com> and Alexandre Duret-Lutz <adl@gnu.org>. What steps will reproduce the problem? 1. svn checkout http://googletest.googlecode.com/svn/trunk/ googletest-read-only 2. cd googletest-read-only 3. autoreconf -fvi What is the expected output? What do you see instead? googletest-read-only> autoreconf -fvi autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf --force configure.ac:29: error: possibly undefined macro: AC_PROG_LIBTOOL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 What version of the product are you using? On what operating system? 64-bit openSUSE 11.1 > uname -srvmpio Linux 2.6.27.37-0.1-default #1 SMP 2009-10-15 14:56:58 +0200 x86_64 x86_64 x86_64 GNU/Linux > /usr/local/bin/aclocal --version aclocal (GNU automake) 1.11 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Tom Tromey <tromey@redhat.com> and Alexandre Duret-Lutz <adl@gnu.org>. > /usr/local/bin/automake --version automake (GNU automake) 1.11 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Tom Tromey <tromey@redhat.com> and Alexandre Duret-Lutz <adl@gnu.org>. Dec 19, 2009 issue 235 (奇怪的tuple 编译错误) commented on by wangqiang1588 - 抱歉，似乎重新启动一下操作系统以后，可怜的VS 不会发疯了，不知该如何撤回这个问题。抱歉，似乎重新启动一下操作系统以后，可怜的VS 不会发疯了，不知该如何撤回这个问题。 Dec 18, 2009 issue 235 (奇怪的tuple 编译错误) reported by wangqiang1588 - 在Vista sp2 vs2008 sp1 gtest-1.4.0 中定义一个类使用 tuple，若如下定义则可顺利编译通过 class CombineTest: public TestWithParam<::std::tr1::tuple<int, unsigned long long,DWORD,unsigned short >> {}; INSTANTIATE_TEST_CASE_P(DataStoreCombineTest, CombineTest, Combine( Values(2), Values(8, 9, 10), Values(100, 200, 300), Values(45, 46, 47) )); 但是若修改成这样 class CombineTest: public TestWithParam<::std::tr1::tuple<unsigned int, unsigned long long,DWORD,unsigned short >> {}; INSTANTIATE_TEST_CASE_P(DataStoreCombineTest, CombineTest, Combine( Values(2), Values(8, 9, 10), Values(100, 200, 300), Values(45, 46, 47) )); 则编译出错 error C2664: “testing::internal::ParamGenerator<T>::ParamGenerator(const testing::internal::ParamGenerator<T> &)”: 不能将参数 1 从 “testing::internal::ParamGenerator<T>”转换为“const testing::internal::ParamGenerator<T> &” 1> with 1> [ 1> T=unsigned int 1> ] 1> and 1> [ 1> T=int 1> ] 1> and 1> [ 1> T=unsigned int 1> ] 1> 原因如下: 无法从“testing::internal::ParamGenerator<T>”转换为 “const testing::internal::ParamGenerator<T>” 1> with 1> [ 1> T=int 1> ] 1> and 1> [ 1> T=unsigned int 1> ] 1> 没有可用于执行该转换的用户定义的转换运算符，或者无法调用该运算符 1> gtest-1.4.0\include\gtest\internal\gtest-param-util-generated.h (4655): 参见对正在编译的函数模板实例化 “testing::internal::ValueArray1<T1>::operator testing::internal::ParamGenerator<T>(void) const<unsigned int>”的引用 1> with 1> [ 1> T1=int, 1> T=unsigned int 1> ] 同样的道理 <::std::tr1::tuple<WORD, unsigned long long,DWORD,unsigned short >> ，<::std::tr1::tuple<unsigned short, unsigned long long,DWORD,unsigned short >> 等等都会提示上面的错误，似乎第一个必须是 Int 有什么建议吗？在Vista sp2 vs2008 sp1 gtest-1.4.0 中定义一个类使用 tuple，若如下定义则可顺利编译通过 class CombineTest: public TestWithParam<::std::tr1::tuple<int, unsigned long long,DWORD,unsigned short >> {}; INSTANTIATE_TEST_CASE_P(DataStoreCombineTest, CombineTest, Combine( Values(2), Values(8, 9, 10), Values(100, 200, 300), Values(45, 46, 47) )); 但是若修改成这样 class CombineTest: public TestWithParam<::std::tr1::tuple<unsigned int, unsigned long long,DWORD,unsigned short >> {}; INSTANTIATE_TEST_CASE_P(DataStoreCombineTest, CombineTest, Combine( Values(2), Values(8, 9, 10), Values(100, 200, 300), Values(45, 46, 47) )); 则编译出错 error C2664: “testing::internal::ParamGenerator<T>::ParamGenerator(const testing::internal::ParamGenerator<T> &)”: 不能将参数 1 从 “testing::internal::ParamGenerator<T>”转换为“const testing::internal::ParamGenerator<T> &” 1> with 1> [ 1> T=unsigned int 1> ] 1> and 1> [ 1> T=int 1> ] 1> and 1> [ 1> T=unsigned int 1> ] 1> 原因如下: 无法从“testing::internal::ParamGenerator<T>”转换为 “const testing::internal::ParamGenerator<T>” 1> with 1> [ 1> T=int 1> ] 1> and 1> [ 1> T=unsigned int 1> ] 1> 没有可用于执行该转换的用户定义的转换运算符，或者无法调用该运算符 1> gtest-1.4.0\include\gtest\internal\gtest-param-util-generated.h (4655): 参见对正在编译的函数模板实例化 “testing::internal::ValueArray1<T1>::operator testing::internal::ParamGenerator<T>(void) const<unsigned int>”的引用 1> with 1> [ 1> T1=int, 1> T=unsigned int 1> ] 同样的道理 <::std::tr1::tuple<WORD, unsigned long long,DWORD,unsigned short >> ，<::std::tr1::tuple<unsigned short, unsigned long long,DWORD,unsigned short >> 等等都会提示上面的错误，似乎第一个必须是 Int 有什么建议吗？ Dec 18, 2009 r355 (Moves gtest.def from src/ to msvc/. ) committed by zhanyong.wan - Moves gtest.def from src/ to msvc/. Moves gtest.def from src/ to msvc/. Dec 18, 2009 issue 214 (Google Test does not support compiling into Windows DLL - I ...) commented on by lennypri...@gmail.com - Vlad's patch works. Couple of comments - Still would like a separate .vcproj/.sln files for building DLL on visual studio - Generally, the convention for naming DLLs on windows would be gtest.dll (for release) and gtestd.dll (for debug) or gtestmdd/gtestmd (for multithreaded-dll, multithreaded-debug-dll) I would like to see either of these name schemes as opposed to _dll scheme. looks kinda ugly _dll.dll Vlad's patch works. Couple of comments - Still would like a separate .vcproj/.sln files for building DLL on visual studio - Generally, the convention for naming DLLs on windows would be gtest.dll (for release) and gtestd.dll (for debug) or gtestmdd/gtestmd (for multithreaded-dll, multithreaded-debug-dll) I would like to see either of these name schemes as opposed to _dll scheme. looks kinda ugly _dll.dll Dec 17, 2009 r354 (Supports building gtest as a DLL (by Vlad Losev). ) committed by zhanyong.wan - Supports building gtest as a DLL (by Vlad Losev). Supports building gtest as a DLL (by Vlad Losev). Dec 16, 2009 issue 108 (Running with valgrind gives a bunch of errors : Conditional ...) Status changed by w...@google.com - Status: Accepted Status: Accepted Dec 16, 2009 r353 (Removes uses of GTEST_HAS_STD_STRING. ) committed by zhanyong.wan - Removes uses of GTEST_HAS_STD_STRING. Removes uses of GTEST_HAS_STD_STRING. Dec 16, 2009 r352 (Trims the autotools build script. ) committed by zhanyong.wan - Trims the autotools build script. Trims the autotools build script. Dec 16, 2009 r351 (Moves mis-placed tests. ) committed by zhanyong.wan - Moves mis-placed tests. Moves mis-placed tests. Dec 16, 2009 issue 220 (warning: declaration of 'c_str' shadows a member of 'this' ) commented on by w...@google.com - Fixed by Preston in r350. Fixed by Preston in r350. Dec 16, 2009 r350 (Turns on -Wshadow (by Preston Jackson). ) committed by zhanyong.wan - Turns on -Wshadow (by Preston Jackson). Turns on -Wshadow (by Preston Jackson). Dec 16, 2009 GoogleTestFAQ (Tips and Frequently-Asked Questions about Google C++ Testing...) Wiki page edited by w...@google.com - Revision r349 wiki change: makes the faq about ASSERT_NE(NULL, ptr) more searchable. Revision r349 wiki change: makes the faq about ASSERT_NE(NULL, ptr) more searchable. Dec 14, 2009 r348 (Stops supporting MSVC 7.1 with exceptions disabled. ) committed by zhanyong.wan - Stops supporting MSVC 7.1 with exceptions disabled. Stops supporting MSVC 7.1 with exceptions disabled. Dec 10, 2009 issue 108 (Running with valgrind gives a bunch of errors : Conditional ...) commented on by mercier.luc - Hi, I think this issue needs to be reopened. Indeed, the "Conditional jump or move depends on uninitialised value(s)" errors appear as soon as you link with googletest, even if you don't use it at all! Here's how to reproduce: Environment: Red Hat on x86_64 architecture Compiler: g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) Gtest: I found no way of display the exact gtest version, but it was downloaded on December 1st I believe. Create a file gtestBug.C containing: ----------------------------------------- int main(int argc, char* argv[]) { return 0; } ----------------------------------------- Then, compile with linking to googletest: g++ -g -O0 -ansi -Wall -W -c gtestBug.C g++ -g -O0 -o gtestBug gtestBug.o -static -L/usr/local/lib -lgtest Finally, run "valgrind gtestBug". Here's my output: ------------------------------------------ ==28233== Memcheck, a memory error detector. ==28233== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==28233== Using LibVEX rev 1658, a library for dynamic binary translation. ==28233== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==28233== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==28233== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==28233== For more details, rerun with: -v ==28233== ==28233== Conditional jump or move depends on uninitialised value(s) ==28233== at 0x41580D: strlen (in /XXXXX/gtestBug) ==28233== by 0x433CC4: fillin_rpath (in /XXXXX/gtestBug) ==28233== by 0x4359F5: _dl_init_paths (in /XXXXX/gtestBug) ==28233== by 0x4196BE: _dl_non_dynamic_init (in /XXXXX/gtestBug) ==28233== by 0x419F8A: __libc_init_first (in /XXXXX/gtestBug) ==28233== by 0x40A59C: (below main) (in /XXXXX/gtestBug) ==28233== ==28233== Use of uninitialised value of size 8 ==28233== at 0x40B003: exit (in /XXXXX/gtestBug) ==28233== ==28233== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) ==28233== malloc/free: in use at exit: 0 bytes in 0 blocks. ==28233== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==28233== For counts of detected errors, rerun with: -v ==28233== All heap blocks were freed -- no leaks are possible. -------------------------------------------------- The error disappears if I don't link with gtest, so the problem seems to be from some static initialization performed by gtest. Note that the version of gcc I pointed too was the one used to compile the tiny program above. I wouldn't swear gtest itlesf was compiled with the same version. Hi, I think this issue needs to be reopened. Indeed, the "Conditional jump or move depends on uninitialised value(s)" errors appear as soon as you link with googletest, even if you don't use it at all! Here's how to reproduce: Environment: Red Hat on x86_64 architecture Compiler: g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) Gtest: I found no way of display the exact gtest version, but it was downloaded on December 1st I believe. Create a file gtestBug.C containing: ----------------------------------------- int main(int argc, char* argv[]) { return 0; } ----------------------------------------- Then, compile with linking to googletest: g++ -g -O0 -ansi -Wall -W -c gtestBug.C g++ -g -O0 -o gtestBug gtestBug.o -static -L/usr/local/lib -lgtest Finally, run "valgrind gtestBug". Here's my output: ------------------------------------------ ==28233== Memcheck, a memory error detector. ==28233== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==28233== Using LibVEX rev 1658, a library for dynamic binary translation. ==28233== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==28233== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==28233== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==28233== For more details, rerun with: -v ==28233== ==28233== Conditional jump or move depends on uninitialised value(s) ==28233== at 0x41580D: strlen (in /XXXXX/gtestBug) ==28233== by 0x433CC4: fillin_rpath (in /XXXXX/gtestBug) ==28233== by 0x4359F5: _dl_init_paths (in /XXXXX/gtestBug) ==28233== by 0x4196BE: _dl_non_dynamic_init (in /XXXXX/gtestBug) ==28233== by 0x419F8A: __libc_init_first (in /XXXXX/gtestBug) ==28233== by 0x40A59C: (below main) (in /XXXXX/gtestBug) ==28233== ==28233== Use of uninitialised value of size 8 ==28233== at 0x40B003: exit (in /XXXXX/gtestBug) ==28233== ==28233== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) ==28233== malloc/free: in use at exit: 0 bytes in 0 blocks. ==28233== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==28233== For counts of detected errors, rerun with: -v ==28233== All heap blocks were freed -- no leaks are possible. -------------------------------------------------- The error disappears if I don't link with gtest, so the problem seems to be from some static initialization performed by gtest. Note that the version of gcc I pointed too was the one used to compile the tiny program above. I wouldn't swear gtest itlesf was compiled with the same version. Dec 10, 2009 issue 40 (Need an Eclipse plug-in) commented on by mikelong2005 - I was using the Industrial Logic plugin but it doesn't seem to work with the latest edition of eclipse... I was using the Industrial Logic plugin but it doesn't seem to work with the latest edition of eclipse... Dec 10, 2009 issue 40 (Need an Eclipse plug-in) commented on by hlindstrom - Any news in this area? Any news in this area? Dec 10, 2009 issue 210 (provide an sample to demonstrating using death test) Status changed by w...@google.com - There are plenty of examples in test/gtest-death-test_test.cc. Status: WontFix There are plenty of examples in test/gtest-death-test_test.cc. Status: WontFix Dec 10, 2009 issue 188 (local unwind in arm cpu) commented on by w...@google.com - Hi charsyam, Which email address or full name did you use to sign the CLA? Thanks. Hi charsyam, Which email address or full name did you use to sign the CLA? Thanks. Dec 10, 2009 issue 168 (Need better test coverage of gtest-death-test.cc) commented on by w...@google.com - Is the test coverage really inadequate for death tests? I suspect not. Note that the test coverage tool we use only tracks code in the parent process (I think), and it only takes into account the Linux code path, so the result is skewed. Is the test coverage really inadequate for death tests? I suspect not. Note that the test coverage tool we use only tracks code in the parent process (I think), and it only takes into account the Linux code path, so the result is skewed. Dec 10, 2009 issue 159 (Crash with /vd2 flag ) Status changed by w...@google.com - Closed as this is a compiler bug. Status: Invalid Closed as this is a compiler bug. Status: Invalid Dec 10, 2009 issue 134 (testShardStatusFileIsCreatedWithListTests test fails on Mac ...) Status changed by w...@google.com - Closed for lack of user response. Please re-open it if you are still seeing the problem in the latest version of gtest (1.4.0). Status: WontFix Closed for lack of user response. Please re-open it if you are still seeing the problem in the latest version of gtest (1.4.0). Status: WontFix

issue 108 (Running with valgrind gives a bunch of errors : Conditional ...) commented on by mercier.luc - Hi, I think this issue needs to be reopened. Indeed, the "Conditional jump or move depends on uninitialised value(s)" errors appear as soon as you link with googletest, even if you don't use it at all! Here's how to reproduce: Environment: Red Hat on x86_64 architecture Compiler: g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) Gtest: I found no way of display the exact gtest version, but it was downloaded on December 1st I believe. Create a file gtestBug.C containing: ----------------------------------------- int main(int argc, char* argv[]) { return 0; } ----------------------------------------- Then, compile with linking to googletest: g++ -g -O0 -ansi -Wall -W -c gtestBug.C g++ -g -O0 -o gtestBug gtestBug.o -static -L/usr/local/lib -lgtest Finally, run "valgrind gtestBug". Here's my output: ------------------------------------------ ==28233== Memcheck, a memory error detector. ==28233== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==28233== Using LibVEX rev 1658, a library for dynamic binary translation. ==28233== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==28233== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==28233== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==28233== For more details, rerun with: -v ==28233== ==28233== Conditional jump or move depends on uninitialised value(s) ==28233== at 0x41580D: strlen (in /XXXXX/gtestBug) ==28233== by 0x433CC4: fillin_rpath (in /XXXXX/gtestBug) ==28233== by 0x4359F5: _dl_init_paths (in /XXXXX/gtestBug) ==28233== by 0x4196BE: _dl_non_dynamic_init (in /XXXXX/gtestBug) ==28233== by 0x419F8A: __libc_init_first (in /XXXXX/gtestBug) ==28233== by 0x40A59C: (below main) (in /XXXXX/gtestBug) ==28233== ==28233== Use of uninitialised value of size 8 ==28233== at 0x40B003: exit (in /XXXXX/gtestBug) ==28233== ==28233== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) ==28233== malloc/free: in use at exit: 0 bytes in 0 blocks. ==28233== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==28233== For counts of detected errors, rerun with: -v ==28233== All heap blocks were freed -- no leaks are possible. -------------------------------------------------- The error disappears if I don't link with gtest, so the problem seems to be from some static initialization performed by gtest. Note that the version of gcc I pointed too was the one used to compile the tiny program above. I wouldn't swear gtest itlesf was compiled with the same version.

Hi, I think this issue needs to be reopened. Indeed, the "Conditional jump or move depends on uninitialised value(s)" errors appear as soon as you link with googletest, even if you don't use it at all! Here's how to reproduce: Environment: Red Hat on x86_64 architecture Compiler: g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) Gtest: I found no way of display the exact gtest version, but it was downloaded on December 1st I believe. Create a file gtestBug.C containing: ----------------------------------------- int main(int argc, char* argv[]) { return 0; } ----------------------------------------- Then, compile with linking to googletest: g++ -g -O0 -ansi -Wall -W -c gtestBug.C g++ -g -O0 -o gtestBug gtestBug.o -static -L/usr/local/lib -lgtest Finally, run "valgrind gtestBug". Here's my output: ------------------------------------------ ==28233== Memcheck, a memory error detector. ==28233== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==28233== Using LibVEX rev 1658, a library for dynamic binary translation. ==28233== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==28233== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==28233== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==28233== For more details, rerun with: -v ==28233== ==28233== Conditional jump or move depends on uninitialised value(s) ==28233== at 0x41580D: strlen (in /XXXXX/gtestBug) ==28233== by 0x433CC4: fillin_rpath (in /XXXXX/gtestBug) ==28233== by 0x4359F5: _dl_init_paths (in /XXXXX/gtestBug) ==28233== by 0x4196BE: _dl_non_dynamic_init (in /XXXXX/gtestBug) ==28233== by 0x419F8A: __libc_init_first (in /XXXXX/gtestBug) ==28233== by 0x40A59C: (below main) (in /XXXXX/gtestBug) ==28233== ==28233== Use of uninitialised value of size 8 ==28233== at 0x40B003: exit (in /XXXXX/gtestBug) ==28233== ==28233== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) ==28233== malloc/free: in use at exit: 0 bytes in 0 blocks. ==28233== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==28233== For counts of detected errors, rerun with: -v ==28233== All heap blocks were freed -- no leaks are possible. -------------------------------------------------- The error disappears if I don't link with gtest, so the problem seems to be from some static initialization performed by gtest. Note that the version of gcc I pointed too was the one used to compile the tiny program above. I wouldn't swear gtest itlesf was compiled with the same version.

Last 7 days

Last 30 days