You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
|
|
2
(3) |
3
|
4
|
5
(8) |
6
(5) |
7
(1) |
8
|
|
9
|
10
|
11
(9) |
12
(8) |
13
(12) |
14
(9) |
15
|
|
16
|
17
(5) |
18
(2) |
19
(1) |
20
(10) |
21
(1) |
22
|
|
23
(3) |
24
(4) |
25
(1) |
26
(5) |
27
(8) |
28
|
29
(5) |
|
30
|
31
(3) |
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2009-08-12 09:48:14
|
Known problem. See http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits bullet point 8 for details. J On Wednesday 12 August 2009, Tom Vercauteren wrote: > Hi all, > > I encountered a strange behavior when using the cyl_bessel_i from boost: > http://www.boost.org/doc/libs/1_39_0/libs/math/doc/sf_and_dist/html/math_to >olkit/special/bessel/mbessel.html > > When running within valgrind, the following code > > boost::math::cyl_bessel_i( 2, 0.82995 ) > > returns a NaN instead of something close to 0.0912 as correctly > returned outside of valgrind. Could this be a valgrind issue, or would > you rather have me report this to the boost mailing list? > > Below is a simple (but requiring boost) unit test for this issue and > some infomation about my setup. > > Thank you for your help. > > Best regards, > Tom Vercauteren > > > /////// Unit test /////// > > #include <boost/math/special_functions/bessel.hpp> > int main() > { > // boost::math::cyl_bessel_i( 2, 0.82995 ) should be close to 0.0912 > assert( isnan( boost::math::cyl_bessel_i( 2, 0.82995 ) ) == 0 ); > } > > ///// End unit test //// > > > //// Commands I tried //// > > > g++-4.1 -O0 -Wall -Wconversion -I > > /usr/local/boost_1_39_0/include/boost-1_39/ > > boost_cyl_bessel_i_valgrind_bug_test.cpp -o > > boost_cyl_bessel_i_valgrind_bug_test > > ./boost_cyl_bessel_i_valgrind_bug_test > > pass > > > valgrind ./boost_cyl_bessel_i_valgrind_bug_test > > fail > > > g++-4.1 -O2 -Wall -Wconversion -I > > /usr/local/boost_1_39_0/include/boost-1_39/ > > boost_cyl_bessel_i_valgrind_bug_test.cpp -o > > boost_cyl_bessel_i_valgrind_bug_test > > ./boost_cyl_bessel_i_valgrind_bug_test > > pass > > > valgrind ./boost_cyl_bessel_i_valgrind_bug_test > > fail > > > g++-4.3 -O0 -Wall -Wconversion -I > > /usr/local/boost_1_39_0/include/boost-1_39/ > > boost_cyl_bessel_i_valgrind_bug_test.cpp -o > > boost_cyl_bessel_i_valgrind_bug_test > > ./boost_cyl_bessel_i_valgrind_bug_test > > pass > > > valgrind ./boost_cyl_bessel_i_valgrind_bug_test > > fail > > > g++-4.3 -O2 -Wall -Wconversion -I > > /usr/local/boost_1_39_0/include/boost-1_39/ > > boost_cyl_bessel_i_valgrind_bug_test.cpp -o > > boost_cyl_bessel_i_valgrind_bug_test > > ./boost_cyl_bessel_i_valgrind_bug_test > > pass > > > valgrind ./boost_cyl_bessel_i_valgrind_bug_test > > fail > > //// End commands I tried //// > > > /// Version information /// > > > uname -a > > Linux oahu 2.6.28-15-generic #48-Ubuntu SMP Wed Jul 29 08:54:56 UTC > 2009 i686 GNU/Linux > > > g++-4.1 --version > > g++-4.1 (GCC) 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-24ubuntu1) > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > g++-4.3 --version > > g++-4.3 (Ubuntu 4.3.3-5ubuntu4) 4.3.3 > Copyright (C) 2008 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > valgrind --version > > valgrind-3.4.1-Debian > > /// End version information /// > > > //// Full valgrind output example //// > > > g++ -O0 -Wall -Wconversion -I > > /usr/local/mkt-dev/install/boost_1_39_0/include/boost-1_39/ > > boost_cyl_bessel_i_valgrind_bug_test.cpp -o > > boost_cyl_bessel_i_valgrind_bug_test valgrind -v > > ./boost_cyl_bessel_i_valgrind_bug_test > > ==28028== Memcheck, a memory error detector. > ==28028== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. > ==28028== Using LibVEX rev 1884, a library for dynamic binary translation. > ==28028== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. > ==28028== Using valgrind-3.4.1-Debian, a dynamic binary > instrumentation framework. > ==28028== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. > ==28028== > --28028-- Command line > --28028-- ./boost_cyl_bessel_i_valgrind_bug_test > --28028-- Startup, with flags: > --28028-- -v > --28028-- Contents of /proc/version: > --28028-- Linux version 2.6.28-15-generic (buildd@rothera) (gcc > version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #48-Ubuntu SMP Wed Jul 29 > 08:54:56 UTC 2009 > --28028-- Arch and hwcaps: X86, x86-sse1-sse2 > --28028-- Page sizes: currently 4096, max supported 4096 > --28028-- Valgrind library directory: /usr/lib/valgrind > --28028-- Reading syms from /lib/ld-2.9.so (0x4000000) > --28028-- Reading debug info from /lib/ld-2.9.so .. > --28028-- .. CRC mismatch (computed 049232cc wanted 022486d8) > --28028-- object doesn't have a symbol table > --28028-- Reading syms from > /home/tom/dev/Sandbox/boost_cyl_bessel_i_valgrind_bug_test (0x8048000) > --28028-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck > (0x38000000) --28028-- object doesn't have a dynamic symbol table > --28028-- Reading suppressions file: /usr/lib/valgrind/default.supp > --28028-- Reading syms from > /usr/lib/valgrind/x86-linux/vgpreload_core.so (0x4020000) > --28028-- Reading syms from > /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x4023000) > --28028-- Reading syms from /usr/lib/libstdc++.so.6.0.10 (0x404c000) > --28028-- Reading debug info from /usr/lib/libstdc++.so.6.0.10 .. > --28028-- .. CRC mismatch (computed 87794c5d wanted bcd37461) > --28028-- object doesn't have a symbol table > --28028-- Reading syms from /lib/tls/i686/cmov/libm-2.9.so (0x413b000) > --28028-- Reading debug info from /lib/tls/i686/cmov/libm-2.9.so .. > --28028-- .. CRC mismatch (computed 9d3c94d0 wanted 85a674c7) > --28028-- object doesn't have a symbol table > --28028-- Reading syms from /lib/libgcc_s.so.1 (0x4162000) > --28028-- Reading debug info from /lib/libgcc_s.so.1 .. > --28028-- .. CRC mismatch (computed 224ab3f8 wanted 89276151) > --28028-- object doesn't have a symbol table > --28028-- Reading syms from /lib/tls/i686/cmov/libc-2.9.so (0x4171000) > --28028-- Reading debug info from /lib/tls/i686/cmov/libc-2.9.so .. > --28028-- .. CRC mismatch (computed 7ee64c88 wanted 8d898f0d) > --28028-- object doesn't have a symbol table > --28028-- REDIR: 0x41e8a60 (rindex) redirected to 0x4027330 (rindex) > --28028-- REDIR: 0x41e85e0 (strlen) redirected to 0x40276e0 (strlen) > --28028-- REDIR: 0x41ea850 (memcpy) redirected to 0x4027b50 (memcpy) > --28028-- REDIR: 0x41e8800 (strncmp) redirected to 0x4027950 (strncmp) > --28028-- REDIR: 0x41ea530 (stpcpy) redirected to 0x4028380 (stpcpy) > --28028-- REDIR: 0x41ea3a0 (mempcpy) redirected to 0x4028720 (mempcpy) > --28028-- REDIR: 0x41e4930 (malloc) redirected to 0x4026f20 (malloc) > --28028-- REDIR: 0x41ed390 (strchrnul) redirected to 0x40286c0 (strchrnul) > --28028-- REDIR: 0x41e2520 (free) redirected to 0x4025d40 (free) > --28028-- REDIR: 0x41ea340 (memset) redirected to 0x40285f0 (memset) > --28028-- REDIR: 0x41e4de0 (realloc) redirected to 0x4027030 (realloc) > boost_cyl_bessel_i_valgrind_bug_test: > boost_cyl_bessel_i_valgrind_bug_test.cpp:9: int main(): Assertion > `isnan( boost::math::cyl_bessel_i( 2, 0.82995 ) ) == 0' failed. > ==28028== > ==28028== Process terminating with default action of signal 6 > (SIGABRT): dumping core > ==28028== at 0x40007F2: (within /lib/ld-2.9.so) > ==28028== by 0x419E097: abort (in /lib/tls/i686/cmov/libc-2.9.so) > ==28028== by 0x41955CD: __assert_fail (in > /lib/tls/i686/cmov/libc-2.9.so) ==28028== by 0x804AD8F: main (in > /home/tom/dev/Sandbox/boost_cyl_bessel_i_valgrind_bug_test) > ==28028== > ==28028== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1) > --28028-- > --28028-- supp: 17 Debian libc6 (2.9.x) stripped dynamic linker > ==28028== malloc/free: in use at exit: 0 bytes in 0 blocks. > ==28028== malloc/free: 3 allocs, 3 frees, 569 bytes allocated. > ==28028== > ==28028== All heap blocks were freed -- no leaks are possible. > --28028-- memcheck: sanity checks: 2 cheap, 2 expensive > --28028-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use > --28028-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10 > --28028-- memcheck: auxmaps_L2: 0 searches, 0 nodes > --28028-- memcheck: SMs: n_issued = 11 (176k, 0M) > --28028-- memcheck: SMs: n_deissued = 0 (0k, 0M) > --28028-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M) > --28028-- memcheck: SMs: max_undefined = 0 (0k, 0M) > --28028-- memcheck: SMs: max_defined = 40 (640k, 0M) > --28028-- memcheck: SMs: max_non_DSM = 11 (176k, 0M) > --28028-- memcheck: max sec V bit nodes: 0 (0k, 0M) > --28028-- memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0) > --28028-- memcheck: max shadow mem size: 480k, 0M > --28028-- translate: fast SP updates identified: 3,175 ( 85.6%) > --28028-- translate: generic_known SP updates identified: 269 ( 7.2%) > --28028-- translate: generic_unknown SP updates identified: 264 ( 7.1%) > --28028-- tt/tc: 5,657 tt lookups requiring 5,794 probes > --28028-- tt/tc: 5,657 fast-cache updates, 2 flushes > --28028-- transtab: new 2,821 (67,794 -> 1,028,579; ratio > 151:10) [0 scs] > --28028-- transtab: dumped 0 (0 -> ??) > --28028-- transtab: discarded 0 (0 -> ??) > --28028-- scheduler: 231,604 jumps (bb entries). > --28028-- scheduler: 2/3,045 major/minor sched events. > --28028-- sanity: 3 cheap, 2 expensive checks. > --28028-- exectx: 769 lists, 466 contexts (avg 0 per list) > --28028-- exectx: 558 searches, 222 full compares (397 per 1000) > --28028-- exectx: 0 cmp2, 38 cmp4, 0 cmpAll > --28028-- errormgr: 6 supplist searches, 6 comparisons during search > --28028-- errormgr: 17 errlist searches, 38 comparisons during search > Aborted > > --------------------------------------------------------------------------- >--- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day trial. Simplify your report design, integration and deployment - and > focus on what you do best, core application coding. Discover what's new > with Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Tom V. <tom...@gm...> - 2009-08-12 09:40:39
|
Hi all, I encountered a strange behavior when using the cyl_bessel_i from boost: http://www.boost.org/doc/libs/1_39_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/bessel/mbessel.html When running within valgrind, the following code boost::math::cyl_bessel_i( 2, 0.82995 ) returns a NaN instead of something close to 0.0912 as correctly returned outside of valgrind. Could this be a valgrind issue, or would you rather have me report this to the boost mailing list? Below is a simple (but requiring boost) unit test for this issue and some infomation about my setup. Thank you for your help. Best regards, Tom Vercauteren /////// Unit test /////// #include <boost/math/special_functions/bessel.hpp> int main() { // boost::math::cyl_bessel_i( 2, 0.82995 ) should be close to 0.0912 assert( isnan( boost::math::cyl_bessel_i( 2, 0.82995 ) ) == 0 ); } ///// End unit test //// //// Commands I tried //// > g++-4.1 -O0 -Wall -Wconversion -I /usr/local/boost_1_39_0/include/boost-1_39/ boost_cyl_bessel_i_valgrind_bug_test.cpp -o boost_cyl_bessel_i_valgrind_bug_test > ./boost_cyl_bessel_i_valgrind_bug_test pass > valgrind ./boost_cyl_bessel_i_valgrind_bug_test fail > g++-4.1 -O2 -Wall -Wconversion -I /usr/local/boost_1_39_0/include/boost-1_39/ boost_cyl_bessel_i_valgrind_bug_test.cpp -o boost_cyl_bessel_i_valgrind_bug_test > ./boost_cyl_bessel_i_valgrind_bug_test pass > valgrind ./boost_cyl_bessel_i_valgrind_bug_test fail > g++-4.3 -O0 -Wall -Wconversion -I /usr/local/boost_1_39_0/include/boost-1_39/ boost_cyl_bessel_i_valgrind_bug_test.cpp -o boost_cyl_bessel_i_valgrind_bug_test > ./boost_cyl_bessel_i_valgrind_bug_test pass > valgrind ./boost_cyl_bessel_i_valgrind_bug_test fail > g++-4.3 -O2 -Wall -Wconversion -I /usr/local/boost_1_39_0/include/boost-1_39/ boost_cyl_bessel_i_valgrind_bug_test.cpp -o boost_cyl_bessel_i_valgrind_bug_test > ./boost_cyl_bessel_i_valgrind_bug_test pass > valgrind ./boost_cyl_bessel_i_valgrind_bug_test fail //// End commands I tried //// /// Version information /// > uname -a Linux oahu 2.6.28-15-generic #48-Ubuntu SMP Wed Jul 29 08:54:56 UTC 2009 i686 GNU/Linux > g++-4.1 --version g++-4.1 (GCC) 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-24ubuntu1) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > g++-4.3 --version g++-4.3 (Ubuntu 4.3.3-5ubuntu4) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > valgrind --version valgrind-3.4.1-Debian /// End version information /// //// Full valgrind output example //// > g++ -O0 -Wall -Wconversion -I /usr/local/mkt-dev/install/boost_1_39_0/include/boost-1_39/ boost_cyl_bessel_i_valgrind_bug_test.cpp -o boost_cyl_bessel_i_valgrind_bug_test > valgrind -v ./boost_cyl_bessel_i_valgrind_bug_test ==28028== Memcheck, a memory error detector. ==28028== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==28028== Using LibVEX rev 1884, a library for dynamic binary translation. ==28028== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==28028== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework. ==28028== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==28028== --28028-- Command line --28028-- ./boost_cyl_bessel_i_valgrind_bug_test --28028-- Startup, with flags: --28028-- -v --28028-- Contents of /proc/version: --28028-- Linux version 2.6.28-15-generic (buildd@rothera) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #48-Ubuntu SMP Wed Jul 29 08:54:56 UTC 2009 --28028-- Arch and hwcaps: X86, x86-sse1-sse2 --28028-- Page sizes: currently 4096, max supported 4096 --28028-- Valgrind library directory: /usr/lib/valgrind --28028-- Reading syms from /lib/ld-2.9.so (0x4000000) --28028-- Reading debug info from /lib/ld-2.9.so .. --28028-- .. CRC mismatch (computed 049232cc wanted 022486d8) --28028-- object doesn't have a symbol table --28028-- Reading syms from /home/tom/dev/Sandbox/boost_cyl_bessel_i_valgrind_bug_test (0x8048000) --28028-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck (0x38000000) --28028-- object doesn't have a dynamic symbol table --28028-- Reading suppressions file: /usr/lib/valgrind/default.supp --28028-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_core.so (0x4020000) --28028-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x4023000) --28028-- Reading syms from /usr/lib/libstdc++.so.6.0.10 (0x404c000) --28028-- Reading debug info from /usr/lib/libstdc++.so.6.0.10 .. --28028-- .. CRC mismatch (computed 87794c5d wanted bcd37461) --28028-- object doesn't have a symbol table --28028-- Reading syms from /lib/tls/i686/cmov/libm-2.9.so (0x413b000) --28028-- Reading debug info from /lib/tls/i686/cmov/libm-2.9.so .. --28028-- .. CRC mismatch (computed 9d3c94d0 wanted 85a674c7) --28028-- object doesn't have a symbol table --28028-- Reading syms from /lib/libgcc_s.so.1 (0x4162000) --28028-- Reading debug info from /lib/libgcc_s.so.1 .. --28028-- .. CRC mismatch (computed 224ab3f8 wanted 89276151) --28028-- object doesn't have a symbol table --28028-- Reading syms from /lib/tls/i686/cmov/libc-2.9.so (0x4171000) --28028-- Reading debug info from /lib/tls/i686/cmov/libc-2.9.so .. --28028-- .. CRC mismatch (computed 7ee64c88 wanted 8d898f0d) --28028-- object doesn't have a symbol table --28028-- REDIR: 0x41e8a60 (rindex) redirected to 0x4027330 (rindex) --28028-- REDIR: 0x41e85e0 (strlen) redirected to 0x40276e0 (strlen) --28028-- REDIR: 0x41ea850 (memcpy) redirected to 0x4027b50 (memcpy) --28028-- REDIR: 0x41e8800 (strncmp) redirected to 0x4027950 (strncmp) --28028-- REDIR: 0x41ea530 (stpcpy) redirected to 0x4028380 (stpcpy) --28028-- REDIR: 0x41ea3a0 (mempcpy) redirected to 0x4028720 (mempcpy) --28028-- REDIR: 0x41e4930 (malloc) redirected to 0x4026f20 (malloc) --28028-- REDIR: 0x41ed390 (strchrnul) redirected to 0x40286c0 (strchrnul) --28028-- REDIR: 0x41e2520 (free) redirected to 0x4025d40 (free) --28028-- REDIR: 0x41ea340 (memset) redirected to 0x40285f0 (memset) --28028-- REDIR: 0x41e4de0 (realloc) redirected to 0x4027030 (realloc) boost_cyl_bessel_i_valgrind_bug_test: boost_cyl_bessel_i_valgrind_bug_test.cpp:9: int main(): Assertion `isnan( boost::math::cyl_bessel_i( 2, 0.82995 ) ) == 0' failed. ==28028== ==28028== Process terminating with default action of signal 6 (SIGABRT): dumping core ==28028== at 0x40007F2: (within /lib/ld-2.9.so) ==28028== by 0x419E097: abort (in /lib/tls/i686/cmov/libc-2.9.so) ==28028== by 0x41955CD: __assert_fail (in /lib/tls/i686/cmov/libc-2.9.so) ==28028== by 0x804AD8F: main (in /home/tom/dev/Sandbox/boost_cyl_bessel_i_valgrind_bug_test) ==28028== ==28028== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1) --28028-- --28028-- supp: 17 Debian libc6 (2.9.x) stripped dynamic linker ==28028== malloc/free: in use at exit: 0 bytes in 0 blocks. ==28028== malloc/free: 3 allocs, 3 frees, 569 bytes allocated. ==28028== ==28028== All heap blocks were freed -- no leaks are possible. --28028-- memcheck: sanity checks: 2 cheap, 2 expensive --28028-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --28028-- memcheck: auxmaps_L1: 0 searches, 0 cmps, ratio 0:10 --28028-- memcheck: auxmaps_L2: 0 searches, 0 nodes --28028-- memcheck: SMs: n_issued = 11 (176k, 0M) --28028-- memcheck: SMs: n_deissued = 0 (0k, 0M) --28028-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M) --28028-- memcheck: SMs: max_undefined = 0 (0k, 0M) --28028-- memcheck: SMs: max_defined = 40 (640k, 0M) --28028-- memcheck: SMs: max_non_DSM = 11 (176k, 0M) --28028-- memcheck: max sec V bit nodes: 0 (0k, 0M) --28028-- memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0) --28028-- memcheck: max shadow mem size: 480k, 0M --28028-- translate: fast SP updates identified: 3,175 ( 85.6%) --28028-- translate: generic_known SP updates identified: 269 ( 7.2%) --28028-- translate: generic_unknown SP updates identified: 264 ( 7.1%) --28028-- tt/tc: 5,657 tt lookups requiring 5,794 probes --28028-- tt/tc: 5,657 fast-cache updates, 2 flushes --28028-- transtab: new 2,821 (67,794 -> 1,028,579; ratio 151:10) [0 scs] --28028-- transtab: dumped 0 (0 -> ??) --28028-- transtab: discarded 0 (0 -> ??) --28028-- scheduler: 231,604 jumps (bb entries). --28028-- scheduler: 2/3,045 major/minor sched events. --28028-- sanity: 3 cheap, 2 expensive checks. --28028-- exectx: 769 lists, 466 contexts (avg 0 per list) --28028-- exectx: 558 searches, 222 full compares (397 per 1000) --28028-- exectx: 0 cmp2, 38 cmp4, 0 cmpAll --28028-- errormgr: 6 supplist searches, 6 comparisons during search --28028-- errormgr: 17 errlist searches, 38 comparisons during search Aborted |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-11 23:06:08
|
On Wed, Aug 12, 2009 at 3:05 AM, tom fogal<tf...@al...> wrote: > >> So with the invalid read, it is trying to read an address that is not >> valid. Would you happen to know what the line "16 bytes inside a >> block 24 free'd" means? > > I think it's telling you where the chunk of memory became invalid. I'd > have to check the docs for the 16 and 24, but maybe the allocator gave > a 24-byte block and the pointer that is invalid points to 16 of them. You're (illegally) accessing a heap block that has been freed with 'delete'. The block was 24 bytes in size. Your illegal access is 16 bytes from the start of this 24 byte block. See http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.badrw for more. Nick |
|
From: tom f. <tf...@al...> - 2009-08-11 17:03:58
|
Jonathon <the...@gm...> writes: > Thanks Tom for the help. The --db-attach command is very cool :) np. > So with the invalid read, it is trying to read an address that is not > valid. Would you happen to know what the line "16 bytes inside a > block 24 free'd" means? I think it's telling you where the chunk of memory became invalid. I'd have to check the docs for the 16 and 24, but maybe the allocator gave a 24-byte block and the pointer that is invalid points to 16 of them. > I am using an std::list. Is it possible the problem is in the list? > and not my actual code? Possible? Technically, yes. Exceedingly unlikely. I (highly) recommend -D_GLIBCXX_DEBUG -D_GLIBCXX_CONCEPT_CHECKS when using the STL w/ libstdc++. -tom > On Tue, Aug 11, 2009 at 9:13 AM, tom fogal<tf...@al...> wrote: > > Jonathon <the...@gm...> writes: > >> I was wondering if it is possible to get valgrind to make an "assert" > >> so my debugger can catch it when a memory error occurs? I would like > >> to determine what is causing this memory error and it would be nice > >> if I could do this. > > > > No, but it can do better: suspend the process and automatically start > > your debugger. Use the --db-attach=yes option. > > > >> Also, I am having a hard time deciphering this message, can anyone > >> please give me insight on what this error means? I've tried Google and > >> I had no luck :( > > [snip] > >> 1. ==20770== Invalid read of size 8 > >> 2. ==20770== at 0x662CBB: PacketPool::removePacket(Packet*) > > > > It means a variable, of width 8 (e.g. a double, long on amd64, etc.) > > is being read from yet is not valid. `Read' probably means it's an > > rvalue. `Invalid' implies the address is bad. IIUC, memory is invalid > > by default, marked valid when you assign to it, marked invalid when you > > delete/free it. There's a bit in the memcheck manual about 'shadow > > bits' and how they are used to track validity, IIRC. > > > > -tom |
|
From: Jonathon <the...@gm...> - 2009-08-11 16:51:29
|
Thanks Tom for the help. The --db-attach command is very cool :) So with the invalid read, it is trying to read an address that is not valid. Would you happen to know what the line "16 bytes inside a block 24 free'd" means? I am using an std::list. Is it possible the problem is in the list? and not my actual code? Thanks. On Tue, Aug 11, 2009 at 9:13 AM, tom fogal<tf...@al...> wrote: > Jonathon <the...@gm...> writes: >> I was wondering if it is possible to get valgrind to make an "assert" >> so my debugger can catch it when a memory error occurs? I would like >> to determine what is causing this memory error and it would be nice >> if I could do this. > > No, but it can do better: suspend the process and automatically start > your debugger. Use the --db-attach=yes option. > >> Also, I am having a hard time deciphering this message, can anyone >> please give me insight on what this error means? I've tried Google and >> I had no luck :( > [snip] >> 1. ==20770== Invalid read of size 8 >> 2. ==20770== at 0x662CBB: PacketPool::removePacket(Packet*) > > It means a variable, of width 8 (e.g. a double, long on amd64, etc.) > is being read from yet is not valid. `Read' probably means it's an > rvalue. `Invalid' implies the address is bad. IIUC, memory is invalid > by default, marked valid when you assign to it, marked invalid when you > delete/free it. There's a bit in the memcheck manual about 'shadow > bits' and how they are used to track validity, IIRC. > > -tom > |
|
From: tom f. <tf...@al...> - 2009-08-11 16:11:42
|
Jonathon <the...@gm...> writes: > I was wondering if it is possible to get valgrind to make an "assert" > so my debugger can catch it when a memory error occurs? I would like > to determine what is causing this memory error and it would be nice > if I could do this. No, but it can do better: suspend the process and automatically start your debugger. Use the --db-attach=yes option. > Also, I am having a hard time deciphering this message, can anyone > please give me insight on what this error means? I've tried Google and > I had no luck :( [snip] > 1. ==20770== Invalid read of size 8 > 2. ==20770== at 0x662CBB: PacketPool::removePacket(Packet*) It means a variable, of width 8 (e.g. a double, long on amd64, etc.) is being read from yet is not valid. `Read' probably means it's an rvalue. `Invalid' implies the address is bad. IIUC, memory is invalid by default, marked valid when you assign to it, marked invalid when you delete/free it. There's a bit in the memcheck manual about 'shadow bits' and how they are used to track validity, IIRC. -tom |
|
From: Josef W. <Jos...@gm...> - 2009-08-11 15:59:18
|
On Tuesday 11 August 2009, He fei wrote: > Hi all, > Does Kcachegrind supports recent qt version (4.5~)? Thanks. KCachegrind is part of every KDE4.x release, and KDE4.x is based on Qt4.x. So of course it should work with Qt 4.5 installed. Why should it not? Did you perhaps intend to ask whether there is a KCachegrind version based purely on Qt4.5 (without the need for KDE4)? If so: yes, there is an experimental Qt-only version, which can be found next to KCachegrind sources in the KDE SVN. Look into kdesdk module, subdir kcachegrind/qcachegrind. There is a README on how to compile. I checked that it works with Windows/MinGW (should compile on OSX, too, but I do not have such a machine around). However, the configuration dialog is currently missing :-( Josef |
|
From: Prasanna R. V. <vp...@gm...> - 2009-08-11 15:14:13
|
Dear all, I am trying to use valgrind to profile an application running on linux (RHEL4). The application is multiprocess/multithreaded and also it loads many modules into it. I was particularly interested in one of the modules it loads. So i built that module in debug mode (with -g flag using gcc) and tried to profile it. But i was not able to get the function names inside those modules when valgrind prints its output. Instead i get only hex values(addresses) with which i am not able to figure out anything. When valgrind is trying to load debug info for the module it says "Cant make anything out of .sbss section". I tried googling around for this error and did not get a solution :( Have anybody encountered this before? Or any suggestions to get function names appear in valgrind output for the module i am interested in? I use these options when starting valgrind valgrind --leak-check=yes --leak-resolution=high --log-file=<logfile> --trace-children=yes ./appname <args> Thanks in advance! Regards -- Prasanna Ram |
|
From: Jonathon <the...@gm...> - 2009-08-11 14:34:58
|
Hello, I was wondering if it is possible to get valgrind to make an "assert" so my debugger can catch it when a memory error occurs? I would like to determine what is causing this memory error and it would be nice if I could do this. Also, I am having a hard time deciphering this message, can anyone please give me insight on what this error means? I've tried Google and I had no luck :( thanks J Error: 1. ==20770== Invalid read of size 8 2. ==20770== at 0x662CBB: PacketPool::removePacket(Packet*) 3. ... 4. ... 5. ... 6. ==20770== by 0x5AFA306: start_thread (in /lib64/libpthread-2.5.so) 7. ==20770== by 0x67D7DEC: clone (in /lib64/libc-2.5.so) 8. ==20770== Address 0xDC96D570 is 16 bytes inside a block of size 24 free'd 9. ==20770== at 0x4C1F130: operator delete(void*) (vg_replace_malloc.c:244) 10. ==20770== by 0x641A14: __gnu_cxx::new_allocator<std::_List_node<Packet*> >::deallocate(std::_List_node<Packet*>*, unsigned long) (new_allocator.h:94) 11. ==20770== by 0x641A3C: std::_List_base<PacketBuffer*, std::allocator<PacketBuffer*> >::_M_put_node(std::_List_node<Packet*>*) (stl_list.h:320) 12. ==20770== by 0x642968: std::list<Packet*, std::allocator<Packet*> >::_M_erase(std::_List_iterator<Packet*>) (stl_list.h:1150) 13. ==20770== by 0x64299C: std::list<Packet*, std::allocator<Packet*> >::erase(std::_List_iterator<Packet*>) (list.tcc:98) 14. ... 15. ... 16. ... |
|
From: He f. <fig...@gm...> - 2009-08-11 14:32:36
|
Hi all, Does Kcachegrind supports recent qt version (4.5~)? Thanks. -- Fei |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-11 00:58:48
|
[ Please accept our apologies if you received multiple copies ] -------------------------------- CALL FOR PAPERS -------------------------------- WORKSHOP ON BINARY INSTRUMENTATION SYSTEMS AND ANALYSIS Held in Conjunction with MICRO-42 New York City December 12, 2009 http://www.dyninst.org/wbia09 For questions or comments, please contact: wbia09 (at) dyninst.org ------------------------------- IMPORTANT DATES ------------------------------- 10/16 abstracts due 10/30 notification of acceptance 11/20 final papers due This workshop provides a forum for researchers to present their work on instrumentation systems and applications. Instrumentation has been shown to be an effective technique to support program analysis, debugging, security, and simulation. A number of instrumentation tools and runtime systems have been developed. Instrumentation can be effectively implemented statically (at compile or link time) or dynamically (at run time). This workshop will provide researchers with an opportunity to exchange ideas and learn about new tools and applications. This workshop will consider papers that address a range of topics, including: Instrumentation toolsets Program profiling Dynamic optimization Quantitative metrics for binary instrumentation systems Microarchitectural studies Security applications Software testing and correctness New applications for instrumentation Instrumentation tools used in compiler and architecture education Submissions guidelines: Authors should submit a 3 page double spaced extended abstract by 5pm PST September 1 to wbia09 (at) dyninst.org. Final papers will be 10 pages. The proceedings will be published as part of the ACM International Conference Proceedings Series and will be available in the ACM digital library. ------------------------------ Program Committee: ------------------------------ Derek Bruening, VMware Bruce Childers, University of Pittsburgh Robert Cohn, Intel Saumya Debray, University of Airzona Koen De Bosschere, Ghent University Sebastian Fischmeister, University of Waterloo Jeff Hollingsworth, University of Maryland Robert Hundt, Google Naveen Kumar, VMware Greg Lueck, Intel Nicholas Nethercote, Mozilla Stelios Sidiroglou, MIT Alex Skaletsky, Intel Mustafa Tikir, SDSC --------------------------------- Organizing Committee: --------------------------------- Robert Cohn, Intel Jeff Hollingsworth, University of Maryland Naveen Kumar, VMware |
|
From: Madhan S. <mad...@gm...> - 2009-08-07 06:16:39
|
Hello, To work with PIII machines my applications performs a fence using the following assembly code. lock; addl $0, (-4)(%%esp) During Valgrind 3.2.3 times, looking at, VEX/priv/guest-x86/toIR.c, I guess a fence instruction is explicitly emitted. Can you please tell me how this happens in 3.5.0 code line. We use (-4) instead of (0) as this hinders with a different feature. So I may need to modify Valgrind to also recognize (-4). The instruction looks like this "f0 83 44 24 fc 00" instead of "f0 83 44 24 00 00" Thanks, Madhan. |
|
From: Madhan S. <mad...@gm...> - 2009-08-06 12:30:28
|
This is a very helpful point. Thanks, Madhan. On Thu, Aug 6, 2009 at 3:27 PM, Julian Seward <js...@ac...> wrote: > > Just to clarify .. the intended use scenario is: > > -q --xml=yes --log-file=/tmp/valgrind_myapp.pid%p > --xml-file=/tmp/valgrind_myapp.xml%p > > That means: > > * XML goes into /tmp/valgrind_myapp.xml%p > > * the -q makes the normal output completely silent, unless there is > a critical error in Valgrind itself (eg, assertion failure, or > failure to read debug info from your executable) > > Hence valgrind_myapp.pid%p should normally be empty. If it's not, > then it contains some critical error which the user should be made > aware of. > > I think this is simple -- it means you don't have to do any > filtering/searching/analysis of valgrind_myapp.pid%p, you only > need to distinguish empty vs nonempty. > > J > > > On Thursday 06 August 2009, Madhan Sadasivam wrote: > > It sure does Julian, I messed something for sure in my earlier trial. > > > > Thanks, > > Madhan. > > > > On Thu, Aug 6, 2009 at 2:42 PM, Julian Seward <js...@ac...> wrote: > > > > I want the xml content to go to --xml-file and everything else > > > > to --log-file, the file names being different. Is there a way to do > > > > this. > > > > > > That's how it is supposed to work already! > > > > > > --xml=yes --log-file=/tmp/valgrind_myapp.pid%p > > > --xml-file=/tmp/valgrind_myapp.xml%p > > > > > > should do what you want. > > > > > > J > > > |
|
From: Julian S. <js...@ac...> - 2009-08-06 09:48:02
|
Just to clarify .. the intended use scenario is:
-q --xml=yes --log-file=/tmp/valgrind_myapp.pid%p
--xml-file=/tmp/valgrind_myapp.xml%p
That means:
* XML goes into /tmp/valgrind_myapp.xml%p
* the -q makes the normal output completely silent, unless there is
a critical error in Valgrind itself (eg, assertion failure, or
failure to read debug info from your executable)
Hence valgrind_myapp.pid%p should normally be empty. If it's not,
then it contains some critical error which the user should be made
aware of.
I think this is simple -- it means you don't have to do any
filtering/searching/analysis of valgrind_myapp.pid%p, you only
need to distinguish empty vs nonempty.
J
On Thursday 06 August 2009, Madhan Sadasivam wrote:
> It sure does Julian, I messed something for sure in my earlier trial.
>
> Thanks,
> Madhan.
>
> On Thu, Aug 6, 2009 at 2:42 PM, Julian Seward <js...@ac...> wrote:
> > > I want the xml content to go to --xml-file and everything else
> > > to --log-file, the file names being different. Is there a way to do
> > > this.
> >
> > That's how it is supposed to work already!
> >
> > --xml=yes --log-file=/tmp/valgrind_myapp.pid%p
> > --xml-file=/tmp/valgrind_myapp.xml%p
> >
> > should do what you want.
> >
> > J
|
|
From: Madhan S. <mad...@gm...> - 2009-08-06 09:31:41
|
It sure does Julian, I messed something for sure in my earlier trial. Thanks, Madhan. On Thu, Aug 6, 2009 at 2:42 PM, Julian Seward <js...@ac...> wrote: > > > I want the xml content to go to --xml-file and everything else > > to --log-file, the file names being different. Is there a way to do this. > > That's how it is supposed to work already! > > --xml=yes --log-file=/tmp/valgrind_myapp.pid%p > --xml-file=/tmp/valgrind_myapp.xml%p > > should do what you want. > > J > |
|
From: Julian S. <js...@ac...> - 2009-08-06 09:02:52
|
> I want the xml content to go to --xml-file and everything else
> to --log-file, the file names being different. Is there a way to do this.
That's how it is supposed to work already!
--xml=yes --log-file=/tmp/valgrind_myapp.pid%p
--xml-file=/tmp/valgrind_myapp.xml%p
should do what you want.
J
|
|
From: Madhan S. <mad...@gm...> - 2009-08-06 08:53:37
|
Hi, This is about the 3.5.0 version from the svn trunk (aug 4 2009). When I use the following options, --time-stamp=yes --xml=yes --xml-file=/tmp/valgrind_myapp.xml%p -v a lot of output is thrown to STDOUT and the xml content goes to the file. When I add the following option --log-file=/tmp/valgrind_myapp.xml%p everything including the xml content goes to this file. The xml content is there but there is some more content from "-v" before and after. When I give 2 different file names --log-file=/tmp/valgrind_myapp.pid%p --xml-file=/tmp/valgrind_myapp.xml%p then xml-file is ignored and everything goes to log-file. In short, I want the xml content to go to --xml-file and everything else to --log-file, the file names being different. Is there a way to do this. Thanks, Madhan. |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-05 22:48:06
|
On Thu, Aug 6, 2009 at 1:09 AM, Dan Kegel<da...@ke...> wrote: > On Wed, Aug 5, 2009 at 7:14 AM, Tom Hughes<to...@co...> wrote: >>> (How can you have an invalid address in the middle of a big block?) >> >> It's perfectly possible if you've done VALGRIND_MAKE_MEM_NOACCESS() on that >> piece of memory. Most commonly that would be because that big piece of >> memory is really food for some sort of allocator that is marking it all as >> NOACCESS until it hands out particular pieces. > > This is a bitmapped frame buffer, so the app probably didn't do that. > I'm having heap corruption problems (sorry, I should have mentioned > that), so that's still my favorite explanation. It could also happen if you munmap'd the middle of a heap block, but that seems unlikely (not to mention a terrible idea as it would likely crash the allocator). N |
|
From: Dan K. <da...@ke...> - 2009-08-05 17:40:13
|
On Tue, Aug 4, 2009 at 5:20 PM, Nicholas Nethercote<n.n...@gm...> wrote: > On Wed, Aug 5, 2009 at 10:18 AM, Nicholas > >> http://osdir.com/ml/linux.redhat.release.zoot/2002-11/msg00030.html >> seems relevant, but I couldn't find it in the Darwin Libc-498.1.7 >> sources or xnu-1228.12.14 sources. > > Ooh, I lie. xnu-1228.12.14 has a function called slab_alloc(), but no > constant SLAB_MAGIC that I could find, nor does 'slab->magic' seem to > be present. Grepping every file on the system was the obvious thing to do; it found /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore So I guess some memory corruption bug (in my app?) stepped on a slab used by Quartz. - Dan |
|
From: Dan K. <da...@ke...> - 2009-08-05 15:10:03
|
On Wed, Aug 5, 2009 at 7:14 AM, Tom Hughes<to...@co...> wrote: >> (How can you have an invalid address in the middle of a big block?) > > It's perfectly possible if you've done VALGRIND_MAKE_MEM_NOACCESS() on that > piece of memory. Most commonly that would be because that big piece of > memory is really food for some sort of allocator that is marking it all as > NOACCESS until it hands out particular pieces. This is a bitmapped frame buffer, so the app probably didn't do that. I'm having heap corruption problems (sorry, I should have mentioned that), so that's still my favorite explanation. |
|
From: Tom H. <to...@co...> - 2009-08-05 14:14:52
|
On 05/08/09 14:44, Dan Kegel wrote: > Does this make any sense? > > Invalid write of size 4 > ... > Address 0x1c1ddcec is 1,629,372 bytes inside a block of size 4,065,600 alloc'd > ... > > (How can you have an invalid address in the middle of a big block?) It's perfectly possible if you've done VALGRIND_MAKE_MEM_NOACCESS() on that piece of memory. Most commonly that would be because that big piece of memory is really food for some sort of allocator that is marking it all as NOACCESS until it hands out particular pieces. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Dan K. <da...@ke...> - 2009-08-05 13:50:15
|
Does this make any sense? Invalid write of size 4 ... Address 0x1c1ddcec is 1,629,372 bytes inside a block of size 4,065,600 alloc'd ... (How can you have an invalid address in the middle of a big block?) Or is this more likely a symptom of memory corruption breaking Valgrind? - Dan |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-05 00:27:37
|
On Wed, Aug 5, 2009 at 10:18 AM, Nicholas > > http://osdir.com/ml/linux.redhat.release.zoot/2002-11/msg00030.html > seems relevant, but I couldn't find it in the Darwin Libc-498.1.7 > sources or xnu-1228.12.14 sources. Ooh, I lie. xnu-1228.12.14 has a function called slab_alloc(), but no constant SLAB_MAGIC that I could find, nor does 'slab->magic' seem to be present. N |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-05 00:19:43
|
On Wed, Aug 5, 2009 at 10:04 AM, Dan Kegel<da...@ke...> wrote: > Twice now (three days ago and today) I got the error > Assertion failed: (slab->magic == SLAB_MAGIC), function slab_alloc, > file x-alloc.c, line 353. > while running the chromium ui tests under valgrind *on Mac OS X*... > and I can't figure out where it's coming from. > I've grepped through the chromium and valgrind sources, > and I've googled, with no luck. > > Does that message ring a bell to anyone? Means nothing to me. http://osdir.com/ml/linux.redhat.release.zoot/2002-11/msg00030.html seems relevant, but I couldn't find it in the Darwin Libc-498.1.7 sources or xnu-1228.12.14 sources. Nick |
|
From: Dan K. <da...@ke...> - 2009-08-05 00:04:38
|
Twice now (three days ago and today) I got the error Assertion failed: (slab->magic == SLAB_MAGIC), function slab_alloc, file x-alloc.c, line 353. while running the chromium ui tests under valgrind *on Mac OS X*... and I can't figure out where it's coming from. I've grepped through the chromium and valgrind sources, and I've googled, with no luck. Does that message ring a bell to anyone? |