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
(4) |
|
2
(5) |
3
(3) |
4
(3) |
5
(7) |
6
(7) |
7
(9) |
8
(10) |
|
9
(12) |
10
(26) |
11
(9) |
12
(6) |
13
(7) |
14
(15) |
15
(25) |
|
16
(20) |
17
(32) |
18
(11) |
19
(19) |
20
(22) |
21
(6) |
22
(8) |
|
23
(16) |
24
(25) |
25
(11) |
26
(16) |
27
(12) |
28
(15) |
29
(11) |
|
30
(5) |
31
(8) |
|
|
|
|
|
|
From: Robert W. <rj...@du...> - 2005-01-24 23:44:19
|
On Mon, 2005-01-24 at 22:50 +0000, Nicholas Nethercote wrote: > That doesn't look that bad -- I think it's because V reserves a couple of > signals. I think there may be some *.exp2 files for some of the other > regtests that involve signals for exactly this reason... perhaps there > should be some for these tests too. Or do they already have some? They already have some. They need one more each, I guess. Shall I go ahead and add them in? |
|
From: Nicholas N. <nj...@ca...> - 2005-01-24 22:50:36
|
On Wed, 19 Jan 2005, Robert Walsh wrote: > I ran the two failing signal tests (corecheck/tests/sigkill and > none/tests/exec-sigmask) outside of Valgrind on my FC2 machine. The > results I got were the same as when I ran it under Valgrind. However, > the .exp files were different, so the tests were marked as failed. > Basically, signal 32 seems to be handled differently in both real life > and under Valgrind to how the .exp files expect it to be. Is it time to > update the .exp files, or is something else going on here? > > *** sigkill.stderr.exp 2005-01-19 22:01:41.043293766 -0800 > --- sigkill.stderr.out 2005-01-19 22:10:11.181185774 -0800 > *************** > *** 99,100 **** > ! setting signal 32: Success > ! getting signal 32: Success > --- 99,100 ---- > ! setting signal 32: Invalid argument > ! getting signal 32: Invalid argument > > > *** exec-sigmask.stdout.exp 2005-01-19 22:01:46.761629837 -0800 > --- exec-sigmask.stdout.out 2005-01-19 22:11:14.487860761 -0800 > *************** > *** 0 **** > --- 1 ---- > + full: signal 32 missing from mask That doesn't look that bad -- I think it's because V reserves a couple of signals. I think there may be some *.exp2 files for some of the other regtests that involve signals for exactly this reason... perhaps there should be some for these tests too. Or do they already have some? N |
|
From: Jeremy F. <je...@go...> - 2005-01-24 22:03:20
|
CVS commit by fitzhardinge:
One more file for the previous checkin; include valgrind.spec in the dist tar.
M +1 -1 Makefile.am 1.73
--- valgrind/Makefile.am #1.72:1.73
@@ -41,5 +41,5 @@
README_PACKAGERS \
README_MISSING_SYSCALL_OR_IOCTL TODO \
- valgrind.spec.in valgrind.pc.in \
+ valgrind.spec valgrind.spec.in valgrind.pc.in \
Makefile.all.am Makefile.tool.am Makefile.core-AM_CPPFLAGS.am \
Makefile.tool-inplace.am
|
|
From: Jeremy F. <je...@go...> - 2005-01-24 21:59:23
|
CVS commit by fitzhardinge:
Fix up various build issues. This allows building outside the source tree, and fixes
"make dist" and RPM building.
BUG: 97792
CC: ch...@at...
M +1 -0 Makefile.core-AM_CPPFLAGS.am 1.9
M +1 -2 valgrind.spec.in 1.19
M +2 -2 memcheck/tests/Makefile.am 1.65
M +3 -3 none/tests/Makefile.am 1.61
--- valgrind/Makefile.core-AM_CPPFLAGS.am #1.8:1.9
@@ -1,3 +1,4 @@
add_includes = -I$(top_builddir)/coregrind -I$(top_srcdir)/coregrind \
+ -I$(top_srcdir) \
-I$(top_srcdir)/coregrind/$(VG_ARCH) \
-I$(top_srcdir)/coregrind/$(VG_OS) \
--- valgrind/valgrind.spec.in #1.18:1.19
@@ -47,7 +47,6 @@
/usr/bin/valgrind
/usr/bin/cg_annotate
-/usr/lib/valgrind
-/usr/lib/valgrind/*
/usr/bin/valgrind-listener
+/usr/lib/valgrind
/usr/lib/pkgconfig/valgrind.pc
--- valgrind/none/tests/Makefile.am #1.60:1.61
@@ -78,5 +78,5 @@
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -g
-AM_CPPFLAGS = -I$(top_builddir)/include
+AM_CPPFLAGS = -I$(top_srcdir) -I$(top_srcdir)/include -I$(top_builddir)/include
AM_CXXFLAGS = $(AM_CFLAGS)
@@ -128,10 +128,10 @@
tls_SOURCES = tls.c tls2.c
tls_DEPENDENCIES = tls.so
-tls_LDFLAGS = -Wl,-rpath,$(srcdir)
+tls_LDFLAGS = -Wl,-rpath,$(top_builddir)/none/tests
tls_LDADD = tls.so -lpthread
tls_so_SOURCES = tls_so.c
tls_so_LDADD = tls2.so
tls_so_DEPENDENCIES = tls2.so
-tls_so_LDFLAGS = -Wl,-rpath,$(srcdir) -shared
+tls_so_LDFLAGS = -Wl,-rpath,$(top_builddir)/none/tests -shared
tls2_so_SOURCES = tls2_so.c
tls2_so_LDFLAGS = -shared
--- valgrind/memcheck/tests/Makefile.am #1.64:1.65
@@ -50,5 +50,5 @@
null_socket.stderr.exp null_socket.vgtest \
overlap.stderr.exp overlap.stdout.exp overlap.vgtest \
- post-syscall.stderr.exp post-syscall.stderr.out post-syscall.vgtest \
+ post-syscall.stderr.exp post-syscall.stdout.exp post-syscall.vgtest \
pth_once.stderr.exp pth_once.stdout.exp pth_once.vgtest \
realloc1.stderr.exp realloc1.vgtest \
@@ -99,5 +99,5 @@
-AM_CPPFLAGS = -I$(top_builddir)/include
+AM_CPPFLAGS = -I$(top_srcdir) -I$(top_srcdir)/include -I$(top_builddir)/include
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -g
AM_CXXFLAGS = $(AM_CFLAGS)
|
|
From: Eyal L. <ey...@ey...> - 2005-01-24 13:47:52
|
Jeremy Fitzhardinge wrote: > On Thu, 2005-01-20 at 13:06 +1100, Eyal Lebedinsky wrote: > >>I would like to offer another observation. I just created a simple program >>in an attempt to demonstrate the laconic report problem. Instead, it crashed >>(sig 11) on a return. > > > OK, I just checked in a fix for this too. > > J Further to my report that there still is a problem. I have now ran my tests a few times, and the process dies in exactly the same spot each time, very consistently. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Eyal L. <ey...@ey...> - 2005-01-24 11:59:04
|
Jeremy Fitzhardinge wrote: > On Mon, 2005-01-24 at 14:12 +1100, Eyal Lebedinsky wrote: > >>Jeremy Fitzhardinge wrote: >>[trimmed] >> >>>Could you file a bug with zz36 attached just to >>>make sure the issue gets tracked? >>> >>> J >> >>Logged as 1108082 > > > That doesn't look like a bugs.kde.org bug number (we're only up to > ~97000). Did you submit it via > http://bugs.kde.org/enter_valgrind_bug.cgi ? Now logged as http://bugs.kde.org/show_bug.cgi?id=97785 > J -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Eyal L. <ey...@ey...> - 2005-01-24 10:35:37
|
Jeremy Fitzhardinge wrote: > On Thu, 2005-01-20 at 13:06 +1100, Eyal Lebedinsky wrote: > >>I would like to offer another observation. I just created a simple program >>in an attempt to demonstrate the laconic report problem. Instead, it crashed >>(sig 11) on a return. > > OK, I just checked in a fix for this too. > > J It still crashes, but differently. faultstatus does not fail anymore, but my tests still fail. The pattern is that one program fails with /ssa/builds/20050118g-vgi/bin/showtime: line 81: 10967 Segmentation fault $valgrind_prefix --logfile-fd=9 $orig "$@" 9>>$log The log does not show any errors. Actually, this last run of showtime has not a single line from VG in the log, as if vg itself died quietly. And after this I cannot run anything. This is due to the segfault happening when the failed program was holding a semaphore. This is most unusual because that sem is held for a very brief time, and I do not expect a random crash to happen just then. The fact is that these crashes are very common, actually the earlier problem (the sig11 now patched) was causing exactly the same thing, and I always had to manually remove the sem. Almost as if the fix is not just right. In short, I still have a problem, and it happens about the same time into my tests as the sig11 did. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Eyal L. <ey...@ey...> - 2005-01-24 09:31:59
|
Jeremy Fitzhardinge wrote: > On Thu, 2005-01-20 at 13:06 +1100, Eyal Lebedinsky wrote: > >>I would like to offer another observation. I just created a simple program >>in an attempt to demonstrate the laconic report problem. Instead, it crashed >>(sig 11) on a return. > > OK, I just checked in a fix for this too. I started my testing, I should know how it goes in 1-2h. The pasta sauce (now simmering happily) should also be ready by then... > J Thanks -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Eyal L. <ey...@ey...> - 2005-01-24 09:17:18
|
Jeremy Fitzhardinge wrote: > On Mon, 2005-01-24 at 14:12 +1100, Eyal Lebedinsky wrote: > >>Jeremy Fitzhardinge wrote: >>[trimmed] >> >>>Could you file a bug with zz36 attached just to >>>make sure the issue gets tracked? >>> >>> J >> >>Logged as 1108082 > > > That doesn't look like a bugs.kde.org bug number (we're only up to > ~97000). Did you submit it via > http://bugs.kde.org/enter_valgrind_bug.cgi ? No, through sourceforge.net. https://sourceforge.net/tracker/?func=detail&atid=445586&aid=1108082&group_id=46268 > J Sorry, the pasta sauce is just being made and requires my full attention, I will be back in 15m... -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Jeremy F. <je...@go...> - 2005-01-24 08:53:02
|
CVS commit by fitzhardinge:
Check pthread_create return, so that we're also checking that threads
are being cleaned up properly.
M +21 -5 thread-exits.c 1.2
--- valgrind/none/tests/thread-exits.c #1.1:1.2
@@ -13,6 +13,12 @@
grow the stack. If we don't get the siginfo, then it just looks
like the program crashed.
+
+ Oh, and this test also makes sure that thread resources are cleaned
+ up properly.
*/
#include <pthread.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdlib.h>
static void *thr(void *v)
@@ -37,16 +43,26 @@ int main()
int i;
- /* create lots of threads */
+ /* Create lots of threads */
for(i = 0; i < 1300; i++) {
pthread_t t;
+ int ret;
- pthread_create(&t, NULL, thr, NULL);
- pthread_join(t, NULL);
+ ret = pthread_create(&t, NULL, thr, NULL);
+ if (ret) {
+ printf("pthread_create failed: %s\n", strerror(ret));
+ exit(1);
}
- /* grow the stack */
+ ret = pthread_join(t, NULL);
+ if (ret) {
+ printf("pthread_join failed: %s\n", strerror(ret));
+ exit(1);
+ }
+ }
+
+ /* Grow the stack */
grow(10);
- /* if we didn't die with SIGSEGV in grow(), it is a pass */
+ /* If we didn't die with SIGSEGV in grow(), it is a pass */
printf("PASS\n");
|
|
From: Jeremy F. <je...@go...> - 2005-01-24 08:15:22
|
On Thu, 2005-01-20 at 13:06 +1100, Eyal Lebedinsky wrote: > I would like to offer another observation. I just created a simple program > in an attempt to demonstrate the laconic report problem. Instead, it crashed > (sig 11) on a return. OK, I just checked in a fix for this too. J |
|
From: Jeremy F. <je...@go...> - 2005-01-24 08:13:22
|
CVS commit by fitzhardinge:
Mop up any stray SIGVGCHLDs in poll_signals(); they are generated by
thread exit events, but mostly we don't care about them. However, if
we let too many accumulate, they prevent the proper delivery of other
RT signals which are important, like stack-growth SIGSEGVs.
A none/tests/thread-exits.c 1.1 [no copyright]
A none/tests/thread-exits.stderr.exp 1.1
A none/tests/thread-exits.stdout.exp 1.1
A none/tests/thread-exits.vgtest 1.1
M +7 -0 coregrind/vg_signals.c 1.114
M +4 -0 none/tests/Makefile.am 1.60
--- valgrind/coregrind/vg_signals.c #1.113:1.114
@@ -1865,4 +1865,11 @@ void VG_(poll_signals)(ThreadId tid)
vki_sigset_t saved_mask;
+ /* First, mop up any pending SIGVGCHLDs; we don't care about
+ them here. */
+ VG_(sigemptyset)(&pollset);
+ VG_(sigaddset)(&pollset, VKI_SIGVGCHLD);
+ while(VG_(sigtimedwait)(&pollset, NULL, &zero) == VKI_SIGVGCHLD)
+ ;
+
/* look for all the signals this thread isn't blocking */
for(i = 0; i < _VKI_NSIG_WORDS; i++)
--- valgrind/none/tests/Makefile.am #1.59:1.60
@@ -59,4 +59,5 @@
syscall-restart2.vgtest syscall-restart2.stdout.exp syscall-restart2.stderr.exp \
system.stderr.exp system.vgtest \
+ thread-exits.stderr.exp thread-exits.stdout.exp thread-exits.vgtest \
tls.stderr.exp tls.stdout.exp \
yield.stderr.exp yield.stdout.exp yield.vgtest
@@ -72,4 +73,5 @@
smc1 susphello pending pth_blockedsig pth_stackalign \
syscall-restart1 syscall-restart2 system \
+ thread-exits \
tls tls.so tls2.so \
coolo_sigaction gxx304 yield
@@ -122,4 +124,6 @@
syscall_restart2_SOURCES = syscall-restart2.c
system_SOURCES = system.c
+thread_exits_SOURCES = thread-exits.c
+thread_exits_LDADD = -lpthread
tls_SOURCES = tls.c tls2.c
tls_DEPENDENCIES = tls.so
|
|
From: Jeremy F. <je...@go...> - 2005-01-24 07:46:35
|
On Mon, 2005-01-24 at 14:12 +1100, Eyal Lebedinsky wrote: > Jeremy Fitzhardinge wrote: > [trimmed] > > Could you file a bug with zz36 attached just to > > make sure the issue gets tracked? > > > > J > > Logged as 1108082 That doesn't look like a bugs.kde.org bug number (we're only up to ~97000). Did you submit it via http://bugs.kde.org/enter_valgrind_bug.cgi ? J |
|
From: <js...@ac...> - 2005-01-24 03:57:25
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-01-24 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 193 tests, 15 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-01-24 03:25:20
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-01-24 03:20:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 200 tests, 12 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-24 03:22:25
|
Nightly build on audi ( Red Hat 9 ) started at 2005-01-24 03:15:12 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) none/tests/tls (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-24 03:16:06
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-01-24 03:10:07 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 198 tests, 12 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Eyal L. <ey...@ey...> - 2005-01-24 03:12:28
|
Jeremy Fitzhardinge wrote: [trimmed] > Could you file a bug with zz36 attached just to > make sure the issue gets tracked? > > J Logged as 1108082 -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Tom H. <th...@cy...> - 2005-01-24 03:10:26
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-01-24 03:05:12 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 198 tests, 14 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/post-syscall (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-24 03:06:11
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-01-24 03:00:13 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 198 tests, 13 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Nicholas M. L. <nm...@cs...> - 2005-01-24 02:39:49
|
hi, On Wed, Jan 19, 2005 at 02:47:25PM -0800, Jeremy Fitzhardinge wrote: > Is anyone using VALGRIND_MALLOCLIKE_BLOCK/FREELIKE_BLOCK? yes, i'm using them for custom allocators that i wrote. > If so, how? > > It seems to me that these requests are basically useless, because > there's no way for Valgrind to tell when your malloc implementation is > manipulating its metadata, and when the client is trashing it. If you > mark your memory regions returned by your malloc-like function, Valgrind > will complain when you touch memory near it with your free-like > function. the way i get around this is to only mark the regions i return for client use using MALLOCLIKE, and i only do that immediately prior to returning it. When the region is free'd i immediately call FREELIKE on it. I protect my meta-data seperately by marking it NOACCESS when my functions aren't manipulating it. That way, the MALLOCLIKE and FREELIKE requests are only used to manipulate the leak-checking, not memory protection. Its a bit tricky to ensure that i mark things accessible and inaccessible at the right times, but it was the only way i could find to get the intergration with valgrind that i wanted. > I think we need to add another pair of requests, > VALGRIND_ENTER_MALLOCLIKE_FUNCTION/LEAVE_MALLOCLIKE_FUNCTION, which > tells Valgrind not to complain about touching memory outside of blocks > which have been declared MALLOCLIKE. i certainly agree that the existing MALLOC functions are pretty quirky, (i still don't know whether the redzones come before or after the allocated block), and the MEMPOOL stuff i tried to understand but couldn't. But i did manage to get my allocator working so that i was happy with it in the end. cheers Nick |
|
From: Jeremy F. <je...@go...> - 2005-01-24 01:25:06
|
On Sun, 2005-01-23 at 16:52 -0800, Jeremy Fitzhardinge wrote: > No, I can reproduce it. Could you file a bug with zz36 attached just to > make sure the issue gets tracked? Actually, don't bother, I fixed it. J |
|
From: Jeremy F. <je...@go...> - 2005-01-24 01:24:30
|
CVS commit by fitzhardinge:
Fix stack backtraces in threads. do_clone() was not initializing
stack_highest_word, so a lot of stack-related things were going wrong.
M +13 -2 vg_execontext.c 1.24
M +4 -3 x86-linux/syscalls.c 1.18
--- valgrind/coregrind/vg_execontext.c #1.23:1.24
@@ -160,4 +160,5 @@ static UInt stack_snapshot2 ( Addr* ips,
Addr fp_min, Addr fp_max_orig )
{
+ static const Bool debug = False;
Int i;
Addr fp_max;
@@ -182,4 +183,8 @@ static UInt stack_snapshot2 ( Addr* ips,
fp_max -= sizeof(Addr);
+ if (debug)
+ VG_(printf)("n_ips=%d fp_min=%p fp_max_orig=%p, fp_max=%p ip=%p fp=%p\n",
+ n_ips, fp_min, fp_max_orig, fp_max, ip, fp);
+
/* Assertion broken before main() is reached in pthreaded programs; the
* offending stack traces only have one item. --njn, 2002-aug-16 */
@@ -198,5 +203,6 @@ static UInt stack_snapshot2 ( Addr* ips,
for (i = 1; i < n_ips; i++) {
if (!(fp_min <= fp && fp <= fp_max)) {
- //VG_(printf)("... out of range %p\n", fp);
+ if (debug)
+ VG_(printf)("... out of range %p\n", fp);
break; /* fp gone baaaad */
}
@@ -208,5 +214,6 @@ static UInt stack_snapshot2 ( Addr* ips,
ips[i] = STACK_FRAME_RET(fp); /* ret addr */
fp = STACK_FRAME_NEXT(fp); /* old fp */
- //VG_(printf)(" %p\n", ips[i]);
+ if (debug)
+ VG_(printf)(" ips[%d]=%08p\n", i, ips[i]);
}
}
@@ -334,4 +341,8 @@ void get_needed_regs(ThreadId tid, Addr*
*sp += sizeof(Addr);
}
+
+ if (0)
+ VG_(printf)("tid %d: stack_highest=%p ip=%p sp=%p fp=%p\n",
+ tid, *stack_highest_word, *ip, *sp, *fp);
}
--- valgrind/coregrind/x86-linux/syscalls.c #1.17:1.18
@@ -326,9 +326,10 @@ static Int do_clone(ThreadId ptid,
if (seg) {
ctst->stack_base = seg->addr;
- ctst->stack_size = (Addr)PGROUNDUP(esp) - seg->addr;
+ ctst->stack_highest_word = (Addr)PGROUNDUP(esp);
+ ctst->stack_size = ctst->stack_highest_word - ctst->stack_base;
if (debug)
- VG_(printf)("guessed client stack range %p-%p\n",
- seg->addr, PGROUNDUP(esp));
+ VG_(printf)("tid %d: guessed client stack range %p-%p\n",
+ ctid, seg->addr, PGROUNDUP(esp));
} else {
VG_(message)(Vg_UserMsg, "!? New thread %d starts with ESP(%p) unmapped\n",
|
|
From: Jeremy F. <je...@go...> - 2005-01-24 00:52:46
|
On Mon, 2005-01-24 at 11:48 +1100, Eyal Lebedinsky wrote: > Should I assume that zz36 does not reproduce the problem for you? No, I can reproduce it. Could you file a bug with zz36 attached just to make sure the issue gets tracked? J |
|
From: Eyal L. <ey...@ey...> - 2005-01-24 00:48:40
|
Jeremy Fitzhardinge wrote:
> On Sun, 2005-01-23 at 23:34 +1100, Eyal Lebedinsky wrote:
>
>>Please do not ignore the original report, the problem is still
>>there.
>>
>>Attached is a program that shows how the backtrace is displayed
>>when in main but is missing from a thread.
>
>
> Valgrind has to guess where the thread's stack is, because it isn't
> explicitly told. It assumes that the limits of the stack is between the
> initial stack pointer and the base of that memory mapping; this may not
> be a good assumption.
>
> In coregrind/x86-linux/syscalls.c:do_clone(), could you set "debug" to
> True and tell me what the guessed stack range is for the thread which is
> reporting bad stack backtraces? Also, the contents of /proc/<pid>/maps
> for that process.
>
> J
Should I assume that zz36 does not reproduce the problem for you?
Also, at what point do you want the /proc entry? I will need to
insert some code into VG to dump it. Here is what I inserted at
the top of do_clone():
vki_sigset_t blockall, savedmask;
{
char cmd[256];
VG_(sprintf) (cmd, "cat /proc/%d/maps", (Int)VG_(getpid ()));
VG_(system) (cmd);
}
I hope that getpid() gets the required value.
It took me a while to discover that '%ld' in VG means 'Long' which is
type 'long long' and I need to use '%d' and 'Int' which are 'long'...
==22241== Memcheck, a memory error detector for x86-linux.
==22241== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==22241== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux.
==22241== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==22241== For more details, rerun with: -v
==22241==
/home/eyal/zz/zz36.c(75) testing in main
==22241== Conditional jump or move depends on uninitialised value(s)
==22241== at 0x1B905D32: memcmp (mac_replace_strmem.c:325)
==22241== by 0x8048636: func (zz36.c:23)
==22241== by 0x8048831: main (zz36.c:77)
/home/eyal/zz/zz36.c(80) testing in thread
/home/eyal/zz/zz36.c(38) will pthread_attr_init
/home/eyal/zz/zz36.c(41) pthread_attr_init=0
08048000-08049000 r-xp 00000000 03:06 344360 /home/eyal/zz/zz36
08049000-0804a000 rw-p 00000000 03:06 344360 /home/eyal/zz/zz36
1b8e4000-1b8fa000 r-xp 00000000 03:06 167200 /lib/ld-2.3.2.so
1b8fa000-1b8fb000 rw-p 00015000 03:06 167200 /lib/ld-2.3.2.so
1b8fc000-1b8fd000 rw-p 1b8fc000 00:00 0
1b8fe000-1b8ff000 r-xp 00000000 03:07 5767177 /data2/usr/local/lib/valgrind/vg_inject.so
1b8ff000-1b900000 rw-p 00000000 03:07 5767177 /data2/usr/local/lib/valgrind/vg_inject.so
1b901000-1b907000 r-xp 00000000 03:07 5767318 /data2/usr/local/lib/valgrind/vgpreload_memcheck.so
1b907000-1b908000 rw-p 00005000 03:07 5767318 /data2/usr/local/lib/valgrind/vgpreload_memcheck.so
1b909000-1b90a000 rw-p 1b909000 00:00 0
1b91d000-1b91e000 rw-p 1b91d000 00:00 0
1b91f000-1b92b000 r-xp 00000000 03:06 395375 /lib/tls/libpthread-0.60.so
1b92b000-1b92c000 rw-p 0000c000 03:06 395375 /lib/tls/libpthread-0.60.so
1b92c000-1b92e000 rw-p 1b92c000 00:00 0
1b92f000-1ba58000 r-xp 00000000 03:06 395242 /lib/tls/libc-2.3.2.so
1ba58000-1ba60000 rw-p 00129000 03:06 395242 /lib/tls/libc-2.3.2.so
1ba60000-1ba63000 rw-p 1ba60000 00:00 0
1ba64000-1ba65000 rw-p 1ba64000 00:00 0
1ba66000-1bb66000 rwxp 1ba66000 00:00 0
1bb67000-1bb68000 ---p 1bb67000 00:00 0
1bb68000-1c367000 rwxp 1bb68000 00:00 0
52bfb000-52bff000 rwxp 52bfb000 00:00 0
52bff000-52c00000 r-xp 52bff000 00:00 0
52c00000-52d00000 ---p 52c00000 00:00 0
52d00000-537f8000 rw-p 52d00000 00:00 0
537f8000-b0000000 ---p 537f8000 00:00 0
b0000000-b00af000 r-xp 00000000 03:07 5767176 /data2/usr/local/lib/valgrind/stage2
b00af000-b00b1000 rw-p 000ae000 03:07 5767176 /data2/usr/local/lib/valgrind/stage2
b00b1000-b0205000 rw-p b00b1000 00:00 0
b0206000-b0306000 rwxp b0206000 00:00 0
b0307000-b0407000 rwxp b0307000 00:00 0
b0408000-b0409000 ---p b0408000 00:00 0
b0409000-b0419000 rw-p b0409000 00:00 0
b041a000-b0422000 rwxp b041a000 00:00 0
b0423000-b0433000 rwxp b0423000 00:00 0
b0434000-b0444000 rwxp b0434000 00:00 0
b063b000-b073b000 rwxp b063b000 00:00 0
b073c000-b0986000 rwxp b073c000 00:00 0
b1000000-b1016000 r-xp 00000000 03:06 167200 /lib/ld-2.3.2.so
b1016000-b1017000 rw-p 00015000 03:06 167200 /lib/ld-2.3.2.so
b1018000-b1705000 rwxp b1018000 00:00 0
b7c88000-b7ca1000 r-xp 00000000 03:07 5767317 /data2/usr/local/lib/valgrind/vgskin_memcheck.so
b7ca1000-b7ca2000 rw-p 00018000 03:07 5767317 /data2/usr/local/lib/valgrind/vgskin_memcheck.so
b7ca2000-b7eb5000 rw-p b7ca2000 00:00 0
b7eb5000-b7fde000 r-xp 00000000 03:06 395242 /lib/tls/libc-2.3.2.so
b7fde000-b7fe6000 rw-p 00129000 03:06 395242 /lib/tls/libc-2.3.2.so
b7fe6000-b7fe9000 rw-p b7fe6000 00:00 0
b7fe9000-b7feb000 r-xp 00000000 03:06 395245 /lib/tls/libdl-2.3.2.so
b7feb000-b7fec000 rw-p 00002000 03:06 395245 /lib/tls/libdl-2.3.2.so
b7fff000-b8000000 rw-p b7fff000 00:00 0
bffeb000-c0000000 rw-p bffeb000 00:00 0
ffffe000-fffff000 ---p 00000000 00:00 0
guessed client stack range 0x1BB68000-0x1C367000
clone child has SETTLS: tls info at 0x52BFEB40: idx=6 base=0x1C366BB0 limit=FFFFF; esp=0x52BFEB00 fs=0 gs=33
==22241==
==22241== Thread 2:
==22241== Conditional jump or move depends on uninitialised value(s)
==22241== at 0x1B905D32: memcmp (mac_replace_strmem.c:325)
/home/eyal/zz/zz36.c(60) joined
/home/eyal/zz/zz36.c(65) pthread_attr_destroy=0
/home/eyal/zz/zz36.c(85) test done
0
0
==22241==
==22241== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 13 from 1)
==22241== malloc/free: in use at exit: 68 bytes in 1 blocks.
==22241== malloc/free: 3 allocs, 2 frees, 70 bytes allocated.
==22241== For counts of detected errors, rerun with: -v
==22241== searching for pointers to 1 not-freed blocks.
==22241== checked 9860356 bytes.
==22241==
==22241==
==22241== 68 bytes in 1 blocks are possibly lost in loss record 1 of 1
==22241== at 0x1B904FE5: calloc (vg_replace_malloc.c:175)
==22241== by 0x1B8F25A8: (within /lib/ld-2.3.2.so)
==22241== by 0x1B8F287B: _dl_allocate_tls (in /lib/ld-2.3.2.so)
==22241== by 0x1B92424A: allocate_stack (in /lib/tls/libpthread-0.60.so)
==22241== by 0x1B923C54: pthread_create@@GLIBC_2.1 (in /lib/tls/libpthread-0.60.so)
==22241== by 0x80486DF: test (zz36.c:43)
==22241== by 0x8048868: main (zz36.c:82)
==22241==
==22241== LEAK SUMMARY:
==22241== definitely lost: 0 bytes in 0 blocks.
==22241== possibly lost: 68 bytes in 1 blocks.
==22241== still reachable: 0 bytes in 0 blocks.
==22241== suppressed: 0 bytes in 0 blocks.
==22241== Reachable blocks (those to which a pointer was found) are not shown.
==22241== To see them, rerun with: --show-reachable=yes
--
Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/>
attach .zip as .dat
|