You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(1) |
2
(5) |
3
(1) |
|
4
(3) |
5
(1) |
6
(8) |
7
(7) |
8
(2) |
9
(2) |
10
(2) |
|
11
|
12
(8) |
13
(7) |
14
(14) |
15
(5) |
16
(8) |
17
(8) |
|
18
(12) |
19
(7) |
20
(2) |
21
|
22
(9) |
23
(8) |
24
(1) |
|
25
|
26
(4) |
27
(6) |
28
(5) |
29
|
30
|
31
(1) |
|
From: Matthew B. <ma...@ma...> - 2004-01-15 14:26:57
|
I have a problem I am trying to debug via valgrind and I am seeing something really odd. I am getting a read from uninit error. ==11800== Use of uninitialised value of size 4 ==11800== at 0x80A6931: AddTemperature (c_part.c:2518) Looking at that line u->x += v_thermal*nu1*sqrt(-log(R2)/R2); I thought I would figure out which var is causing the problem, so I did this fubar = v_thermal; fubar *= nu1; fubar *=R2; fubar = u->x; fubar = v_thermal*nu1*sqrt(-log(R2)/R2); None of these report uninited vars. so I am guessing there is something odd happening with valgrind. I have compiled the code as follows mpicc -I/usr/local/mpich/include -I../mp -DLINUX -DMPICH -DBITFLAGS -g -Wimplicit -Wall -pedantic -Wno-long-long -c -o VT.o VT.c So, the compiler shouldn't be cutting out the useless code. I have tried this with both the 2.0.0 and 2.1.0 versions and get the same result. Any ideas would be helpful.. Thanks matt |
|
From: Dirk M. <dm...@me...> - 2004-01-14 19:59:59
|
Is there a reason VG_N_SEMAPHORE is set to 50? I end up recompiling on all machines because our software requires orders of magnitude more. Are there some adverse affects that I'm not seeing? -Dirk |
|
From: Crispin F. <val...@fl...> - 2004-01-14 16:44:10
|
> > Shall I put this into bugzilla ? > > Yes please. Looks like a problem with Jeremy's system call and signal > handling changes. Done, bug 72650 > You can get the same result without using alarm by installing that > handler on SIGINT and then hitting Control-C to interrupt it - it > works normally but under valgrind the read gets restarted. Oh, yeah, thats even worse :) Crispin |
|
From: John R.
|
Tom Hughes wrote: > I've just sent a patch to the developers list to implement all bar > about three of the missing opcodes, and to try and test the ones which > were already implemented as a few of them were broken. Thank you. -- |
|
From: Tom H. <th...@cy...> - 2004-01-14 16:29:44
|
In message <107...@st...>
Crispin Flowerday <val...@fl...> wrote:
> The program is a test case, where normally, and under previous versions
> of valgrind, it would exit after 1 second. However using 2.1.0 it just
> sits in the read() forever. This seems to be because the read() function
> call is getting restarted, which is not what normally happens.
[ snipped test case ]
> Shall I put this into bugzilla ?
Yes please. Looks like a problem with Jeremy's system call and signal
handling changes.
You can get the same result without using alarm by installing that
handler on SIGINT and then hitting Control-C to interrupt it - it
works normally but under valgrind the read gets restarted.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Paul P. <pa...@pa...> - 2004-01-14 16:20:45
|
>>>>> On Wed, 14 Jan 2004 13:50:50 +0100, "S=E9bastien de Menten" <sdem=
en...@ho...> said:
> Does it mean that valgrind is unable to check the stack
> allocated memory ?
Insure++ from ParaSoft in source-instrumentation mode is about the
only current tool that can detect stack and globals overflow errors
in C and C++.
Cheers,
[Speaking for ParaSoft].
|
|
From: Lauren A <mus...@ya...> - 2004-01-14 16:20:20
|
Nope, it's sequential. --- David Eriksson <tw...@us...> wrote: > On Tue, 2004-01-13 at 21:48, Lauren A wrote: > > Hi. I'm having a strange problem, and I was > wondering > > if you had any ideas about it. My program, written > in > > OCaml and C, has a seg fault in it. But when I run > the > > program under Valgrind, there's no seg fault. Any > > ideas on why that would happen? > > Is your program threaded with pthreads? Could be a > race condition in > that case. > > -- > Regards, > -\- David Eriksson -/- > > SynCE - http://synce.sourceforge.net > CalcEm - http://calcem.sourceforge.net > Desquirr - http://desquirr.sourceforge.net > SetiWrapper - http://setiwrapper.sourceforge.net > __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
|
From: Crispin F. <val...@fl...> - 2004-01-14 16:07:27
|
Hi,
I am using 2.1.0, (debian package), and have come across a problem with
the signal handling.
The program is a test case, where normally, and under previous versions
of valgrind, it would exit after 1 second. However using 2.1.0 it just
sits in the read() forever. This seems to be because the read() function
call is getting restarted, which is not what normally happens.
== START ==
#include <unistd.h>
#include <signal.h>
static void nullfunction( int ) {}
static void
setup_signal( int sig, void(*routine)(int) )
{
struct sigaction act;
act.sa_flags = 0;
act.sa_handler = (void(*)(int))routine;
sigemptyset( &act.sa_mask );
sigaction( sig, &act, 0 );
}
int main()
{
char buff[8];
setup_signal( SIGALRM, nullfunction );
alarm( 1 );
read( 0, buff, sizeof( buff ) );
alarm( 0 );
return 0;
}
== CUT ==
System: debian unstable,
Kernel 2.6.1, libc: debian package 2.3.2.ds1-9
Shall I put this into bugzilla ?
Crispin
|
|
From: Tom H. <th...@cy...> - 2004-01-14 15:49:53
|
In message <Sea...@ho...>
SXbastien de Menten <sde...@ho...> wrote:
> will it ever be able to do so ?
> is it due to the fact that it does its checking by replacing malloc
> and/or new by its own memory allocator ?
>
> I ask this because we use insure++ also and wanted to know if it was
> possible to rely only on valgrind
In general terms you can't do much stack checking without
instrumenting the code at compile time as it's very hard to
insert padding between stack variables at run time in order
to catch over/under runs.
There are some things valgrind will catch, like use of a stack
variable that is not initialised, or attempting to access an
address below the bottom of the stack.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Sébastien de M. <sde...@ho...> - 2004-01-14 15:40:09
|
will it ever be able to do so ? is it due to the fact that it does its checking by replacing malloc and/or new by its own memory allocator ? I ask this because we use insure++ also and wanted to know if it was possible to rely only on valgrind sebastien _________________________________________________________________ Hotmail: your free e-mail ! http://www.msn.be/hotmail |
|
From: David E. <tw...@us...> - 2004-01-14 13:45:22
|
On Wed, 2004-01-14 at 13:50, S=E9bastien de Menten wrote:
> Hi, I have a problem when detecting the faulty memory access in
>=20
> #define N 16
> main()
> {
> int a[N];
> // int *a =3D new int[N];
> int i;
> for(i=3D0; i<=3DN+10; i++)
> a[i] =3D 0;
> return (0);
> }
>=20
> The error message is cryptic:
> =3D=3D5749=3D=3D Memcheck, a memory error detector for x86-linux.
> =3D=3D5749=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, by Julian Sewa=
rd.
> =3D=3D5749=3D=3D Using valgrind-2.1.0, a program supervision framework =
for=20
> x86-linux.
> =3D=3D5749=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian Sewa=
rd.
> =3D=3D5749=3D=3D Estimated CPU clock rate is 2004 MHz
> =3D=3D5749=3D=3D For more details, rerun with: -v
> =3D=3D5749=3D=3D
> =3D=3D5749=3D=3D Jump to the invalid address stated on the next line
> =3D=3D5749=3D=3D at 0x0: ???
> =3D=3D5749=3D=3D Address 0x0 is not stack'd, malloc'd or free'd
> =3D=3D5749=3D=3D
> =3D=3D5749=3D=3D Process terminating with default action of signal 11 (=
SIGSEGV):=20
> dumping core
> =3D=3D5749=3D=3D Address not mapped to object at address 0x0
> =3D=3D5749=3D=3D at 0x0: ???
> =3D=3D5749=3D=3D
> =3D=3D5749=3D=3D ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0=
from 0)
> =3D=3D5749=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
> =3D=3D5749=3D=3D malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
> =3D=3D5749=3D=3D For a detailed leak analysis, rerun with: --leak-chec=
k=3Dyes
> =3D=3D5749=3D=3D For counts of detected errors, rerun with: -v
>=20
> If I change the line
> for(i=3D0; i<=3DN+10; i++)
> by
> for(i=3D0; i<=3DN; i++)
> it does not detect the error.
>=20
> If I allocate the memory dynamically,i.e.
> // int a[N];
> int *a =3D new int[N];
> Valgrind detects correctly the error.
>=20
> Does it mean that valgrind is unable to check the stack allocated memor=
y ?
Yes.
--=20
Regards,
-\- David Eriksson -/-
SynCE - http://synce.sourceforge.net
CalcEm - http://calcem.sourceforge.net
Desquirr - http://desquirr.sourceforge.net
SetiWrapper - http://setiwrapper.sourceforge.net
|
|
From: Sébastien de M. <sde...@ho...> - 2004-01-14 12:50:56
|
Hi, I have a problem when detecting the faulty memory access in
#define N 16
main()
{
int a[N];
// int *a = new int[N];
int i;
for(i=0; i<=N+10; i++)
a[i] = 0;
return (0);
}
The error message is cryptic:
==5749== Memcheck, a memory error detector for x86-linux.
==5749== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==5749== Using valgrind-2.1.0, a program supervision framework for
x86-linux.
==5749== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==5749== Estimated CPU clock rate is 2004 MHz
==5749== For more details, rerun with: -v
==5749==
==5749== Jump to the invalid address stated on the next line
==5749== at 0x0: ???
==5749== Address 0x0 is not stack'd, malloc'd or free'd
==5749==
==5749== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==5749== Address not mapped to object at address 0x0
==5749== at 0x0: ???
==5749==
==5749== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==5749== malloc/free: in use at exit: 0 bytes in 0 blocks.
==5749== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==5749== For a detailed leak analysis, rerun with: --leak-check=yes
==5749== For counts of detected errors, rerun with: -v
If I change the line
for(i=0; i<=N+10; i++)
by
for(i=0; i<=N; i++)
it does not detect the error.
If I allocate the memory dynamically,i.e.
// int a[N];
int *a = new int[N];
Valgrind detects correctly the error.
Does it mean that valgrind is unable to check the stack allocated memory ?
Thank you
Sebastien
_________________________________________________________________
|
|
From: Robert W. <rj...@du...> - 2004-01-14 07:31:18
|
Hi all,
I've put a new version of my memory pool patch on my web site. This
version improves the messages output by Valgrind when you run into the
red-zone at either end of a chunk allocated out of a pool, or when you
write into an unallocated part of the pool. The mempool test program in
memcheck/tests now tests the improved red-zone stuff.
Still to be thought about is leak-checking the contents of a pool.=20
Normally, if you use malloc to allocate a pool, the entire pool will be
leak-checked at exit. This is often sufficient. However, if you use
mmap to allocate the pool, this won't happen.
This will probably be the last version of this I make for a while,
unless I come up with a major bug or someone requests additional
functionality. I'm particularly interested in what you think of the
leak-checking shortcoming.
The patch is at the usual place:
http://www.durables.org/software/valgrind
Regards,
Robert.
--=20
Robert Walsh
Amalgamated Durables, Inc. - "We don't make the things you buy."
Email: rj...@du...
|
|
From: David E. <tw...@us...> - 2004-01-14 05:22:44
|
On Tue, 2004-01-13 at 21:48, Lauren A wrote:
> Hi. I'm having a strange problem, and I was wondering
> if you had any ideas about it. My program, written in
> OCaml and C, has a seg fault in it. But when I run the
> program under Valgrind, there's no seg fault. Any
> ideas on why that would happen?
Is your program threaded with pthreads? Could be a race condition in
that case.
--
Regards,
-\- David Eriksson -/-
SynCE - http://synce.sourceforge.net
CalcEm - http://calcem.sourceforge.net
Desquirr - http://desquirr.sourceforge.net
SetiWrapper - http://setiwrapper.sourceforge.net
|
|
From: Lauren A <mus...@ya...> - 2004-01-13 20:48:21
|
Hi. I'm having a strange problem, and I was wondering if you had any ideas about it. My program, written in OCaml and C, has a seg fault in it. But when I run the program under Valgrind, there's no seg fault. Any ideas on why that would happen? Thanks very much, Lauren __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
|
From: Tom H. <th...@cy...> - 2004-01-13 19:14:12
|
In message <200...@bl...>
Jason Wood <jas...@bl...> wrote:
> Does anyone know of a way to take a memory "snapshot" - something like a
> list of all memory currently allocated, grouped by the file line number of
> where it was allocated, and sorted by the amount of memory that is
> allocated. I feel that such a thing would let me solve this issue very
> quickly :-)
You can use the VALGRIND_DO_LEAK_CHECK client request in your program
to request a leak check at any time and if you used --show-reachable=yes
when starting valgrind then it will show all blocks, but I'm afraid
you'll have to handle the resorting of the output yourself.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jason W. <jas...@bl...> - 2004-01-13 18:54:06
|
Hi, I am trying to track down a memory leak in an application. The memory leak is proving difficult to track down - valgrind's memleak check does not pick it up, which suggests to me that the memory is being cleaned up at exit, but is not being managed correctly while the app is running. Does anyone know of a way to take a memory "snapshot" - something like a list of all memory currently allocated, grouped by the file line number of where it was allocated, and sorted by the amount of memory that is allocated. I feel that such a thing would let me solve this issue very quickly :-) Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk |
|
From: Tom H. <th...@cy...> - 2004-01-13 16:08:21
|
In message <Pin...@re...>
Nicholas Nethercote <nj...@ca...> wrote:
> See attachment for a list of unimplemented MMX/SSE/SSE2 opcodes. About
> 78% are implemented. The list may contain mistakes; the names and
> opcodes of these instructions can be confusing, and I wasn't as thorough
> as I could have been. Still, it should give a good idea of what's left.
> As for a suggested order of implementation, I won't pretend to know,
> however the fact that users haven't reported them yet indicate the ones
> remaining aren't used very widely.
I've just sent a patch to the developers list to implement all bar
about three of the missing opcodes, and to try and test the ones which
were already implemented as a few of them were broken.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nissim K. <ni...@ka...> - 2004-01-13 12:36:28
|
Hi, I'm trying to use valgrind to debug a problem in the gdam-server program from here: http://gdam.ffem.org/index.html. I get this: $ valgrind -v gdam-server gdam-server: /usr/lib/valgrind/libpthread.so.0: version `GLIBC_2.1.1' not found (required by gdam-server) Sounds like some kind of version incompatibility. How does that all work? Both valgrind and gdam were compiled on the same machine. Please help me figure out how to get it to run. Thanks, -Nissim |
|
From: Tom H. <th...@cy...> - 2004-01-13 11:52:09
|
In message <76C...@us...>
Tim Lee <TL...@ft...> wrote:
> ==3526==
> Hello World
> proxy 3534 for tid 1 exited status -1, res 0
> got signal 17 in LWP 3526 (3526)
>
> valgrind: vg_signals.c:1558 (vg_async_signalhandler): Assertion
> `vgPlain_ksigismember(&uc->uc_sigmask, sigNo)' failed.
> ==3526== at 0x401749FE: (within
> /VIEWS/fes620_DEV630_linux.vws/.s/00027/8000015a3ffc7001valgrind.so)
>
> sched status:
>
> Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
> ==3526== at 0x40257BA0: sigprocmask (in /lib/libc-2.2.4.so)
> ==3526== by 0x402788F0: __libc_system (in /lib/libc-2.2.4.so)
> ==3526== by 0x80484B2: main (vtest.c:4)
>
> Here is a test program I wrote to produce the above error:
>
> int main ()
> {
> printf ("Hello World\n");
> system ("ls >/tmp/junk");
> }
I've tried this example on my systems and so far I've been unable to
reproduce the symptoms. On RedHat 9 I can't get it to fail and on
RedHat 7.2 it does fail sometimes, but with a different assertion:
valgrind: vg_proxylwp.c:973 (proxy_wait): Assertion `*status == proxy->exitcode' failed.
==31647== at 0x40175546: (within /usr/lib/valgrind/valgrind.so)
==31647== by 0x40175545: assert_fail (vg_mylibc.c:1161)
==31647== by 0x401755A2: vgPlain_core_assert_fail (vg_mylibc.c:1172)
==31647== by 0x40179087: proxy_wait (vg_proxylwp.c:973)
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==31647== at 0x402F871A: __execve (../sysdeps/unix/sysv/linux/execve.c:70)
==31647== by 0x4028C991: __libc_system (../sysdeps/posix/system.c:109)
==31647== by 0x80484F2: main (71053.c:7)
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-01-12 22:15:55
|
In message <76C...@us...>
"Lee, Tim" <TL...@ft...> wrote:
> Hello World
> proxy 3534 for tid 1 exited status -1, res 0
> got signal 17 in LWP 3526 (3526)
>
> valgrind: vg_signals.c:1558 (vg_async_signalhandler): Assertion
> `vgPlain_ksigismember(&uc->uc_sigmask, sigNo)' failed.
> ==3526== at 0x401749FE: (within
> /VIEWS/fes620_DEV630_linux.vws/.s/00027/8000015a3ffc7001valgrind.so)
>
> sched status:
>
> Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
> ==3526== at 0x40257BA0: sigprocmask (in /lib/libc-2.2.4.so)
> ==3526== by 0x402788F0: __libc_system (in /lib/libc-2.2.4.so)
> ==3526== by 0x80484B2: main (vtest.c:4)
>
> Here is a test program I wrote to produce the above error:
>
> int main ()
> {
> printf ("Hello World\n");
> system ("ls >/tmp/junk");
> }
This looks similar to bug 71053 which we haven't had a good test
case for until now.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Lee, T. <TL...@ft...> - 2004-01-12 21:46:05
|
Hi --
=20
Apologies in advance if this is a usage error on my part or as has been
documented as I am new to valgrind.
=20
I got the following error when running valgrind against when making the
'system' call:
=20
+ valgrind --leak-check=3Dyes -v --num-callers=3D20 --track-fds=3Dyes =
vtest
=3D=3D3526=3D=3D Memcheck, a memory error detector for x86-linux.
=3D=3D3526=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, by Julian =
Seward.
=3D=3D3526=3D=3D Using valgrind-2.1.0, a program supervision framework =
for
x86-linux.
=3D=3D3526=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian =
Seward.
=3D=3D3526=3D=3D Command line
=3D=3D3526=3D=3D vtest
=3D=3D3526=3D=3D Startup, with flags:
=3D=3D3526=3D=3D
--suppressions=3D/dcaclearcase/vobs/eParty/valgrind/Bin/Linux/lib/valgrin=
d
/default.supp
=3D=3D3526=3D=3D --leak-check=3Dyes
=3D=3D3526=3D=3D -v
=3D=3D3526=3D=3D --num-callers=3D20
=3D=3D3526=3D=3D --track-fds=3Dyes
=3D=3D3526=3D=3D Reading syms from /home/fes620/test/vtest
=3D=3D3526=3D=3D Reading syms from /lib/ld-2.2.4.so
=3D=3D3526=3D=3D Reading syms from
/VIEWS/fes620_DEV630_linux.vws/.s/00027/800001753ffc701cvgskin_memcheck.
so
=3D=3D3526=3D=3D Reading syms from
/VIEWS/fes620_DEV630_linux.vws/.s/00027/8000015a3ffc7001valgrind.so
=3D=3D3526=3D=3D Reading syms from /lib/libc-2.2.4.so
=3D=3D3526=3D=3D object doesn't have a symbol table
=3D=3D3526=3D=3D object doesn't have any debug info
=3D=3D3526=3D=3D Reading suppressions file:
/dcaclearcase/vobs/eParty/valgrind/Bin/Linux/lib/valgrind/default.supp
=3D=3D3526=3D=3D Estimated CPU clock rate is 997 MHz
=3D=3D3526=3D=3D=20
Hello World
proxy 3534 for tid 1 exited status -1, res 0
got signal 17 in LWP 3526 (3526)
=20
valgrind: vg_signals.c:1558 (vg_async_signalhandler): Assertion
`vgPlain_ksigismember(&uc->uc_sigmask, sigNo)' failed.
=3D=3D3526=3D=3D at 0x401749FE: (within
/VIEWS/fes620_DEV630_linux.vws/.s/00027/8000015a3ffc7001valgrind.so)
=20
sched status:
=20
Thread 1: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D =
0x0
=3D=3D3526=3D=3D at 0x40257BA0: sigprocmask (in /lib/libc-2.2.4.so)
=3D=3D3526=3D=3D by 0x402788F0: __libc_system (in /lib/libc-2.2.4.so)
=3D=3D3526=3D=3D by 0x80484B2: main (vtest.c:4)
=20
Here is a test program I wrote to produce the above error:
=20
int main ()
{
printf ("Hello World\n");
system ("ls >/tmp/junk");
}
Info related to valgrind environment and usage:
=20
valgrind command invokation: valgrind --leak-check=3Dyes -v
--num-callers=3D20 --track-fds=3Dyes vtest
valgrind version: valgrind-2.1.0
Linux distribution: Red Hat Advanced Server 2.1
Kernel version: 2.4.9-e.5
glibc version: gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.1)
=20
Thanks,
Tim
=20
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any erroneous
transmission. If you receive this message in error, please immediately
destroy it and notify the sender. You must not, directly or indirectly,
use, disclose, distribute, or copy any part of this message if you are
not the intended recipient.
=20
|
|
From: Mukund S. <mu...@sh...> - 2004-01-12 16:20:21
|
Hi=20 Attached is the small test case you asked for. The err.out file contains the errors as generated by valgrind.=20 Thanks Mukund -----Original Message----- From: Dirk Mueller [mailto:dm...@gm...]=20 Sent: Monday, January 12, 2004 7:58 AM To: val...@li... Subject: Re: [Valgrind-users] 2.6 kernel support On Monday 12 January 2004 16:24, Mukund Srinivasan wrote: > Is there a plan to support the 2.6 kernel features any > time soon? sure, you post small selfcontained examples that fail, and we'll fix them.=20 ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dirk M. <dm...@gm...> - 2004-01-12 15:57:48
|
On Monday 12 January 2004 16:24, Mukund Srinivasan wrote: > Is there a plan to support the 2.6 kernel features any > time soon? sure, you post small selfcontained examples that fail, and we'll fix them. |
|
From: Mukund S. <mu...@sh...> - 2004-01-12 15:24:36
|
Hi=20 I am trying to use valgrind under 2.6 kernel. My machine runs fedora (with 2.6 as the kernel). I am trying to run valgrind and trying to use 2.6 kernel features such as "sys/epoll". As of now none of the 2.6 kernel features such as kqueue, epoll etc is not being recognized by valgrind. Also I get lot of uninitalized memory errors from valgrind when using gethostbyname_r. I will be more than happy to provide programming examples. I have tried both the cvs tip and the stable version of valgrind. Did anyone else have success with running valgrind under 2.6 kernel? Is there a plan to support the 2.6 kernel features any time soon?=20 =20 Thanks Mukund =20 =20 |