You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(17) |
2
(15) |
3
(36) |
4
(24) |
5
(36) |
|
6
(18) |
7
(16) |
8
(18) |
9
(19) |
10
(18) |
11
(37) |
12
(18) |
|
13
(13) |
14
(21) |
15
(27) |
16
(10) |
17
(16) |
18
(25) |
19
(21) |
|
20
(11) |
21
(14) |
22
(6) |
23
(15) |
24
(27) |
25
(3) |
26
(9) |
|
27
(16) |
28
(24) |
29
(21) |
30
(43) |
31
(42) |
|
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-10 23:09:55
|
On Fri, 11 Mar 2005, Eyal Lebedinsky wrote: > http://bugs.kde.org/show_bug.cgi?id=101204 > > How do I edit the entry to Version "2.4 CVS"? I could not > find this category when I entered the bug report, but > the category seems to be there now. It was added in response to you noticing it was missing :) N |
|
From: Dirk M. <dm...@gm...> - 2005-03-10 23:02:27
|
On Thursday 10 March 2005 23:28, Eyal Lebedinsky wrote: > How do I edit the entry to Version "2.4 CVS"? I could not > find this category when I entered the bug report, but > the category seems to be there now. done. Dirk |
|
From: Tom H. <to...@co...> - 2005-03-10 22:51:37
|
In message <423...@ey...>
Eyal Lebedinsky <ey...@ey...> wrote:
> http://bugs.kde.org/show_bug.cgi?id=101204
>
> How do I edit the entry to Version "2.4 CVS"? I could not
> find this category when I entered the bug report, but
> the category seems to be there now.
Well 2.4.0 isn't released yet, so I'm not sure that 2.3 CVS isn't
the right value anyway.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Eyal L. <ey...@ey...> - 2005-03-10 22:28:17
|
http://bugs.kde.org/show_bug.cgi?id=101204 How do I edit the entry to Version "2.4 CVS"? I could not find this category when I entered the bug report, but the category seems to be there now. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Robert W. <rj...@du...> - 2005-03-10 18:54:33
|
CVS commit by rjwalsh: Remove messages about not being able to clean up non-existent core files. M +1 -1 memcheck/tests/badjump.vgtest 1.5 M +1 -1 none/tests/x86/int.vgtest 1.5 --- valgrind/memcheck/tests/badjump.vgtest #1.4:1.5 @@ -1,2 +1,2 @@ prog: badjump -cleanup: rm vgcore.pid* +cleanup: rm -f vgcore.pid* --- valgrind/none/tests/x86/int.vgtest #1.4:1.5 @@ -1,2 +1,2 @@ prog: int -cleanup: rm vgcore.pid* +cleanup: rm -f vgcore.pid* |
|
From: Jeremy F. <je...@go...> - 2005-03-10 09:05:17
|
CVS commit by fitzhardinge:
Get more useful stack traces for internal errors/panics which happen
during the exit cleanup. Also, don't report stack growth failures if
the fault is actually way above the stack.
M +5 -2 vg_signals.c 1.136
--- valgrind/coregrind/vg_signals.c #1.135:1.136
@@ -1812,5 +1812,6 @@ void vg_sync_signalhandler ( Int sigNo,
if (info->si_code == 1 && /* SEGV_MAPERR */
- fault >= esp) {
+ fault >= esp &&
+ fault < VG_(client_end)) {
/* If the fault address is above esp but below the current known
stack segment base, and it was a fault because there was
@@ -1908,5 +1909,7 @@ void vg_sync_signalhandler ( Int sigNo,
VG_(kill_self)(sigNo); /* generate a core dump */
- tst = VG_(get_ThreadState)(VG_(get_lwp_tid)(VG_(gettid)()));
+ if (tid == 0) /* could happen after everyone has exited */
+ tid = VG_(master_tid);
+ tst = VG_(get_ThreadState)(tid);
VG_(core_panic_at)("Killed by fatal signal",
VG_(get_ExeContext2)(UCONTEXT_INSTR_PTR(uc),
|
|
From: Jeremy F. <je...@go...> - 2005-03-10 08:58:41
|
Jeremy Fitzhardinge wrote: >Nicholas Nethercote wrote: > > > >>>It looks like the crash happened when massif is assembling its final >>>report. >>>It seems that one of the pointers in the line >>> >>>xpt_snapshot->xpt->exact_ST_dbld += d_t1_t2 * xpt_snapshot->space >>> >>>is equal to 0xe4e4e4e4 - a very clearly bogus pointer. >>> >>>(The "stack overflow" message is meaningless in this context; it >>>failed to grow the stack to that address, so it decided that it was >>>an overflow.) >>> >>> >>I can't reproduce this problem. Can you provide a test program that >>demonstrates the behaviour? >> >> > >I get it with memcheck/tests/leakotron: > >: abulafia:pts/2; coregrind/valgrind '--tool=massif' memcheck/tests/leakotron >==29291== Massif, a space profiler for x86-linux. >==29291== Copyright (C) 2003, Nicholas Nethercote >==29291== Using valgrind-2.4.0.rc1, a program supervision framework for x86-linux. >==29291== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. >==29291== For more details, rerun with: -v >==29291== >FAILED: I count 399408 bytes, leakcheck says 0 >==29291== >==29291== Stack overflow in thread 0: can't grow stack to 0x919191A1 >--29291-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting >--29291-- si_code=1 Fault EIP: 0xB7D46029; Faulting address: 0x919191A1 >--29291-- esp=0xB050AF38 > > >valgrind: the `impossible' happened: > Killed by fatal signal >Basic block ctr is approximately 16779353 >==29291== at 0xB7D46029: calc_exact_ST_dbld2 (ms_main.c:1268) > >sched status: > running_tid=0 > > >Note: see also the FAQ.txt in the source distribution. >It contains workarounds to several common problems. > >If that doesn't help, please report this bug to: valgrind.kde.org > >In the bug report, send all the above text, the valgrind >version, and what Linux distro you are using. Thanks. > > >Some printfs show that its xpt_snapshot->xpt which has the bad value; >running massif under memcheck shows that it is uninitialized: > >==29793== Conditional jump or move depends on uninitialised value(s) >==29793== at 0x5125B038: calc_exact_ST_dbld2 (ms_main.c:1266) >==29793== >==29793== Use of uninitialised value of size 4 >==29793== at 0x5125B029: calc_exact_ST_dbld2 (ms_main.c:1268) > > > With some more backtrace: ==32004== Stack overflow in thread 0: can't grow stack to 0x51515161 --32004-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --32004-- si_code=1 Fault EIP: 0xB7DBF042; Faulting address: 0x51515161 --32004-- esp=0xB050AF38 valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 16779353 ==32004== at 0xB7DBF042: calc_exact_ST_dbld2 (ms_main.c:1268) ==32004== by 0xB7DBF17B: calc_exact_ST_dbld (ms_main.c:1305) ==32004== by 0xB7DC0159: vgSkin_fini (ms_main.c:1805) ==32004== by 0xB006DACE: vgSkinInternal_fini (vg_toolint.c:36) ==32004== by 0xB0030C60: vgPlain_shutdown_actions (vg_main.c:2683) ==32004== by 0xB0087CB4: vgArch_thread_wrapper (core_os.c:48) sched status: running_tid=0 J |
|
From: Jeremy F. <je...@go...> - 2005-03-10 08:52:45
|
Nicholas Nethercote wrote: >> It looks like the crash happened when massif is assembling its final >> report. >> It seems that one of the pointers in the line >> >> xpt_snapshot->xpt->exact_ST_dbld += d_t1_t2 * xpt_snapshot->space >> >> is equal to 0xe4e4e4e4 - a very clearly bogus pointer. >> >> (The "stack overflow" message is meaningless in this context; it >> failed to grow the stack to that address, so it decided that it was >> an overflow.) > > > I can't reproduce this problem. Can you provide a test program that > demonstrates the behaviour? I get it with memcheck/tests/leakotron: : abulafia:pts/2; coregrind/valgrind '--tool=massif' memcheck/tests/leakotron ==29291== Massif, a space profiler for x86-linux. ==29291== Copyright (C) 2003, Nicholas Nethercote ==29291== Using valgrind-2.4.0.rc1, a program supervision framework for x86-linux. ==29291== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==29291== For more details, rerun with: -v ==29291== FAILED: I count 399408 bytes, leakcheck says 0 ==29291== ==29291== Stack overflow in thread 0: can't grow stack to 0x919191A1 --29291-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --29291-- si_code=1 Fault EIP: 0xB7D46029; Faulting address: 0x919191A1 --29291-- esp=0xB050AF38 valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 16779353 ==29291== at 0xB7D46029: calc_exact_ST_dbld2 (ms_main.c:1268) sched status: running_tid=0 Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. Some printfs show that its xpt_snapshot->xpt which has the bad value; running massif under memcheck shows that it is uninitialized: ==29793== Conditional jump or move depends on uninitialised value(s) ==29793== at 0x5125B038: calc_exact_ST_dbld2 (ms_main.c:1266) ==29793== ==29793== Use of uninitialised value of size 4 ==29793== at 0x5125B029: calc_exact_ST_dbld2 (ms_main.c:1268) J |
|
From: <js...@ac...> - 2005-03-10 04:02:20
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-03-10 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 199 tests, 5 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) corecheck/tests/fdleak_fcntl (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-03-10 03:28:16
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-03-10 03:20:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int sh: line 1: 11489 Segmentation fault VALGRINDLIB=/tmp/valgrind.18873/valgrind/.in_place /tmp/valgrind.18873/valgrind/./coregrind/valgrind --command-line-only=yes --memcheck:leak-check=no --addrcheck:leak-check=no --tool=none ./int >int.stdout.out 2>int.stderr.out rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 205 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-10 03:22:27
|
Nightly build on audi ( Red Hat 9 ) started at 2005-03-10 03:15:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow fpu_lazy_eflags: valgrind ./fpu_lazy_eflags insn_basic: valgrind ./insn_basic insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 204 tests, 0 stderr failures, 0 stdout failures ================= |
|
From: Tom H. <th...@cy...> - 2005-03-10 03:16:22
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-03-10 03:10:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 203 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-10 03:15:21
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-03-10 03:00:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 203 tests, 5 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) addrcheck/tests/leak-tree (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-10 03:11:37
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-03-10 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) addrcheck/tests/leak-0 (stderr) addrcheck/tests/leak-cycle (stderr) addrcheck/tests/leak-regroot (stderr) addrcheck/tests/leak-tree (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) make: *** [regtest] Error 1 |
|
From: Nicholas N. <nj...@cs...> - 2005-03-10 02:47:11
|
On Wed, 9 Mar 2005, Jeremy Fitzhardinge wrote: >> However, when I use the new version of massif, I get the following: >> >> ==================================================================== >> ==19751== >> ==19751== Stack overflow in thread 0: can't grow stack to 0xE4E4E4F4 >> --19751-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - >> exiting >> --19751-- si_code=1 Fault EIP: 0xB7D74051; Faulting address: 0xE4E4E4F4 >> --19751-- esp=0xB0755F38 >> >> >> valgrind: the `impossible' happened: >> Killed by fatal signal >> Basic block ctr is approximately 503255235 >> ==19751== at 0xB7D74051: calc_exact_ST_dbld2 (ms_main.c:1269) >> > It looks like the crash happened when massif is assembling its final report. > It seems that one of the pointers in the line > > xpt_snapshot->xpt->exact_ST_dbld += d_t1_t2 * xpt_snapshot->space > > is equal to 0xe4e4e4e4 - a very clearly bogus pointer. > > (The "stack overflow" message is meaningless in this context; it failed to > grow the stack to that address, so it decided that it was an overflow.) I can't reproduce this problem. Can you provide a test program that demonstrates the behaviour? N |
|
From: Nicholas N. <nj...@cs...> - 2005-03-10 02:41:03
|
CVS commit by nethercote:
Don't print debug info.
M +0 -1 ms_main.c 1.25
--- valgrind/massif/ms_main.c #1.24:1.25
@@ -850,5 +850,4 @@ static UInt curr_census = 0;
static Bool count_stack_size( Addr stack_min, Addr stack_max, void *cp )
{
- VG_(printf)("stack_max=%p stack_min=%p delta=%d\n", stack_max, stack_min, stack_max-stack_min);
*(UInt *)cp += (stack_max - stack_min);
return False;
|
|
From: Jeremy F. <je...@go...> - 2005-03-10 02:04:11
|
CVS commit by fitzhardinge:
Only try matching if the pointer could be resolved to a name.
M +4 -2 vg_errcontext.c 1.73
--- valgrind/coregrind/vg_errcontext.c #1.72:1.73
@@ -980,10 +980,12 @@ Bool supp_matches_callers(Error* err, Su
switch (su->callers[i].ty) {
case ObjName:
- (void)VG_(get_objname)(a, caller_name, M_VG_ERRTXT);
+ if (!VG_(get_objname)(a, caller_name, M_VG_ERRTXT))
+ return False;
break;
case FunName:
// Nb: mangled names used in suppressions
- (void)VG_(get_fnname_nodemangle)(a, caller_name, M_VG_ERRTXT);
+ if (!VG_(get_fnname_nodemangle)(a, caller_name, M_VG_ERRTXT))
+ return False;
break;
default: VG_(skin_panic)("supp_matches_callers");
|
|
From: Jeremy F. <je...@go...> - 2005-03-10 02:02:57
|
CVS commit by fitzhardinge:
Fix false assertion in pattern matching.
A memcheck/tests/match-overrun.c 1.1 [no copyright]
A memcheck/tests/match-overrun.stderr.exp 1.1
A memcheck/tests/match-overrun.supp 1.1
A memcheck/tests/match-overrun.vgtest 1.1
M +3 -1 coregrind/vg_mylibc.c 1.112
M +3 -0 memcheck/tests/Makefile.am 1.71
--- valgrind/coregrind/vg_mylibc.c #1.111:1.112
@@ -1062,5 +1062,6 @@ static Bool string_match_wrk ( const Cha
for (;;) {
switch (*pat) {
- case '\0' : return (*str=='\0');
+ case '\0' : recDepth--;
+ return (*str=='\0');
case '*' : do {
if (string_match_wrk(pat+1,str)) {
@@ -1096,4 +1097,5 @@ Bool VG_(string_match) ( const Char* pat
recDepth = 0;
b = string_match_wrk ( pat, str );
+ vg_assert(recDepth == 0);
/*
VG_(printf)("%s %s %s\n",
--- valgrind/memcheck/tests/Makefile.am #1.70:1.71
@@ -44,4 +44,5 @@
manuel1.stderr.exp manuel1.stdout.exp manuel1.vgtest \
manuel2.stderr.exp manuel2.stdout.exp manuel2.vgtest \
+ match-overrun.stderr.exp match-overrun.vgtest match-overrun.stderr.supp \
manuel3.stderr.exp manuel3.vgtest \
memalign_test.stderr.exp memalign_test.vgtest \
@@ -97,4 +98,5 @@
malloc1 malloc2 malloc3 manuel1 manuel2 manuel3 \
memalign_test memalign2 memcmptest mempool mmaptest \
+ match-overrun \
nanoleak new_nothrow \
null_socket overlap \
@@ -151,4 +153,5 @@
manuel2_SOURCES = manuel2.c
manuel3_SOURCES = manuel3.c
+match_overrun_SOURCES = match-overrun.c
mmaptest_SOURCES = mmaptest.c
memalign_test_SOURCES = memalign_test.c
|