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
|
2
|
3
(6) |
4
(1) |
5
(1) |
6
(2) |
|
7
(4) |
8
(7) |
9
(1) |
10
(2) |
11
(1) |
12
(4) |
13
|
|
14
(3) |
15
(2) |
16
(6) |
17
(10) |
18
(8) |
19
|
20
|
|
21
|
22
(5) |
23
(12) |
24
(5) |
25
|
26
(5) |
27
(1) |
|
28
(1) |
29
(2) |
|
|
|
|
|
|
From: <sv...@va...> - 2016-02-16 21:14:55
|
Author: florian
Date: Tue Feb 16 21:14:47 2016
New Revision: 3208
Log:
s390: Add machine model z13s
Modified:
trunk/pub/libvex.h
Modified: trunk/pub/libvex.h
==============================================================================
--- trunk/pub/libvex.h (original)
+++ trunk/pub/libvex.h Tue Feb 16 21:14:47 2016
@@ -141,7 +141,8 @@
#define VEX_S390X_MODEL_ZEC12 10
#define VEX_S390X_MODEL_ZBC12 11
#define VEX_S390X_MODEL_Z13 12
-#define VEX_S390X_MODEL_UNKNOWN 13 /* always last in list */
+#define VEX_S390X_MODEL_Z13S 13
+#define VEX_S390X_MODEL_UNKNOWN 14 /* always last in list */
#define VEX_S390X_MODEL_MASK 0x3F
#define VEX_HWCAPS_S390X_LDISP (1<<6) /* Long-displacement facility */
|
|
From: William G. <app...@li...> - 2016-02-16 20:27:48
|
Hi I am writing a valgrind tool and I am aware that valgrind has a flag to display a timestamp. The tool must keep track of certain events and mark their start and stop time. Since I cannot use standard c library is there a known way to use "clock()" or "time()" Thanks, Will |
|
From: Anuta M. <man...@gm...> - 2016-02-16 09:27:51
|
Hi,
I am very new to Valgrind and am trying to write a tool where I need to
track:
- Variable declarations (global and local variables)
- Reads/writes to these variables
- Locks and unlocks of mutexes
*How do I track reads/writes to variables declared by my test program?*
*How do I track pthread_mutex_{lock,unlock}?*
Thanks in advance,
--
Anuta Mukherjee,
|
|
From: <sv...@va...> - 2016-02-15 22:53:53
|
Author: philippe
Date: Mon Feb 15 22:53:45 2016
New Revision: 15788
Log:
Speed up vgdb in standalone mode by using noack mode
Modified:
trunk/coregrind/vgdb.c
Modified: trunk/coregrind/vgdb.c
==============================================================================
--- trunk/coregrind/vgdb.c (original)
+++ trunk/coregrind/vgdb.c Mon Feb 15 22:53:45 2016
@@ -381,7 +381,7 @@
valgrind process that there is new data.
Returns True if write is ok, False if there was a problem. */
static
-Bool write_buf(int fd, char* buf, int size, const char* desc, Bool notify)
+Bool write_buf(int fd, const char* buf, int size, const char* desc, Bool notify)
{
int nrwritten;
int nrw;
@@ -586,10 +586,9 @@
}
/* Read a packet from fromfd, with error checking,
- and store it in BUF.
- Returns length of packet, or -1 if error or -2 if EOF.
- Writes ack on ackfd */
-
+ and store it in BUF.
+ If checksum incorrect, writes a - on ackfd.
+ Returns length of packet, or -1 if error or -2 if EOF. */
static int
getpkt (char *buf, int fromfd, int ackfd)
{
@@ -647,11 +646,7 @@
add_written(1);
}
- DEBUG(2, "getpkt (\"%s\"); [sending ack] \n", buf);
- if (write (ackfd, "+", 1) != 1)
- ERROR(0, "error when writing + (ack)\n");
- else
- add_written(1);
+ DEBUG(2, "getpkt (\"%s\"); [no ack] \n", buf);
return bp - buf;
}
@@ -980,6 +975,17 @@
}
from_pid = open_fifo(to_gdb_from_pid, O_RDONLY,
"read cmd result from pid");
+
+ /* Enable no ack mode. */
+ write_buf(to_pid, "$QStartNoAckMode#b0", 19, "write start no ack mode",
+ /* notify */ True);
+ buflen = getpkt(buf, from_pid, to_pid);
+ if (buflen != 2 || strcmp(buf, "OK") != 0) {
+ if (buflen != 2)
+ ERROR (0, "no ack mode: unexpected buflen %d\n", buflen);
+ else
+ ERROR (0, "no ack mode: unexpected packet %s\n", buf);
+ }
for (nc = 0; nc <= last_command; nc++) {
fprintf (stderr, "sending command %s to pid %d\n", commands[nc], pid);
|
|
From: Mark W. <mj...@re...> - 2016-02-15 15:57:17
|
Sorry I missed this (old) thread when writing the patch for: https://bugs.kde.org/show_bug.cgi?id=359201 I think it improves on the orginal fix by explicitly skipping argument5 (uaddr2 aka dummy) for FUTEX_WAIT_BITSET. Does that patch look reasonable? |
|
From: <sv...@va...> - 2016-02-14 22:14:28
|
Author: philippe
Date: Sun Feb 14 22:14:19 2016
New Revision: 15787
Log:
Fix Bug 359133 - m_deduppoolalloc.c:258 (vgPlain_allocEltDedupPA): Assertion 'eltSzB <= ddpa->poolSzB' failed.
When the elt to allocate is bigger than the pool size, allocate
a specific pool only for this element.
Modified:
trunk/NEWS
trunk/coregrind/m_deduppoolalloc.c
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Sun Feb 14 22:14:19 2016
@@ -70,6 +70,7 @@
357871 pthread_spin_destroy not properly wrapped
357887 Fix a file handle leak. VG_(fclose) did not close the file
358030 support direct socket calls on x86 32bit (new in linux 4.3)
+359133 Assertion 'eltSzB <= ddpa->poolSzB' failed
n-i-bz Fix incorrect (or infinite loop) unwind on RHEL7 x86 32 bits
n-i-bz massif --pages-as-heap=yes does not report peak caused by mmap+munmap
Modified: trunk/coregrind/m_deduppoolalloc.c
==============================================================================
--- trunk/coregrind/m_deduppoolalloc.c (original)
+++ trunk/coregrind/m_deduppoolalloc.c Sun Feb 14 22:14:19 2016
@@ -255,7 +255,6 @@
ht_node *ht_ins;
vg_assert(ddpa);
vg_assert(ddpa->ht_elements);
- vg_assert (eltSzB <= ddpa->poolSzB);
ddpa->nr_alloc_calls++;
@@ -272,15 +271,24 @@
and insert it in the hash table of inserted elements. */
// Add a new pool or grow pool if not enough space in the current pool
- if (UNLIKELY(ddpa->curpool_free == NULL
- || ddpa->curpool_free + eltSzB - 1 > ddpa->curpool_limit)) {
- ddpa_add_new_pool_or_grow (ddpa);
+ if (eltSzB + ddpa->eltAlign > ddpa->poolSzB) {
+ // Element (+eltAlign for worst case) bigger than the pool size
+ // => allocate a specific pool just for this element
+ UChar *newpool = ddpa->alloc_fn (ddpa->cc, eltSzB + ddpa->eltAlign);
+ /* add to our collection of pools */
+ VG_(addToXA)( ddpa->pools, &newpool );
+ elt_ins = ddpa_align (ddpa, newpool);
+ } else {
+ if (UNLIKELY(ddpa->curpool_free == NULL
+ || ddpa->curpool_free + eltSzB - 1 > ddpa->curpool_limit)) {
+ ddpa_add_new_pool_or_grow (ddpa);
+ }
+ elt_ins = ddpa->curpool_free;
+ ddpa->curpool_free = ddpa_align(ddpa, ddpa->curpool_free + eltSzB);
}
- elt_ins = ddpa->curpool_free;
- VG_(memcpy)(elt_ins, elt, eltSzB);
- ddpa->curpool_free = ddpa_align(ddpa, ddpa->curpool_free + eltSzB);
+ VG_(memcpy)(elt_ins, elt, eltSzB);
ht_ins = VG_(allocEltPA) (ddpa->ht_node_pa);
ht_ins->key = ht_elt.key;
ht_ins->eltSzB = eltSzB;
|
|
From: Philippe W. <phi...@sk...> - 2016-02-14 18:00:18
|
On Sun, 2016-02-07 at 03:10 +0000, William Good wrote: > > Thanks for your response I. Very helpful slides. As a follow up > question is it possible to use thread local storage in a valgrind > tool? > ______________________________________________________________________ When I prototyped a 'parallel valgrind', I did some trials of using thread local storage : TLS variables started to work on linux, but nothing tried/examined for Android or MacOs. Again, nothing that can be committed. Philippe |
|
From: Philippe W. <phi...@sk...> - 2016-02-14 17:57:08
|
On Sat, 2016-02-06 at 11:33 +0100, Ivo Raisr wrote: > An ideal situation would be if Valgrind core provides efficient > synchronization mechanisms which all analysis tools can consume. > Maybe Philippe could comment if there is anything usable from his > prototype. The prototype was a 'real prototype', i.e. trying to explore possibilities/problems/issues/... . So, no, in the current state, there is nothing that can be committed. Philippe |
|
From: <sv...@va...> - 2016-02-12 13:57:58
|
Author: iraisr
Date: Fri Feb 12 13:57:50 2016
New Revision: 15786
Log:
Fix scalar test case for llseek on x86/Solaris.
n-i-bz
Modified:
trunk/memcheck/tests/x86-solaris/scalar.c
trunk/memcheck/tests/x86-solaris/scalar.stderr.exp
Modified: trunk/memcheck/tests/x86-solaris/scalar.c
==============================================================================
--- trunk/memcheck/tests/x86-solaris/scalar.c (original)
+++ trunk/memcheck/tests/x86-solaris/scalar.c Fri Feb 12 13:57:50 2016
@@ -64,8 +64,8 @@
sys_openat642();
/* SYS_llseek 175 */
- GO(SYS_llseek, "3s 0m");
- SY(SYS_llseek, x0 - 1, x0, x0); FAILx(EBADF);
+ GO(SYS_llseek, "4s 0m");
+ SY(SYS_llseek, x0 - 1, x0, x0, x0); FAILx(EBADF);
/* SYS_getdents64 213 */
GO(SYS_getdents64, "3s 1m");
Modified: trunk/memcheck/tests/x86-solaris/scalar.stderr.exp
==============================================================================
--- trunk/memcheck/tests/x86-solaris/scalar.stderr.exp (original)
+++ trunk/memcheck/tests/x86-solaris/scalar.stderr.exp Fri Feb 12 13:57:50 2016
@@ -57,7 +57,7 @@
Address 0x........ is not stack'd, malloc'd or (recently) free'd
---------------------------------------------------------
-175: SYS_llseek 3s 0m
+175: SYS_llseek 4s 0m
---------------------------------------------------------
Syscall param llseek(fildes) contains uninitialised byte(s)
...
@@ -68,6 +68,9 @@
Syscall param llseek(offset_high) contains uninitialised byte(s)
...
+Syscall param llseek(whence) contains uninitialised byte(s)
+ ...
+
---------------------------------------------------------
213: SYS_getdents64 3s 1m
---------------------------------------------------------
|
|
From: <sv...@va...> - 2016-02-12 13:44:08
|
Author: iraisr
Date: Fri Feb 12 13:43:59 2016
New Revision: 15785
Log:
New gcc versions (4.9, 5.3) provided by Solaris enable
largefile support by default. This gets in the way what
Valgrind core expects (vki, various m_libc modules).
Therefore disable largefile support if it is enabled.
Anyway, support for 32-bit applications is going away in Solaris 12.
Modified:
trunk/Makefile.all.am
trunk/Makefile.tool-tests.am
trunk/README.solaris
trunk/configure.ac
Modified: trunk/Makefile.all.am
==============================================================================
--- trunk/Makefile.all.am (original)
+++ trunk/Makefile.all.am Fri Feb 12 13:43:59 2016
@@ -244,7 +244,8 @@
AM_FLAG_M3264_X86_SOLARIS = @FLAG_M32@
AM_CFLAGS_X86_SOLARIS = @FLAG_M32@ @PREFERRED_STACK_BOUNDARY_2@ \
- $(AM_CFLAGS_BASE) -fomit-frame-pointer
+ $(AM_CFLAGS_BASE) -fomit-frame-pointer \
+ @SOLARIS_UNDEF_LARGESOURCE@
AM_CFLAGS_PSO_X86_SOLARIS = @FLAG_M32@ $(AM_CFLAGS_BASE) $(AM_CFLAGS_PSO_BASE)
AM_CCASFLAGS_X86_SOLARIS = @FLAG_M32@ -g -D_ASM
Modified: trunk/Makefile.tool-tests.am
==============================================================================
--- trunk/Makefile.tool-tests.am (original)
+++ trunk/Makefile.tool-tests.am Fri Feb 12 13:43:59 2016
@@ -28,7 +28,8 @@
if VGCONF_OS_IS_SOLARIS
# Make sure that all test programs have threaded errno.
-AM_CFLAGS += -D_REENTRANT
+# Disable largefile support as there are test cases explictly enabling it.
+AM_CFLAGS += -D_REENTRANT @SOLARIS_UNDEF_LARGESOURCE@
endif
if VGCONF_OS_IS_DARWIN
Modified: trunk/README.solaris
==============================================================================
--- trunk/README.solaris (original)
+++ trunk/README.solaris Fri Feb 12 13:43:59 2016
@@ -50,6 +50,8 @@
- syscall number for unlinkat() is 76 on Solaris 11, but 65 on illumos [2]
- illumos (in April 2013) changed interface of the accept() and pipe()
syscalls [3]
+- posix_spawn() functionality is backed up by true spawn() syscall on Solaris 12
+ whereas illumos and Solaris 11 leverage vfork()
[1] http://docs.oracle.com/cd/E26502_01/html/E28556/gkzlf.html#gkzip
[2] https://www.illumos.org/issues/521
Modified: trunk/configure.ac
==============================================================================
--- trunk/configure.ac (original)
+++ trunk/configure.ac Fri Feb 12 13:43:59 2016
@@ -2728,6 +2728,26 @@
CFLAGS="$save_CFLAGS"
+# Solaris-specific check determining if gcc enables largefile support by
+# default for 32-bit executables. If it does, then set SOLARIS_UNDEF_LARGESOURCE
+# variable with gcc flags which disable it.
+#
+AC_MSG_CHECKING([if gcc enables largefile support for 32-bit apps (Solaris-specific)])
+save_CFLAGS="$CFLAGS"
+CFLAGS="$CFLAGS -m32"
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[
+ return _LARGEFILE_SOURCE;
+]])], [
+SOLARIS_UNDEF_LARGESOURCE="-U_LARGEFILE_SOURCE -U_LARGEFILE64_SOURCE -U_FILE_OFFSET_BITS"
+AC_MSG_RESULT([yes])
+], [
+SOLARIS_UNDEF_LARGESOURCE=""
+AC_MSG_RESULT([no])
+])
+CFLAGS=$safe_CFLAGS
+AC_SUBST(SOLARIS_UNDEF_LARGESOURCE)
+
+
# Solaris-specific check determining if /proc/self/cmdline
# or /proc/<pid>/cmdline is supported.
#
|
|
From: Mark W. <mj...@re...> - 2016-02-12 10:40:38
|
On Fri, 2016-02-12 at 09:33 +0530, Gopal Reddy pandiri wrote: > Hi All, > > I am facing issue in porting valgrind on arm-linux, can anyone help me in > this respect > I was able to successfully compile on arm-Linux while trying to run on the > device(with arm-linux), > Valgrind at the startup throws the following errors. > root@iCAM7000S:bin# ./valgrind --leak-check=yes > /usr/local/bin/icammgr/iCamManager7000S -qws > ==1106== Memcheck, a memory error detector > ==1106== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. > ==1106== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info > ==1106== Command: /usr/local/bin/icammgr/iCamManager7000S -qws > ==1106== > valgrind: Fatal error at startup: a function redirection > valgrind: which is mandatory for this platform-tool combination > valgrind: cannot be set up. Details of the redirection are: > valgrind: > valgrind: A must-be-redirected function > valgrind: whose name matches the pattern: strcmp > valgrind: in an object with soname matching: ld-linux-armhf.so.3 > valgrind: was not found whilst processing > valgrind: symbols from the object with soname: ld-linux-armhf.so.3 > valgrind: > valgrind: Possible fixes: (1, short term): install glibc's debuginfo > valgrind: package on this machine. (2, longer term): ask the packagers > valgrind: for your Linux distribution to please in future ship a non- > valgrind: stripped ld.so (or whatever the dynamic linker .so is called) > valgrind: that exports the above-named function using the standard > valgrind: calling conventions for this platform. The package you need > valgrind: to install for fix (1) is called > valgrind: > valgrind: On Debian, Ubuntu: libc6-dbg > valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo > valgrind: > valgrind: Cannot continue -- exiting now. Sorry. > Let me know if any further information required. That is all the information you need. Just do what the error message tells you to do. Don't strip the symbol table from ld.so. |
|
From: Gopal R. p. <gop...@gm...> - 2016-02-12 04:03:15
|
Hi All, I am facing issue in porting valgrind on arm-linux, can anyone help me in this respect I was able to successfully compile on arm-Linux while trying to run on the device(with arm-linux), Valgrind at the startup throws the following errors. root@iCAM7000S:bin# ./valgrind --leak-check=yes /usr/local/bin/icammgr/iCamManager7000S -qws ==1106== Memcheck, a memory error detector ==1106== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==1106== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==1106== Command: /usr/local/bin/icammgr/iCamManager7000S -qws ==1106== valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: strcmp valgrind: in an object with soname matching: ld-linux-armhf.so.3 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux-armhf.so.3 valgrind: valgrind: Possible fixes: (1, short term): install glibc's debuginfo valgrind: package on this machine. (2, longer term): ask the packagers valgrind: for your Linux distribution to please in future ship a non- valgrind: stripped ld.so (or whatever the dynamic linker .so is called) valgrind: that exports the above-named function using the standard valgrind: calling conventions for this platform. The package you need valgrind: to install for fix (1) is called valgrind: valgrind: On Debian, Ubuntu: libc6-dbg valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo valgrind: valgrind: Cannot continue -- exiting now. Sorry. Let me know if any further information required. Regards, Gopal |
|
From: Mark W. <mj...@re...> - 2016-02-11 10:37:44
|
Hi Bob, On Wed, 2016-02-10 at 14:49 +0000, Bob LaMain wrote: > But, recently, when using valgrind on my Debian machines, it constantly report warnings like: > > WARNING: Serious error when reading debug info > When reading debug info from /lib/i386-linux-gnu/ld-2.21.so > Ignoring non-Dwarf2/3/4 block in .debug_info > ... > > It seems related to the reported bug: > https://bugs.kde.org/show_bug.cgi?id=303877 > > So, > Did the bug has been properly reported to valgrind developers ? > And if so, did somebody already working on it ? > How can i help resolving this issue ? Best would be to make sure Debian doesn't use ELF section compression (and especially not different variants). There are better and more supported ways to compress debuginfo [*]. If you are stuck with such a debuginfo file and you have elfutils 0.165+ installed then you can fix them by decompressing using eu-elfcompress -t none. That said, the issue is known, and there have been some suggestions how a fix might possible be done, but nobody is working on it. See the bug report for more info if you want to help out with that. Cheers, Mark [*] https://gnu.wildebeest.org/blog/mjw/2016/02/02/where-are-your-symbols-debuginfo-and-sources/#Compressing |
|
From: Bob L. <lam...@ya...> - 2016-02-10 14:52:15
|
Hello,
And before complains: thanks for providing valgrind which is a very cool tool which save hours of my life.
But, recently, when using valgrind on my Debian machines, it constantly report warnings like:
WARNING: Serious error when reading debug info
When reading debug info from /lib/i386-linux-gnu/ld-2.21.so
Ignoring non-Dwarf2/3/4 block in .debug_info
...
It seems related to the reported bug:
https://bugs.kde.org/show_bug.cgi?id=303877
So,
Did the bug has been properly reported to valgrind developers ?
And if so, did somebody already working on it ?
How can i help resolving this issue ?
|
|
From: Ivo R. <iv...@iv...> - 2016-02-10 01:55:20
|
2016-02-09 19:57 GMT+01:00 William Good <app...@li...>: > Kind thanks for your response. From reading Philippe's slides I see that > a thread will release the big lock "After it has executed 100K basic > blocks". This does not necessarily guarantee that there will be no > context switches inside my helper function (addStmtToIRSB( sbOut, > IRStmt_Dirty(di) ). It seems like a lock is still necessary to protect my > data structure. If this is the case how do I go about protecting my table > from thread races? > I assume your helper function is called from within the translated code, right? Then your helper is always executed within a context of a basic block. And the big lock guarantees that no context switch happens during the invocation of a basic block. If that was not the case, we would be in a huge trouble today. I. |
|
From: William G. <app...@li...> - 2016-02-09 18:57:51
|
Kind thanks for your response. From reading Philippe's slides I see that a thread will release the big lock "After it has executed 100K basic blocks". This does not necessarily guarantee that there will be no context switches inside my helper function (addStmtToIRSB( sbOut, IRStmt_Dirty(di) ). It seems like a lock is still necessary to protect my data structure. If this is the case how do I go about protecting my table from thread races? ________________________________ From: Ivo Raisr <iv...@iv...> Sent: Saturday, February 6, 2016 5:33 AM To: William Good Cc: val...@li... Subject: Re: [Valgrind-developers] Using lock in tool 2016-02-06 5:07 GMT+01:00 William Good <app...@li...<mailto:app...@li...>>: The table needs to be thread safe because different threads will be using it at run time. I cannot use a pthread_mutex in my tool, correct? How can I make a lock for the table? Hi Bill, Valgrind runs properly multi-threaded applications, but effectively only uses one vCPU at a time to run them. In other words, Valgrind does not use multiple CPUs when running a multi-threaded application. So far no Valgrind analysis tool (except 'none') is designed such that it is multi-thread safe. They all leverage the fact there is always single thread running. See Philippe's presentation about multi-thread Valgrind prototype from FOSDEM 2015: https://archive.fosdem.org/2015/schedule/event/valgrind_multi_prototype/ It goes to a great length in what and where is not multi-thread safe and how come Valgrind is able to run multi-thread applications properly. An ideal situation would be if Valgrind core provides efficient synchronization mechanisms which all analysis tools can consume. Maybe Philippe could comment if there is anything usable from his prototype. I. |
|
From: Olaf H. <ol...@ae...> - 2016-02-08 17:57:41
|
On Mon, Feb 08, Tom Hughes wrote: > Well firstly, open a ticket in bugzilla rather than sending email, so that > it won't get forgotten. Thanks for the reply. I will try to get it into bugs.kde.org, which appears to reacting slow. Olaf |
|
From: John R. <jr...@bi...> - 2016-02-08 17:25:58
|
> Whats the procedure to get this patch for valgrind into the tree? > It looks like the suggested patch got no response: > http://valgrind.10908.n7.nabble.com/Xen-4-6-support-td55907.html The only effective way is to file a bug report. Checking the bug list is built into the development process; the mailing list is not consulted. http://valgrind.org/support/bug_reports.html |
|
From: Tom H. <to...@co...> - 2016-02-08 17:21:09
|
On 08/02/16 16:22, Olaf Hering wrote: > Back in November 2015 a patch was posted which extends valgrinds > knowledge about Xen up to version 4.6. And in fact even up to the > current 4.7 devel tree. > Whats the procedure to get this patch for valgrind into the tree? > It looks like the suggested patch got no response: > http://valgrind.10908.n7.nabble.com/Xen-4-6-support-td55907.html Well firstly, open a ticket in bugzilla rather than sending email, so that it won't get forgotten. Secondly, don't expect it to get merged immediately especially if it's a big patch, or to something obscure like this. The point of putting it in bugzilla is that it will be visible when we're next planning a release and people are looking through the open tickets for things to merge. The main problem with something like this specific example is probably just that none of the core people have any knowledge of Xen so it's hard for us to review. My normal procedure for anything which touches the system call interface is to review the proposed changes against the kernel code to make sure that they appear to be correct, but that is harder the less familiar I am with the system calls in question. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Olaf H. <ol...@ae...> - 2016-02-08 16:35:50
|
Back in November 2015 a patch was posted which extends valgrinds knowledge about Xen up to version 4.6. And in fact even up to the current 4.7 devel tree. Whats the procedure to get this patch for valgrind into the tree? It looks like the suggested patch got no response: http://valgrind.10908.n7.nabble.com/Xen-4-6-support-td55907.html Olaf |
|
From: John R. <jr...@bi...> - 2016-02-08 13:47:49
|
> *==1106== Memcheck, a memory error detector* > *==1106== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.* > *==1106== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info* > *==1106== Command: /usr/local/bin/icammgr/iCamManager7000S -qws* > *==1106== * > * > * > *valgrind: Fatal error at startup: a function redirection* > *valgrind: which is mandatory for this platform-tool combination* > *valgrind: cannot be set up. Details of the redirection are:* > *valgrind: * > *valgrind: A must-be-redirected function* > *valgrind: whose name matches the pattern: strcmp* > *valgrind: in an object with soname matching: ld-linux-armhf.so.3* > *valgrind: was not found whilst processing* > *valgrind: symbols from the object with soname: ld-linux-armhf.so.3* > *valgrind: * > *valgrind: Possible fixes: (1, short term): install glibc's debuginfo* > *valgrind: package on this machine. (2, longer term): ask the packagers* > *valgrind: for your Linux distribution to please in future ship a non-* > *valgrind: stripped ld.so (or whatever the dynamic linker .so is called)* > *valgrind: that exports the above-named function using the standard* > *valgrind: calling conventions for this platform. The package you need* > *valgrind: to install for fix (1) is called* > *valgrind: * > *valgrind: On Debian, Ubuntu: libc6-dbg* > *valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo* > *valgrind: * > *valgrind: Cannot continue -- exiting now. Sorry.* > > > Let me know if any further information required. There is no more information that is required. All the needed information is contained in that message from valgrind. *You*, *yourself*, must do what it says under "Possible fixes". |
|
From: Gopal R. p. <gop...@gm...> - 2016-02-08 08:30:13
|
Thanks Rhys, I was able to successfully compile on arm-Linux while trying to run on the device(with arm-linux), Valgrind at the startup throws the following errors. *root@iCAM7000S:bin# ./valgrind --leak-check=yes /usr/local/bin/icammgr/iCamManager7000S -qws* *==1106== Memcheck, a memory error detector* *==1106== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.* *==1106== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info* *==1106== Command: /usr/local/bin/icammgr/iCamManager7000S -qws* *==1106== * *valgrind: Fatal error at startup: a function redirection* *valgrind: which is mandatory for this platform-tool combination* *valgrind: cannot be set up. Details of the redirection are:* *valgrind: * *valgrind: A must-be-redirected function* *valgrind: whose name matches the pattern: strcmp* *valgrind: in an object with soname matching: ld-linux-armhf.so.3* *valgrind: was not found whilst processing* *valgrind: symbols from the object with soname: ld-linux-armhf.so.3* *valgrind: * *valgrind: Possible fixes: (1, short term): install glibc's debuginfo* *valgrind: package on this machine. (2, longer term): ask the packagers* *valgrind: for your Linux distribution to please in future ship a non-* *valgrind: stripped ld.so (or whatever the dynamic linker .so is called)* *valgrind: that exports the above-named function using the standard* *valgrind: calling conventions for this platform. The package you need* *valgrind: to install for fix (1) is called* *valgrind: * *valgrind: On Debian, Ubuntu: libc6-dbg* *valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo* *valgrind: * *valgrind: Cannot continue -- exiting now. Sorry.* Let me know if any further information required. Regards, Gopal Reddy P. On Sun, Feb 7, 2016 at 9:47 PM, Rhys Kidd <rhy...@gm...> wrote: > Gopal, > > You'll need to be more specific outlining the issues you are seeing with > Valgrind on ARM/Linux. That said, the current version should support many > of the variants on that platform, as per the documentation: > > It runs on the following platforms: X86/Linux, AMD64/Linux, ARM/Linux, > ARM64/Linux, ... ARM/Android (2.3.x and later), ARM64/Android, ... and > AMD64/Darwin (Mac OS X 10.10, with initial support for 10.11). > > Regards, > Rhys > > On 7 February 2016 at 09:03, Gopal Reddy pandiri <gop...@gm...> > wrote: > >> Dear All, >> I am facing issue in porting valgrind on arm-linux, can anyone help me in >> this respect. >> >> Regards, >> Gopal >> >> >> ------------------------------------------------------------------------------ >> Site24x7 APM Insight: Get Deep Visibility into Application Performance >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month >> Monitor end-to-end web transactions and take corrective actions now >> Troubleshoot faster and improve end-user experience. Signup Now! >> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >> >> > |
|
From: <sv...@va...> - 2016-02-08 08:26:24
|
Author: iraisr
Date: Mon Feb 8 08:26:17 2016
New Revision: 15784
Log:
Exclude 'threading model' information from Solaris coredump_many_threads test as well
See previous SVN r15783 for details.
n-i-bz
Modified:
trunk/none/tests/solaris/coredump_many_threads.post.exp
trunk/none/tests/solaris/filter_coredump_many_threads_post
Modified: trunk/none/tests/solaris/coredump_many_threads.post.exp
==============================================================================
--- trunk/none/tests/solaris/coredump_many_threads.post.exp (original)
+++ trunk/none/tests/solaris/coredump_many_threads.post.exp Mon Feb 8 08:26:17 2016
@@ -1,7 +1,6 @@
---Status---
debugging core file of coredump_many_t from ...
initial argv: ./coredump_many_threads
-threading model: native threads
status: process terminated by SIGSEGV (Segmentation Fault), addr=........
---Stacks---
Modified: trunk/none/tests/solaris/filter_coredump_many_threads_post
==============================================================================
--- trunk/none/tests/solaris/filter_coredump_many_threads_post (original)
+++ trunk/none/tests/solaris/filter_coredump_many_threads_post Mon Feb 8 08:26:17 2016
@@ -7,6 +7,7 @@
echo "::status" | /usr/bin/mdb vgcore.* | \
perl -p -e 's/\(.*\) from \S*$/from .../' | \
perl -0 -p -e 's/^file: .+?^(initial argv:)/$1/ms' | \
+sed '/^threading model:/ d' | \
perl -p -e 's/addr=[0-9A-Fa-f]+/addr=......../g'
echo "\n---Stacks---"
|
|
From: <sv...@va...> - 2016-02-07 23:59:49
|
Author: iraisr
Date: Sun Feb 7 23:59:41 2016
New Revision: 15783
Log:
Exclude 'threading model' information from Solaris coredump tests
Solaris 12 transitioned to public libproc and mdb now prints
'raw lwps' instead of 'native threads' for the threading model.
This information is irrelevant for coredump generation and analysis;
therefore leave it out.
n-i-bz
Modified:
trunk/none/tests/amd64-solaris/coredump_single_thread.post.exp
trunk/none/tests/amd64-solaris/coredump_single_thread_mdb
trunk/none/tests/amd64-solaris/coredump_single_thread_sse.post.exp
trunk/none/tests/amd64-solaris/coredump_single_thread_sse_mdb
trunk/none/tests/x86-solaris/coredump_single_thread.post.exp
trunk/none/tests/x86-solaris/coredump_single_thread_mdb
trunk/none/tests/x86-solaris/coredump_single_thread_sse.post.exp
trunk/none/tests/x86-solaris/coredump_single_thread_sse_mdb
Modified: trunk/none/tests/amd64-solaris/coredump_single_thread.post.exp
==============================================================================
--- trunk/none/tests/amd64-solaris/coredump_single_thread.post.exp (original)
+++ trunk/none/tests/amd64-solaris/coredump_single_thread.post.exp Sun Feb 7 23:59:41 2016
@@ -1,7 +1,6 @@
---Status---
debugging core file of coredump_single (64-bit) from ...
initial argv: ./coredump_single_thread
-threading model: native threads
status: process terminated by SIGSEGV (Segmentation Fault), addr=........
---Registers---
Modified: trunk/none/tests/amd64-solaris/coredump_single_thread_mdb
==============================================================================
--- trunk/none/tests/amd64-solaris/coredump_single_thread_mdb (original)
+++ trunk/none/tests/amd64-solaris/coredump_single_thread_mdb Sun Feb 7 23:59:41 2016
@@ -7,6 +7,7 @@
echo "::status" | /usr/bin/mdb vgcore.* | \
perl -p -e 's/from \S*$/from .../' | \
perl -0 -p -e 's/^file: .+?^(initial argv:)/$1/ms' | \
+sed '/^threading model:/ d' | \
perl -p -e 's/addr=[0-9A-Fa-f]+/addr=......../g'
echo "\n---Registers---"
Modified: trunk/none/tests/amd64-solaris/coredump_single_thread_sse.post.exp
==============================================================================
--- trunk/none/tests/amd64-solaris/coredump_single_thread_sse.post.exp (original)
+++ trunk/none/tests/amd64-solaris/coredump_single_thread_sse.post.exp Sun Feb 7 23:59:41 2016
@@ -1,7 +1,6 @@
---Status---
debugging core file of coredump_single (64-bit) from ...
initial argv: ./coredump_single_thread_sse
-threading model: native threads
status: process terminated by SIGSEGV (Segmentation Fault), addr=........
---SSE Registers---
Modified: trunk/none/tests/amd64-solaris/coredump_single_thread_sse_mdb
==============================================================================
--- trunk/none/tests/amd64-solaris/coredump_single_thread_sse_mdb (original)
+++ trunk/none/tests/amd64-solaris/coredump_single_thread_sse_mdb Sun Feb 7 23:59:41 2016
@@ -7,6 +7,7 @@
echo "::status" | /usr/bin/mdb vgcore.* | \
perl -p -e 's/from \S*$/from .../' | \
perl -0 -p -e 's/^file: .+?^(initial argv:)/$1/ms' | \
+sed '/^threading model:/ d' | \
perl -p -e 's/addr=[0-9A-Fa-f]+/addr=......../g'
echo "\n---SSE Registers---"
Modified: trunk/none/tests/x86-solaris/coredump_single_thread.post.exp
==============================================================================
--- trunk/none/tests/x86-solaris/coredump_single_thread.post.exp (original)
+++ trunk/none/tests/x86-solaris/coredump_single_thread.post.exp Sun Feb 7 23:59:41 2016
@@ -1,7 +1,6 @@
---Status---
debugging core file of coredump_single (32-bit) from ...
initial argv: ./coredump_single_thread
-threading model: native threads
status: process terminated by SIGSEGV (Segmentation Fault), addr=........
---Registers---
Modified: trunk/none/tests/x86-solaris/coredump_single_thread_mdb
==============================================================================
--- trunk/none/tests/x86-solaris/coredump_single_thread_mdb (original)
+++ trunk/none/tests/x86-solaris/coredump_single_thread_mdb Sun Feb 7 23:59:41 2016
@@ -7,6 +7,7 @@
echo "::status" | /usr/bin/mdb vgcore.* | \
perl -p -e 's/from \S*$/from .../' | \
perl -0 -p -e 's/^file: .+?^(initial argv:)/$1/ms' | \
+sed '/^threading model:/ d' | \
perl -p -e 's/addr=[0-9A-Fa-f]+/addr=......../g'
echo "\n---Registers---"
Modified: trunk/none/tests/x86-solaris/coredump_single_thread_sse.post.exp
==============================================================================
--- trunk/none/tests/x86-solaris/coredump_single_thread_sse.post.exp (original)
+++ trunk/none/tests/x86-solaris/coredump_single_thread_sse.post.exp Sun Feb 7 23:59:41 2016
@@ -1,7 +1,6 @@
---Status---
debugging core file of coredump_single (32-bit) from ...
initial argv: ./coredump_single_thread_sse
-threading model: native threads
status: process terminated by SIGSEGV (Segmentation Fault), addr=........
---SSE Registers---
Modified: trunk/none/tests/x86-solaris/coredump_single_thread_sse_mdb
==============================================================================
--- trunk/none/tests/x86-solaris/coredump_single_thread_sse_mdb (original)
+++ trunk/none/tests/x86-solaris/coredump_single_thread_sse_mdb Sun Feb 7 23:59:41 2016
@@ -7,6 +7,7 @@
echo "::status" | /usr/bin/mdb vgcore.* | \
perl -p -e 's/from \S*$/from .../' | \
perl -0 -p -e 's/^file: .+?^(initial argv:)/$1/ms' | \
+sed '/^threading model:/ d' | \
perl -p -e 's/addr=[0-9A-Fa-f]+/addr=......../g'
echo "\n---SSE Registers---"
|
|
From: Rhys K. <rhy...@gm...> - 2016-02-07 16:17:12
|
Gopal, You'll need to be more specific outlining the issues you are seeing with Valgrind on ARM/Linux. That said, the current version should support many of the variants on that platform, as per the documentation: It runs on the following platforms: X86/Linux, AMD64/Linux, ARM/Linux, ARM64/Linux, ... ARM/Android (2.3.x and later), ARM64/Android, ... and AMD64/Darwin (Mac OS X 10.10, with initial support for 10.11). Regards, Rhys On 7 February 2016 at 09:03, Gopal Reddy pandiri <gop...@gm...> wrote: > Dear All, > I am facing issue in porting valgrind on arm-linux, can anyone help me in > this respect. > > Regards, > Gopal > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > |