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
(4) |
2
(6) |
3
(4) |
4
(5) |
5
(8) |
6
(7) |
7
(2) |
|
8
(1) |
9
|
10
(5) |
11
(5) |
12
(5) |
13
(9) |
14
(11) |
|
15
(3) |
16
(3) |
17
(10) |
18
(7) |
19
(2) |
20
|
21
(3) |
|
22
|
23
(1) |
24
(25) |
25
(3) |
26
(7) |
27
(3) |
28
|
|
29
(10) |
|
|
|
|
|
|
|
From: Tom H. <th...@cy...> - 2004-02-15 09:32:17
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Wed, 11 Feb 2004, Tom Hughes wrote:
>
> > OK. It isn't vfork as such, it's a custom fork that system uses...
> >
> > If you look at sysdeps/unix/sysv/linux/system.c in a recent glibc you
> > will see that it defines FORK() before including the generic version
> > of the system() code. That version of FORK() actually uses clone with
> > the CLONE_PARENT_SETTID flag to get the value of the child's PID in
> > a variable in the parent for cancellation.
>
> Right... so we should be able to handle this variant of clone()?
I don't see why it shouldn't work if you just add that to the list of
cases which we handle in PRE(clone).
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-15 00:03:29
|
On Wed, 11 Feb 2004, Tom Hughes wrote: > OK. It isn't vfork as such, it's a custom fork that system uses... > > If you look at sysdeps/unix/sysv/linux/system.c in a recent glibc you > will see that it defines FORK() before including the generic version > of the system() code. That version of FORK() actually uses clone with > the CLONE_PARENT_SETTID flag to get the value of the child's PID in > a variable in the parent for cancellation. Right... so we should be able to handle this variant of clone()? N |
|
From: Nicholas N. <nj...@ca...> - 2004-02-14 22:32:03
|
On Sat, 14 Feb 2004, Mathieu wrote: > > I've just installed valgrind 2.0.0 and am having problems getting it to > > work. I've complied the source on my LFS 5 system, done the make & make > > install. And now whatever I try to do I get the error message > > "/usr/bin/valgrind: '<progname>' not found in $PATH, aborting." (where > > <progname> is the program I try after valgrind). > > > > This is for everything even just "valgrind ls -l" gives this error. I'm > > obviously doing/done something really stupid, but I can't figure out > > what's wrong. > > > > valgrind --skin=memcheck ls -l > > I think their no default skin. Not quite; v2.0.0 has Memcheck as the default, as does 2.1.0; the CVS HEAD doesn't have a default, though. As for why you're getting that error, no idea. Can you try fiddling with the 'which' test in coregrind/valgrind (the startup script) to work out what's going wrong? N |
|
From: Josef W. <Jos...@gm...> - 2004-02-14 22:05:11
|
Am Saturday 14 February 2004 18:17 schrieb Nicholas Nethercote: > On Fri, 13 Feb 2004, Julie Wu wrote: > > For uninitialized read, invalid read/write, is it possible for Valgrind > > to report the runtime address of the variable/memory involved? (Not > > necessarily with Purify-like name translation) > > [snip] > > If we have the address associated with it, then it'll be easier to group > > them. > > Yes, it would be nice to have more information about the variable causing > the problem. Unfortunately, the uninitialised variable is accessed from > a register at the time the error occurs. And the variable may never have > been in a memory location -- for example, a compiler might put short-lived > variables only in registers, and never put them into memory. And for the > cases where the value has been copied from memory, it would be very > difficult to track the history of the value without hurting speed badl Perhaps I am wrong, but shouldn't debug info contain the info if a variable is mapped to a register? A debugger has to know this, too. For DWARF, some time ago I had a short look at libdwarf (from SGI). Perhaps parts can be ported to Valgrind? Josef |
|
From: Mathieu <mma...@ny...> - 2004-02-14 21:23:18
|
valgrind --skin=memcheck ls -l I think their no default skin. HTH Mathieu David Nunn wrote: > Hi, > > I've just installed valgrind 2.0.0 and am having problems getting it to > work. I've complied the source on my LFS 5 system, done the make & make > install. And now whatever I try to do I get the error message > "/usr/bin/valgrind: '<progname>' not found in $PATH, aborting." (where > <progname> is the program I try after valgrind). > > This is for everything even just "valgrind ls -l" gives this error. I'm > obviously doing/done something really stupid, but I can't figure out > what's wrong. > > Can anyone point me in the right direction? > > Thanks, > > David |
|
From: Jeremy F. <je...@go...> - 2004-02-14 18:42:58
|
On Fri, 2004-02-13 at 06:05, Erik Sundnes LXvlie wrote: > Hi, I'm having some trouble using valgrind. Likely I'm doing something > wrong, but I couldn't find any info on this problem on the valgrind > homepage. > My program uses SDL, SDL_image, opengl and glu (mesa). > I know it leaks memory, so it would be great if somebody could help me > figure out what I'm doing wrong here. > The output from valgrind is pasted below. I just reported this - it is bug http://bugs.kde.org/show_bug.cgi?id=74298 A fix for Valgrind 2.0 is unlikely, but it should be easy enough to fix for 2.1. J |
|
From: Nicholas N. <nj...@ca...> - 2004-02-14 17:20:20
|
On Fri, 13 Feb 2004, Julie Wu wrote: > For uninitialized read, invalid read/write, is it possible for Valgrind to > report the runtime address of the variable/memory involved? (Not > necessarily with Purify-like name translation) > [snip] > If we have the address associated with it, then it'll be easier to group > them. Yes, it would be nice to have more information about the variable causing the problem. Unfortunately, the uninitialised variable is accessed from a register at the time the error occurs. And the variable may never have been in a memory location -- for example, a compiler might put short-lived variables only in registers, and never put them into memory. And for the cases where the value has been copied from memory, it would be very difficult to track the history of the value without hurting speed badly. Given these difficulties, I don't think this will be done any time soon, unfortunately. N |
|
From: David N. <dav...@ho...> - 2004-02-14 12:44:24
|
Hi, I've just installed valgrind 2.0.0 and am having problems getting it to = work. I've complied the source on my LFS 5 system, done the make & make = install. And now whatever I try to do I get the error message = "/usr/bin/valgrind: '<progname>' not found in $PATH, aborting." (where = <progname> is the program I try after valgrind).=20 This is for everything even just "valgrind ls -l" gives this error. I'm = obviously doing/done something really stupid, but I can't figure out = what's wrong.=20 Can anyone point me in the right direction? Thanks, David |
|
From: Andi K. <ak...@su...> - 2004-02-14 08:41:37
|
Tom Hughes <th...@cy...> writes: > In message <200...@we...> > smiley glitter <smi...@ya...> wrote: > > > There is no mention anywhere about valgrind's support > > for 64 bit applications and nor have I access to a 64 > > bit machine to check it out. However I need to know if > > valgrind supports 64 bit applications as its critical > > in deciding its use for our project quite soon. > > There is no support for valgrinding 64 bit applications at present > although I believe it is possible to valgrind 32 bit applications > on AMD 64 machines. I haven't had a chance to try that yet though > as we've only had a suitable machine for a few days. Actually it's not that easy to valgrind 32bit on 64bit. I have been working on that. The original 1.x valgrind worked pretty well in emulation, but with 2.x the problems started. First it didn't like the 4GB address space, but that can be worked around with linux32 --3gb. Then it triggered a few bugs in the 32bit emulation that I fixed (but you need a pretty recent 2.6 kernel for the fixes). Currently it usually works, but sometimes depending on timing (e.g. strace or not) it still runs into a segfault in the signal handling. I haven't tracked that down. 2.4.x I haven't tested. It has different signal code, so it may not have some of the 2.6 bugs. At least one of the bugs I fixed was definitely in 2.4 too. I also took a short look at porting it to native 64bit. As usual I think the most work would be to make the source 64bit clean (it seems to have a lot of 32bit assumptions). With that fixed adding real AMD64 support (REX prefixes, RIP relative addressing, extended registers, MOVABS) would be probably straight-forward. -Andi |
|
From: Julie Wu
|
Hi, Continuation on the question earlier... For uninitialized read, invalid read/write, is it possible for Valgrind to report the runtime address of the variable/memory involved? (Not necessarily with Purify-like name translation) The address reported in Valgrind log seems to be the function address in the binary. I'm trying to filter out distinct Valgrind messages. e.g., char buf[256]; -- never initialized foo(buf); bar(buf); the memory involved can be accessed in multiple routines at various locations, resulting in multiple Valgrind complaints with *different* stack traces, but they are actually all of the same error. If we have the address associated with it, then it'll be easier to group them. Thanks, Julie On Tue, 3 Feb 2004, Jeremy Fitzhardinge wrote: > On Mon, 2004-02-02 at 18:23, Julie Wu wrote: > > I've used Purify a lot before. Just curious, by any chance Valgrind > > supports Purify-like address->variable name translation (when -g > > compiled)? If so, which flag shall I set? > > By default Valgrind will find static or global variable names to > describe an address. > > It will also attempt to find a C expression to describe a dynamic > address, which may be on the stack or heap. It tries, but it isn't very > consistently implemented. For a start, at present it only works with > stabs debugging (so, compile with -gstabs) - nobody has done the work to > parse the right information out of DWARF debug info yet. Also, not all > messages seem to use the VG_(describe_address) function, which is what > does all the work. And sometimes it just can't find an expression > (there's a subtle bug which means that is sometimes uses slightly out of > date information, which often doesn't work). > > So, more work to be done in this area. > > J > > |
|
From: Thomas S. U. <sc...@ap...> - 2004-02-14 00:50:13
|
On Sat, Feb 14, 2004 at 00:02:23, Tom Hughes spake thusly: > > > There is no mention anywhere about valgrind's support > > > for 64 bit applications and nor have I access to a 64 > > > bit machine to check it out. However I need to know if > > > valgrind supports 64 bit applications as its critical > > > in deciding its use for our project quite soon. > > We've had luck using the following boost libs for 64-bit targets on > > solaris: > > boost_thread > > boost_filesystem > > boost_datetime > > boost_regex > > What exactly has that got to do with valgrind? Wrong mailing, not enough sleep, too much caffiene. Not a damn thing, of course. Heh, sorry for the noise. |
|
From: Tom H. <th...@cy...> - 2004-02-14 00:06:35
|
In message <200...@we...>
smiley glitter <smi...@ya...> wrote:
> There is no mention anywhere about valgrind's support
> for 64 bit applications and nor have I access to a 64
> bit machine to check it out. However I need to know if
> valgrind supports 64 bit applications as its critical
> in deciding its use for our project quite soon.
There is no support for valgrinding 64 bit applications at present
although I believe it is possible to valgrind 32 bit applications
on AMD 64 machines. I haven't had a chance to try that yet though
as we've only had a suitable machine for a few days.
You didn't actually say what architecture you were talking about
anyway, but I'm assuming AMD as that's far more likely to happen
than anything else, including Itanium, at least in the short term.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-02-14 00:04:19
|
In message <200...@ap...>
"Thomas S. Urban" <sc...@ap...> wrote:
> On Fri, Feb 13, 2004 at 15:38:14, smiley glitter spake thusly:
>
> > There is no mention anywhere about valgrind's support
> > for 64 bit applications and nor have I access to a 64
> > bit machine to check it out. However I need to know if
> > valgrind supports 64 bit applications as its critical
> > in deciding its use for our project quite soon.
>
> We've had luck using the following boost libs for 64-bit targets on
> solaris:
> boost_thread
> boost_filesystem
> boost_datetime
> boost_regex
What exactly has that got to do with valgrind?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Thomas S. U. <sc...@ap...> - 2004-02-13 23:48:44
|
On Fri, Feb 13, 2004 at 15:38:14, smiley glitter spake thusly: > Hello folks, > > There is no mention anywhere about valgrind's support > for 64 bit applications and nor have I access to a 64 > bit machine to check it out. However I need to know if > valgrind supports 64 bit applications as its critical > in deciding its use for our project quite soon. We've had luck using the following boost libs for 64-bit targets on solaris: boost_thread boost_filesystem boost_datetime boost_regex HTH Scott |
|
From: smiley g. <smi...@ya...> - 2004-02-13 23:40:21
|
Hello folks, There is no mention anywhere about valgrind's support for 64 bit applications and nor have I access to a 64 bit machine to check it out. However I need to know if valgrind supports 64 bit applications as its critical in deciding its use for our project quite soon. Thanks for any help. regards, smile. __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html |
|
From: David E. <tw...@us...> - 2004-02-13 21:04:37
|
On Fri, 2004-02-13 at 15:05, Erik Sundnes L=F8vlie wrote:
> Hi, I'm having some trouble using valgrind. Likely I'm doing something
> wrong, but I couldn't find any info on this problem on the valgrind
> homepage.
> My program uses SDL, SDL_image, opengl and glu (mesa).
> I know it leaks memory, so it would be great if somebody could help me
> figure out what I'm doing wrong here.
The first thing you should do is to increase the length of the backtrace
with for example --num-callers=3D20 as parameter to valgrind.
> The output from valgrind is pasted below.
>=20
>=20
> [eriksul@myhost leved]$ valgrind ./leved
> =3D=3D8422=3D=3D Memcheck, a.k.a. Valgrind, a memory error detector for=
x86-linux.
> =3D=3D8422=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, by Julian Sewa=
rd.
> =3D=3D8422=3D=3D Using valgrind-2.0.0, a program supervision framework =
for x86-linux.
> =3D=3D8422=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian Sewa=
rd.
> =3D=3D8422=3D=3D Estimated CPU clock rate is 1106 MHz
> =3D=3D8422=3D=3D For more details, rerun with: -v
> =3D=3D8422=3D=3D
> =3D=3D8422=3D=3D valgrind's libpthread.so: KLUDGED call to: sem_destroy
> =3D=3D8422=3D=3D Use of uninitialised value of size 4
> =3D=3D8422=3D=3D at 0x403E546C: sigfpe_handler (in /usr/lib/libGL.so=
.1.4.050100)
> =3D=3D8422=3D=3D by 0x40187CDF: (within /usr/lib/valgrind/valgrind.s=
o)
> =3D=3D8422=3D=3D by 0x403E4E17: _mesa_init_all_x86_transform_asm (in
> /usr/lib/libGL.so.1.4.050100)
> =3D=3D8422=3D=3D by 0x40356053: _math_init_transformation (in
> /usr/lib/libGL.so.1.4.050100)
> =3D=3D8422=3D=3D
> =3D=3D8422=3D=3D Invalid read of size 2
> =3D=3D8422=3D=3D at 0x403E546C: sigfpe_handler (in /usr/lib/libGL.so=
.1.4.050100)
> =3D=3D8422=3D=3D by 0x40187CDF: (within /usr/lib/valgrind/valgrind.s=
o)
> =3D=3D8422=3D=3D by 0x403E4E17: _mesa_init_all_x86_transform_asm (in
> /usr/lib/libGL.so.1.4.050100)
> =3D=3D8422=3D=3D by 0x40356053: _math_init_transformation (in
> /usr/lib/libGL.so.1.4.050100)
> =3D=3D8422=3D=3D Address 0x6E is not stack'd, malloc'd or free'd
> Segmentation fault
--=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: Tom H. <th...@cy...> - 2004-02-13 19:31:53
|
In message <227...@we...>
Erik Sundnes LXvlie <Eri...@id...> wrote:
> ==9450== Invalid read of size 2
> ==9450== at 0x403E546C: sigfpe_handler (in /usr/lib/libGL.so.1.4.050100)
> ==9450== by 0x40187CDF: (within /usr/lib/valgrind/valgrind.so)
> ==9450== by 0x403E4E17: _mesa_init_all_x86_transform_asm (in
> /usr/lib/libGL.so.1.4.050100)
> ==9450== by 0x40356053: _math_init_transformation (in
> /usr/lib/libGL.so.1.4.050100)
> ==9450== Address 0x6E is not stack'd, malloc'd or free'd
> Segmentation fault
This looks like the same problem that we've seen before with some
OpenGL programs (usually glxgears) and certain graphics cards. I've
certainly seen it with a Matrox G550. We've never understood what is
going on though.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-13 19:12:28
|
On Fri, 13 Feb 2004, Erik Sundnes L=F8vlie wrote: > =3D=3D8422=3D=3D Invalid read of size 2 > =3D=3D8422=3D=3D at 0x403E546C: sigfpe_handler (in /usr/lib/libGL.so.1= =2E4.050100) > =3D=3D8422=3D=3D by 0x40187CDF: (within /usr/lib/valgrind/valgrind.so) > =3D=3D8422=3D=3D by 0x403E4E17: _mesa_init_all_x86_transform_asm (in /= usr/lib/libGL.so.1.4.050100) > =3D=3D8422=3D=3D by 0x40356053: _math_init_transformation (in /usr/lib= /libGL.so.1.4.050100) > =3D=3D8422=3D=3D Address 0x6E is not stack'd, malloc'd or free'd > Segmentation fault If you read the message, it tells you exactly what's the problem: your program is doing an invalid read, of size 2, of address 0x6e; that definitely looks wrong. As for whether that's caused by the static linking of pthreads, I don't know. It's not uncommon for people to have bugs in their programs that aren't normally seen, but are triggered when run under Valgrind (eg. due to slightly different memory layout). N |
|
From: Erik S. L. <Eri...@id...> - 2004-02-13 17:02:22
|
Sorry, it seems my first email was sent before I had confirmed the subscription to this mailing list. My original question is: Valgrind segfaults when I try to run my program with it. My program uses SDL, SDL_image, opengl and glu (mesa). The linker and valgrind output is as follows: ------------------------------------------------------ [eriksul@myhost leved]$ make g++ -I/usr/include/SDL -D_REENTRANT -lGL -lGLU -lSDL_image -L/usr/lib -Wl,-rpath,/usr/lib -lSDL -lpthread main.o leved.o eventhandler.o elip.o font.o state.o textstate.o editstate.o texfilestate.o savestate.o loadstate.o level.o tool.o toolselect.o toolmove.o toolpolygon.o tooltexpolygon.o toolzoom.o screen.o triangulate.o -o leved [eriksul@myhost leved]$ valgrind ./leved ==9450== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==9450== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==9450== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==9450== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==9450== Estimated CPU clock rate is 1103 MHz ==9450== For more details, rerun with: -v ==9450== ==9450== Conditional jump or move depends on uninitialised value(s) ==9450== at 0x80502DE: Level::initialize() (level.cpp:38) ==9450== by 0x805017D: Level::Level() (level.cpp:28) ==9450== by 0x80496F8: Leved::Leved() (leved.cpp:9) ==9450== by 0x8049475: main (main.cpp:12) ==9450== valgrind's libpthread.so: KLUDGED call to: sem_destroy ==9450== ==9450== Use of uninitialised value of size 4 ==9450== at 0x403E546C: sigfpe_handler (in /usr/lib/libGL.so.1.4.050100) ==9450== by 0x40187CDF: (within /usr/lib/valgrind/valgrind.so) ==9450== by 0x403E4E17: _mesa_init_all_x86_transform_asm (in /usr/lib/libGL.so.1.4.050100) ==9450== by 0x40356053: _math_init_transformation (in /usr/lib/libGL.so.1.4.050100) ==9450== ==9450== Invalid read of size 2 ==9450== at 0x403E546C: sigfpe_handler (in /usr/lib/libGL.so.1.4.050100) ==9450== by 0x40187CDF: (within /usr/lib/valgrind/valgrind.so) ==9450== by 0x403E4E17: _mesa_init_all_x86_transform_asm (in /usr/lib/libGL.so.1.4.050100) ==9450== by 0x40356053: _math_init_transformation (in /usr/lib/libGL.so.1.4.050100) ==9450== Address 0x6E is not stack'd, malloc'd or free'd Segmentation fault -------------------------------------------------------------- > In message > <203...@we...> > Erik Sundnes LXvlie <Eri...@id...> wrote: > >> Actually my program (because of SDL) seems to be linking statically to >> libpthread, and that would be a problem, right? >> How do I link dynamically to libpthread? > > Well given that dynamic linking is the default a better question would > be what are you currently doing to force static linking. Whatever it is > you need to stop doing it ;-) > > Most likely you have something like -static in your link line that you > need to remove. > > Tom > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Tom H. <th...@cy...> - 2004-02-13 14:58:59
|
In message <203...@we...>
Erik Sundnes LXvlie <Eri...@id...> wrote:
> Actually my program (because of SDL) seems to be linking statically to
> libpthread, and that would be a problem, right?
> How do I link dynamically to libpthread?
Well given that dynamic linking is the default a better question would
be what are you currently doing to force static linking. Whatever it
is you need to stop doing it ;-)
Most likely you have something like -static in your link line that you
need to remove.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Erik S. L. <Eri...@id...> - 2004-02-13 14:23:14
|
Actually my program (because of SDL) seems to be linking statically to libpthread, and that would be a problem, right? How do I link dynamically to libpthread? ------------- "Pthreads support is improving, but there are still significant limitations in that department. See the section above on Pthreads. Note that your program must be dynamically linked against libpthread.so, so that Valgrind can substitute its own implementation at program startup time. If you're statically linked against it, things will fail badly." ------------- |
|
From: Erik S. L. <Eri...@id...> - 2004-02-13 14:07:56
|
Hi, I'm having some trouble using valgrind. Likely I'm doing something wrong, but I couldn't find any info on this problem on the valgrind homepage. My program uses SDL, SDL_image, opengl and glu (mesa). I know it leaks memory, so it would be great if somebody could help me figure out what I'm doing wrong here. The output from valgrind is pasted below. [eriksul@myhost leved]$ valgrind ./leved ==8422== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==8422== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==8422== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==8422== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==8422== Estimated CPU clock rate is 1106 MHz ==8422== For more details, rerun with: -v ==8422== ==8422== valgrind's libpthread.so: KLUDGED call to: sem_destroy ==8422== Use of uninitialised value of size 4 ==8422== at 0x403E546C: sigfpe_handler (in /usr/lib/libGL.so.1.4.050100) ==8422== by 0x40187CDF: (within /usr/lib/valgrind/valgrind.so) ==8422== by 0x403E4E17: _mesa_init_all_x86_transform_asm (in /usr/lib/libGL.so.1.4.050100) ==8422== by 0x40356053: _math_init_transformation (in /usr/lib/libGL.so.1.4.050100) ==8422== ==8422== Invalid read of size 2 ==8422== at 0x403E546C: sigfpe_handler (in /usr/lib/libGL.so.1.4.050100) ==8422== by 0x40187CDF: (within /usr/lib/valgrind/valgrind.so) ==8422== by 0x403E4E17: _mesa_init_all_x86_transform_asm (in /usr/lib/libGL.so.1.4.050100) ==8422== by 0x40356053: _math_init_transformation (in /usr/lib/libGL.so.1.4.050100) ==8422== Address 0x6E is not stack'd, malloc'd or free'd Segmentation fault |
|
From: <rk...@ya...> - 2004-02-12 08:50:06
|
I am getting the following problem when I send request to a process started by Valgrind. When I run with valgrind, the program is getting killed before completing complete request. The log is given below. Can anybody help on this? Other details: Valgrind version - 2.0.0 Linux kernel - 2.4.2-2 Linux version - 7.1 The command I used to run is : /home/kaliy/valgrind-2.0.0/bin/valgrind --error-limit=no -v --leak-check=yes -q --logfile=/home/kaliy/memlog /home/kaliy/aais/bin/dpa_server Log--------------------------------- Memcheck: the `impossible' happened: add_MAC_chunk: shadow area is accessible Basic block ctr is approximately 99300000 sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==5772== at 0x4002BBAC: malloc (vg_replace_malloc.c:153) ==5772== by 0x4193ECE4: AppMsg::encode(char **, int *) (appmsg.C:569) ==5772== by 0x419475F9: AbstractServer::go(ParameterList &, int) (AbstractServer.C:430) ==5772== by 0x41946E4D: AbstractServer::go(int) (AbstractServer.C:204) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: js...@ac... In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. ___________________________________________________________ BT Yahoo! Broadband - Free modem offer, sign up online today and save £80 http://btyahoo.yahoo.co.uk |
|
From: Tom H. <th...@cy...> - 2004-02-12 08:24:08
|
In message <107...@id...>
Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca> wrote:
> While running some SSE optimized code (not the same program as in last
> message) with valgrind 2.1.0, I get the following error:
>
> frame size: 160
> 0: SSE2a1_MRdQQ 0xF:0xC6:0x55:0x55(t34)
>
> Memcheck: the `impossible' happened:
> memcheck_instrument: unhandled case
I believe the CVS head code should handle this - the fix was in my
patch that Nick committed yesterday.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jean-Marc V.
|
While running some SSE optimized code (not the same program as in last
message) with valgrind 2.1.0, I get the following error:
frame size: 160
0: SSE2a1_MRdQQ 0xF:0xC6:0x55:0x55(t34)
Memcheck: the `impossible' happened:
memcheck_instrument: unhandled case
Basic block ctr is approximately 0
=3D=3D16868=3D=3D at 0x401593A8: vgPlain_core_panic (vg_mylibc.c:1121)
=3D=3D16868=3D=3D by 0x401593A7: panic (vg_mylibc.c:1117)
=3D=3D16868=3D=3D by 0x401593F0: vgPlain_skin_panic (vg_mylibc.c:1127)
=3D=3D16868=3D=3D by 0x400128E3: memcheck_instrument (mc_translate.c:118=
7)
sched status:
Thread 1: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D 0x0
=3D=3D16868=3D=3D at 0x80532CA: fir_mem2_10 (in
/home/jm/dsp/speex/libspeex/testenc)
=3D=3D16868=3D=3D by 0x804AA26: nb_encode (in
/home/jm/dsp/speex/libspeex/testenc)
=3D=3D16868=3D=3D by 0x80495A4: speex_encode (in
/home/jm/dsp/speex/libspeex/testenc)
=3D=3D16868=3D=3D by 0x8048AE0: main (in /home/jm/dsp/speex/libspeex/tes=
tenc)
Setup is:
Valgrind 2.1.0
Fedora Core 1
Kernel 2.6.2-mm1 highmem (4G)
Pentium-M 1.6 GHz
Program uses only SSE1 intrinsics and compiled with -O3 -march=3Dpentium3
-msse
Jean-Marc
--=20
Jean-Marc Valin, M.Sc.A., ing. jr.
LABORIUS (http://www.gel.usherb.ca/laborius)
Universit=E9 de Sherbrooke, Qu=E9bec, Canada
|