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
(11) |
2
|
|
3
|
4
(7) |
5
|
6
(1) |
7
(2) |
8
(6) |
9
|
|
10
(9) |
11
(4) |
12
(6) |
13
(12) |
14
(13) |
15
|
16
(7) |
|
17
|
18
(8) |
19
(2) |
20
(11) |
21
(6) |
22
(9) |
23
(1) |
|
24
(1) |
25
(1) |
26
(1) |
27
(20) |
28
(5) |
29
(2) |
30
(2) |
|
31
(3) |
|
|
|
|
|
|
|
From: Jonathan A. Z. <jon...@nu...> - 2004-10-16 22:13:39
|
Hi! Valgrind has really helped me to clean up my code, except one particular leak it's reporting that doesn't report any type of line number or function (at least one that belongs to me). Any ideas on how to track this back, or what it means not to have this information? ==25265== 32704 bytes in 8 blocks are still reachable in loss record 1 of 1 ==25265== at 0x1B904A90: malloc (vg_replace_malloc.c:131) ==25265== by 0x80649F8: my_once_alloc (in /usr/local/dev/dspam/dspam) ==25265== by 0x8064CFF: init_state_maps (in /usr/local/dev/dspam/dspam) ==25265== by 0x8065447: init_available_charsets (in /usr/local/dev/dspam/dspam) |
|
From: Nicholas N. <nj...@ca...> - 2004-10-16 12:00:10
|
On Sat, 16 Oct 2004, [iso-8859-15] Andr=E9 W=F6bbeking wrote:
> I know that I can use * but are there any other patterns (i.e. [a-z],
> {a,b})?
I think you can use '?' to match any single character, but nothing beyond=
=20
that.
N |
|
From: <Woe...@on...> - 2004-10-16 09:45:08
|
Hi,
I know that I can use * but are there any other patterns (i.e. [a-z],=20
{a,b})?=20
I want to suppress calloc(), malloc() and realloc() and I don't want to=20
use *alloc, {c,m,re}alloc would be fine.
Cheers,
Andr=E9
|
|
From: Bill S. <bi...@cl...> - 2004-10-14 18:03:42
|
Tom Hughes wrote: > > In message <416...@cl...> > Bill Somerville <bi...@cl...> wrote: > > > valgrind: vg_libpthread.c:2333 (read): Assertion `read_ptr != ((void > > *)0) && read_ptr != read' failed. > > Bug 88614 is the current record for this problem. Thanks for that - I hadn't spotted that. Not sure I can add much, I'm using gcc 3.4.2 to build with libc.so.6 libgcc_s.so.1 I'll watch that bug for a fix. Had a look at the code and it appears to be intercepting read() calls in libpthread but why it can't lookup the dyn symbol I've got no idea. Perhaps the dlopen isn't getting called for some reason (or its been dlclosed). By the way I always have trouble looking up bugs in Bugzilla, can you summarize how you found that; my searches invariably find no bugs at all! > > Tom > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users Bill Somerville |
|
From: Tom H. <th...@cy...> - 2004-10-14 17:15:39
|
In message <416...@cl...>
Bill Somerville <bi...@cl...> wrote:
> valgrind: vg_libpthread.c:2333 (read): Assertion `read_ptr != ((void
> *)0) && read_ptr != read' failed.
Bug 88614 is the current record for this problem.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dirk M. <dm...@gm...> - 2004-10-14 17:05:08
|
On Thursday 14 October 2004 18:25, Bill Somerville wrote: > Upon downloading valgrind 2.2.0 sources and compiling (after editing out > some ppdev ioctl defines that don't exist on my driver). I get the > following when trying to run. In fact version below is 2.3.0.CVS which > gives the same error (but I didn't need to edit this version to > compile). which distribution are you using? Dirk |
|
From: David E. <tw...@us...> - 2004-10-14 17:01:33
|
On Thu, 2004-10-14 at 18:25, Bill Somerville wrote:
> Upon downloading valgrind 2.2.0 sources and compiling (after editing out
> some ppdev ioctl defines that don't exist on my driver). I get the
> following when trying to run. In fact version below is 2.3.0.CVS which
> gives the same error (but I didn't need to edit this version to
> compile).
>
> [snip]
>
> ==31060== Address 0x52BFDD1C is just below %esp. Possibly a bug in
> GCC/G++
> ==31060== v 2.96 or 3.0.X. To suppress, use:
> --workaround-gcc296-bugs=yes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Did you try the suggested parameter to valgrind?
Btw, you never wrote anything about your Linux distribution, kernel
version or compiler.
--
Regards,
-\- David Eriksson -/-
SynCE - http://synce.sourceforge.net
CalcEm - http://calcem.sourceforge.net
ScummVM - http://scummvm.sourceforge.net
Desquirr - http://desquirr.sourceforge.net
SetiWrapper - http://setiwrapper.sourceforge.net
|
|
From: Tom H. <th...@cy...> - 2004-10-14 16:58:27
|
In message <1097769658.1507.21.camel@pc_espe>
Esther Parrilla Endrino <est...@de...> wrote:
> Well, I am using POSIX pthread library and I have already seen in the
> Valgrind documentation this library contains some memory leaks, so for
> that reason I suppose they appear as 'suppresed'.
There is a single small leak in the threads library, and that is
memory that could only be freed at exit time anyway so it doesn't
really matter,
> But what about the other error:
>
> ==25573== malloc/free: in use at exit: 1174263 bytes in 35554 blocks.
> ==25573== malloc/free: 126553 allocs, 90999 frees, 22499531 bytes
>
> Is this error related to the pthread errors and for that reason is
> displayed after those ones?
No. That is a summary of the memory in use when the program exits
and is printed after the leak reports.
> I have checked the full code and all malloc/free commands seems to be
> OK, and there are no memory leaks...
Indeed there aren't. What there is however is a lot of allocated
memory which your program still has valid pointers to when it exits.
If you want all the memory blocks to be reported rather then just
those that are no longer reaachable, then add this:
--show-reachable=yes
> Could these memory leaks be caused by pthread library?
No.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: David E. <tw...@us...> - 2004-10-14 16:57:15
|
On Thu, 2004-10-14 at 18:00, Esther Parrilla Endrino wrote:
> ==25573== LEAK SUMMARY:
> ==25573== definitely lost: 0 bytes in 0 blocks.
> ==25573== possibly lost: 0 bytes in 0 blocks.
> ==25573== still reachable: 1174263 bytes in 35554 blocks.
> ==25573== Reachable blocks (those to which a pointer was found) are not
> shown.
> ==25573== To see them, rerun with: --show-reachable=yes
^^^^^^^^^^^^^^^^^^^^
Did you ever see that message and suggested command line parameter?
--
Regards,
-\- David Eriksson -/-
SynCE - http://synce.sourceforge.net
CalcEm - http://calcem.sourceforge.net
ScummVM - http://scummvm.sourceforge.net
Desquirr - http://desquirr.sourceforge.net
SetiWrapper - http://setiwrapper.sourceforge.net
|
|
From: Bill S. <bi...@cl...> - 2004-10-14 16:31:37
|
Upon downloading valgrind 2.2.0 sources and compiling (after editing out some ppdev ioctl defines that don't exist on my driver). I get the following when trying to run. In fact version below is 2.3.0.CVS which gives the same error (but I didn't need to edit this version to compile). Can anyone help? valgrind --tool=memcheck ls -l ==31060== Memcheck, a memory error detector for x86-linux. ==31060== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==31060== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. ==31060== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==31060== For more details, rerun with: -v ==31060== ==31060== Conditional jump or move depends on uninitialised value(s) ==31060== at 0x1B8E6011: _dl_start (do-rel.h:46) ==31060== by 0x1B8E5DB5: (within /lib/ld-2.2.2.so) ==31060== ==31060== Conditional jump or move depends on uninitialised value(s) ==31060== at 0x1B8E60B8: _dl_start (do-rel.h:63) ==31060== by 0x1B8E5DB5: (within /lib/ld-2.2.2.so) ==31060== ==31060== Invalid read of size 4 ==31060== at 0x1B8E6318: _dl_start_final (rtld.c:263) ==31060== by 0x1B8E6089: _dl_start (rtld.c:199) ==31060== by 0x1B8E5DB5: (within /lib/ld-2.2.2.so) ==31060== Address 0x52BFDD1C is just below %esp. Possibly a bug in GCC/G++ ==31060== v 2.96 or 3.0.X. To suppress, use: --workaround-gcc296-bugs=yes ==31060== valgrind: vg_libpthread.c:2333 (read): Assertion `read_ptr != ((void *)0) && read_ptr != read' failed. ==31060== Please report this bug at: valgrind.kde.org ==31060== ==31060== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 2 from 1) ==31060== malloc/free: in use at exit: 598 bytes in 4 blocks. ==31060== malloc/free: 4 allocs, 0 frees, 598 bytes allocated. ==31060== For a detailed leak analysis, rerun with: --leak-check=yes ==31060== For counts of detected errors, rerun with: -v Bill Somerville |
|
From: Esther P. E. <est...@de...> - 2004-10-14 16:03:05
|
Hello all, I am running Valgrind to check memory leaks in a C executable file (example) that is calling a dynamic library (.so) I have developed myself. I run Valgrind with the following options, to get full information: valgrind --logfile-fd=9 --leak-check=yes -v ./example 9> output The output file contains the full error information and it displays the following: ********************************************* ==25573== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 3) --25573-- --25573-- supp: 1 __pthread_mutex_unlock/_IO_funlockfile --25573-- supp: 15 pthread_error/__pthread_mutex_destroy/_IO_default_finish --25573-- supp: 1 pthread_error/__pthread_mutex_destroy/__closedir ==25573== malloc/free: in use at exit: 1174263 bytes in 35554 blocks. ==25573== malloc/free: 126553 allocs, 90999 frees, 22499531 bytes allocated. ==25573== ==25573== searching for pointers to 35554 not-freed blocks. ==25573== checked 10447172 bytes. ==25573== ==25573== definitely lost: 0 bytes in 0 blocks. ==25573== possibly lost: 0 bytes in 0 blocks. ==25573== still reachable: 1174263 bytes in 35554 blocks. ==25573== ==25573== LEAK SUMMARY: ==25573== definitely lost: 0 bytes in 0 blocks. ==25573== possibly lost: 0 bytes in 0 blocks. ==25573== still reachable: 1174263 bytes in 35554 blocks. ==25573== Reachable blocks (those to which a pointer was found) are not shown. ==25573== To see them, rerun with: --show-reachable=yes ==25573== --25573-- lru: 1461 epochs, 0 clearings. --25573-- translate: new 20125 (305073 -> 4356072), discard 0 (0 -> 0). --25573-- dispatch: 73050000 basic blocks, 1463/1103215 sched events, 874605 tt_fast misses. --25573-- reg-alloc: 6744 t-req-spill, 788038+50897 orig+spill uis, 107245 total-reg-r. --25573-- sanity: 1464 cheap, 59 expensive checks. ********************************************* Well, I am using POSIX pthread library and I have already seen in the Valgrind documentation this library contains some memory leaks, so for that reason I suppose they appear as 'suppresed'. But what about the other error: ==25573== malloc/free: in use at exit: 1174263 bytes in 35554 blocks. ==25573== malloc/free: 126553 allocs, 90999 frees, 22499531 bytes Is this error related to the pthread errors and for that reason is displayed after those ones? I have checked the full code and all malloc/free commands seems to be OK, and there are no memory leaks... Could these memory leaks be caused by pthread library? How can I get the function that is causing this error? Which Valgrind option can I use to debug? I have already set the '-g' debugging flag to all Makefiles (the Makefile of the library and the one for the executable...) Thanks in advance, I am newbie with Valgrind and could not find more info in the web's doc! :( esther -- ~ Code matters more than comercials ~ -- |
|
From: Tom H. <th...@cy...> - 2004-10-14 10:36:42
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Thu, 14 Oct 2004, Tom Hughes wrote:
>
>>> First, change in "vg_unsafe.h" the include from <net/if.h> to <linux/if.h>
>>> Second, add in "vg_unsafe.h" just before (to make sure that the second
>>> if.h version is included):
>>> #define _LINUX_IF_H_
>>> include <linux/mii.h>
>>
>> Neither of these is a good idea - the two file do two different things
>> and there is no guarantee that the structures will be the same. One is
>> the user visible structure for the glibc interface and one is the kernel
>> visible structure for the system call interface.
>
> I thought the first option seemed ok... and that the same thing should
> really be done for pretty much every non-kernel header mentioned in
> vg_unsafe.h -- it should be replaced with the equivalent kernel header.
> Tom, can you explain further why the first option is bad?
Actually I think you're right - the first option is the way to go.
I had thought it was the other way around - that we were including
the kernel header and some other header was including the glibc header
but obviously not.
Assuming that we're only using it for the system call interface then
it should be the kernel header that we pull in.
>> The whole issue of the kernel interface and which headers to use is a
>> complete swamp that Nick is looking at.
>
> Yes, I haven't come to grips with it yet. However, it seems like our
> copying of parts of kernel files and prefixing with vki/VKI is
> ultimately not a good idea, because the types/macros can change over
> time. What seems to be the right way to do things is to just use the
> kernel headers installed on the system. But then we have to be very
> careful not to mix up glibc and kernel types/macros; this could be
> done by just never using glibc, althought that will be hard in
> general, as we already rely on it somewhat.
As far as the system call interface goes we should probably use the
kernel headers and just make sure that vg_syscalls.c never includes
any glibc headers.
For other parts of the system we may still have to use vki versions
because so that we can pull in glibc headers as necessary I guess.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-10-14 10:32:41
|
On Thu, 14 Oct 2004, Tom Hughes wrote: >> First, change in "vg_unsafe.h" the include from <net/if.h> to <linux/if.h> >> Second, add in "vg_unsafe.h" just before (to make sure that the second >> if.h version is included): >> #define _LINUX_IF_H_ >> include <linux/mii.h> > > Neither of these is a good idea - the two file do two different things > and there is no guarantee that the structures will be the same. One is > the user visible structure for the glibc interface and one is the kernel > visible structure for the system call interface. I thought the first option seemed ok... and that the same thing should really be done for pretty much every non-kernel header mentioned in vg_unsafe.h -- it should be replaced with the equivalent kernel header. Tom, can you explain further why the first option is bad? > The whole issue of the kernel interface and which headers to use is a > complete swamp that Nick is looking at. Yes, I haven't come to grips with it yet. However, it seems like our copying of parts of kernel files and prefixing with vki/VKI is ultimately not a good idea, because the types/macros can change over time. What seems to be the right way to do things is to just use the kernel headers installed on the system. But then we have to be very careful not to mix up glibc and kernel types/macros; this could be done by just never using glibc, althought that will be hard in general, as we already rely on it somewhat. N |
|
From: Tom H. <th...@cy...> - 2004-10-14 09:54:15
|
In message <BAY...@ho...>
Sefer Tov <se...@ho...> wrote:
> The file "vg_unsafe.h" includes both <linux/mii.h> and <net/if.h>
> however, it appears that mii.h also includes <linux/if.h> (which
> conflicts with <net/if.h> because they define the structures but use
> different preprocessor defines to exclude their reprocessing -
> _LINUX_IF_H_ and _LINUX_NET_H_)
I reordered the includes recently to try and resolve this problem
and I thought somebody had confirmed that CVS was OK now.
> First, change in "vg_unsafe.h" the include from <net/if.h> to <linux/if.h>
> Second, add in "vg_unsafe.h" just before (to make sure that the second
> if.h version is included):
> #define _LINUX_IF_H_
> include <linux/mii.h>
Neither of these is a good idea - the two file do two different things
and there is no guarantee that the structures will be the same. One is
the user visible structure for the glibc interface and one is the kernel
visible structure for the system call interface.
The whole issue of the kernel interface and which headers to use is a
complete swamp that Nick is looking at.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Sefer T. <se...@ho...> - 2004-10-14 09:17:19
|
Hi,
There is a certain bug in Valgrind, ranging from Valgrind 2.2.0 and
throughout the HEAD cvs branch.
It's a result of redefinition of certain structures (on certain
architectures, like the newest Mandrake distribution 10.1 and possibly
others).
The file "vg_unsafe.h" includes both <linux/mii.h> and <net/if.h> however,
it appears that mii.h also includes <linux/if.h> (which conflicts with
<net/if.h> because they define the structures but use different preprocessor
defines to exclude their reprocessing - _LINUX_IF_H_ and _LINUX_NET_H_)
There are a few obvious solutions to this, like:
First, change in "vg_unsafe.h" the include from <net/if.h> to <linux/if.h>
Second, add in "vg_unsafe.h" just before (to make sure that the second if.h
version is included):
#define _LINUX_IF_H_
include <linux/mii.h>
Both seems to work and make valgrind compile and work just fine.
Can you please add one of these solution to the cvs head, so that the
upcoming releases would compile on newer Linux distros?
Thanks,
Sefer.
Here is the error I was getting consistently for the past couple of weeks.
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I../coregrind
-I../coregrind/x86 -I../coregrind/x86-linux -I../include -I../include
-I../include/x86 -DVG_LIBDIR="\"/opt/valgrind/lib/valgrind"\" -I./demangle
-DKICKSTART_BASE=0xb0000000 -DVG_PLATFORM="\"x86-linux"\" -Winline -Wall
-Wshadow -O -fno-omit-frame-pointer -mpreferred-stack-boundary=2 -g
-DELFSZ=32 -MT vg_syscalls.o -MD -MP -MF ".deps/vg_syscalls.Tpo" \
-c -o vg_syscalls.o `test -f 'vg_syscalls.c' || echo './'`vg_syscalls.c; \
then mv -f ".deps/vg_syscalls.Tpo" ".deps/vg_syscalls.Po"; \
else rm -f ".deps/vg_syscalls.Tpo"; exit 1; \
fi
In file included from /usr/include/linux/msg.h:5,
from vg_unsafe.h:57,
from vg_syscalls.c:35:
/usr/include/linux/list.h:685:2: warning: #warning "don't include kernel
headers in userspace"
In file included from /usr/include/linux/mii.h:12,
from vg_unsafe.h:77,
from vg_syscalls.c:35:
/usr/include/linux/if.h:95: error: redefinition of `struct ifmap'
/usr/include/linux/if.h:131: error: redefinition of `struct ifreq'
/usr/include/linux/if.h:181: error: redefinition of `struct ifconf'
make[4]: *** [vg_syscalls.o] Error 1
make[4]: Leaving directory `/home/sefer/t/valgrind/coregrind'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/sefer/t/valgrind/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/sefer/t/valgrind/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/sefer/t/valgrind'
make: *** [all] Error 2
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.com/
|
|
From: Bryan O'S. <bo...@se...> - 2004-10-14 05:21:03
|
On Wed, 2004-10-13 at 16:52 -0700, Madhu M Kurup wrote: > Not sure if that is the cause as frequently I've had demangled entries > cut off midway. > coregrind/core.h: > 124: /* Max length of a text fragment used to construct error messages. > */ > 125: #define M_VG_ERRTXT 512 > > Perhaps someone can answer to this question, but is there a reason why > that shouldn't be something on the order of 2048? Oh, dear. If 512 is causing truncation, then 2048 surely won't be enough. It's quite easy to generate C++ symbols that demangle to 8K in length. Many of those masochistic C++ "let's write everything as a heap of templates and optimise everything we don't need away at compile time" libraries are going to blow right past that. <b |
|
From: Madhu M K. <mm...@ya...> - 2004-10-13 23:52:39
|
Hmm: On Wed, 2004-10-13 at 16:15, Bryan O'Sullivan wrote: > On Wed, 2004-10-13 at 23:04 +0200, Dennis Lubert wrote: > > _ZNSt8_Rb_treeIPKcSt4pairIKS1_SsESt10_Select1stIS4_EN5iwear12cstring_lessESaIS4_EE12insert_equalISt17_Rb_tree_iteratorIS4_RS4_PS4_EEEvT_SG_ > > Maybe valgrind is passing an insufficiently large buffer to > cplus_demangle? Using c++filt, this symbol expands to 1418 bytes. > Not sure if that is the cause as frequently I've had demangled entries cut off midway. Which is sort of a pet peeve of mine - I've had a bunch of times when I been forced to rebuild valgrind for different users who cant use the "default" build since the setting in question is far far too conservative (IMHO). coregrind/core.h: 124: /* Max length of a text fragment used to construct error messages. */ 125: #define M_VG_ERRTXT 512 Perhaps someone can answer to this question, but is there a reason why that shouldn't be something on the order of 2048? I did not believe this was "a bug" since users could work around it by rebuilding valgrind, but I can open one up...... Cheerio, M -- Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Bryan O'S. <bo...@se...> - 2004-10-13 23:16:05
|
On Wed, 2004-10-13 at 23:04 +0200, Dennis Lubert wrote: > _ZNSt8_Rb_treeIPKcSt4pairIKS1_SsESt10_Select1stIS4_EN5iwear12cstring_lessESaIS4_EE12insert_equalISt17_Rb_tree_iteratorIS4_RS4_PS4_EEEvT_SG_ Maybe valgrind is passing an insufficiently large buffer to cplus_demangle? Using c++filt, this symbol expands to 1418 bytes. <b |
|
From: Dennis L. <pla...@gm...> - 2004-10-13 21:04:09
|
Hi people,
Im using valgrind from cvs, and noticed that in a few cases, something from
C++ is not demangled by valgrind. Do I need to tell valgrind something else
? Most things are demangled correctly.
Im using gcc 3.3.3 on a SuSE machine.
This is the output by valgrind :
by 0x1B96B3D7:
_ZNSt8_Rb_treeIPKcSt4pairIKS1_SsESt10_Select1stIS4_EN5iwear12cstring_lessESaIS4_EE12insert_equalISt17_Rb_tree_iteratorIS4_RS4_PS4_EEEvT_SG_
(stl_tree.h:1150)
by 0x1B96A3A8:
_ZNSt8multimapIPKcSsN5iwear12cstring_lessESaISt4pairIKS1_SsEEE6insertISt17_Rb_tree_iteratorIS6_RS6_PS6_EEEvT_SE_
(stl_multimap.h:363)
The multimap there is declared as following :
multimap<const char *, string, iwear::cstring_less>
while the insert operation done on it is this :
its insert(iterator,iterator) function
Another not demangled name is :
by 0x1B986722: _GLOBAL__I__ZN5iwear3uid6wehaveE (stl_set.h:100)
which is declared as following :
class uid
{
static set<iwear::uid*,deref_less<iwear::uid*> > wehave;
}
any hints ?
greets
Dennis
Carpe quod tibi datum est
|
|
From: Tom H. <th...@cy...> - 2004-10-13 11:43:07
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> How many times has this RPATH problem come up? Is it worth an entry
> in the FAQ? Even better, is there a way we can auto-detect and deal
> with it?
I'm not aware of it having come up before but it might have done.
Given that we are acting as the ELF loader we ought to be able to
detect it - you just need to look for a DT_RPATH entry in the dynamic
attributes in the ELF file. I don't think we can do anything other
than warn however as it would require altering the ELF headers...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-10-13 11:15:41
|
In message <20041013102826.GC6518@malin>
Karl Hasselström <kh...@tr...> wrote:
> What I did was I dropped /usr/lib and /lib from my LD_LIBRARY_PATH,
> LIBRARY_PATH and LD_RUN_PATH. Now all I have to do is figure out
> exactly which of them is being used for RPATH by the build system . . .
> but I won't bore you with that problem. Thanks again!
It's LD_RUN_PATH that controls the RPATH setting in the binary.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-10-13 10:59:06
|
On Wed, 13 Oct 2004, Karl Hasselstr=F6m wrote: >> I would suggest that you either drop the system libraries from >> RPATH, use RUNPATH instead of RPATH, or add the valgrind library >> directory to the RPATH so that valgrind pthread library is found. > > Yes, it works now! Thanks a lot! How many times has this RPATH problem come up? Is it worth an entry in=20 the FAQ? Even better, is there a way we can auto-detect and deal with it? N |
|
From: Karl <kh...@tr...> - 2004-10-13 10:56:44
|
On 2004-10-13 11:22:24 +0100, Tom Hughes wrote:
> That shouldn't work - the i686 libpthread will use clone just as
> much as the tls one will. You really need the valgrind one.
Then I guess that the messages I'm seeing about
/lib/i686/libpthread-0.10.so must be mistaken, or something. :-P
> I don't understand where that RPATH setting in the binary is coming
> from though if you don't have those directories in LD_RUN_PATH and
> aren't using linker command line options to set it.
They are in my LD_RUN_PATH . . . or were -- see my last post. I just
figured out that this is the culprit (by adding unique nonexisting
directories to each of LD_RUN_PATH, LD_LIBRARY_PATH, and LIBRARY_PATH,
and seeing which showed up in RPATH).
It seems that the bug here is my reckless trial-and-error use of
linker environment variables. I have yet to find a decent tutorial for
these . . . is there a decent Linking for Dummies somewhere out there?
--
Karl Hasselström, kh...@tr...
www.treskal.com/kalle
|
|
From: Karl <kh...@tr...> - 2004-10-13 10:28:35
|
On 2004-10-13 10:45:48 +0100, Tom Hughes wrote:
> The RPATH is your problem - you have /lib in there so the libpthread
> in /lib will be found via the RPATH before LD_LIBRARY_PATH is
> searched which is what would locate the valgrind version.
>
> The way things are supposed to work is that valgrind adds it's own
> library directory to LD_LIBRARY_PATH before starting the client
> program so that the valgrind pthread library is found. Unfortunately
> because RPATH takes priority over LD_LIBRARY_PATH (see man ld.so for
> the search rules) the system one is being found first.
>
> It's highly unusual to add the system library directories to the
> RPATH in that way - normally you just add any special directories
> that your program needs and let the system do it's default stuff to
> find the system libraries.
>
> I would suggest that you either drop the system libraries from
> RPATH, use RUNPATH instead of RPATH, or add the valgrind library
> directory to the RPATH so that valgrind pthread library is found.
Yes, it works now! Thanks a lot!
What I did was I dropped /usr/lib and /lib from my LD_LIBRARY_PATH,
LIBRARY_PATH and LD_RUN_PATH. Now all I have to do is figure out
exactly which of them is being used for RPATH by the build system . . .
but I won't bore you with that problem. Thanks again!
--
Karl Hasselström, kh...@tr...
www.treskal.com/kalle
|
|
From: Tom H. <th...@cy...> - 2004-10-13 10:22:52
|
In message <20041013094849.GB6518@malin>
Karl Hasselström <kh...@tr...> wrote:
> I stripped those first two paths (/home/kha/local/lara.hq.vtech/lib
> and /home/kha/local/generic/lib) from my LD_LIBRARY_PATH, LIBRARY_PATH
> and LD_RUN_PATH, rebuilt everything, and got an RPATH of
> /usr/X11R6/lib:/usr/lib:/lib:/usr/local/lib. For some unfathomable
> reason, this caused the program to use /lib/i686/libpthread-0.10.so
> instead of /lib/tls/libpthread-0.61.so, and valgrind worked. It still
> doesn't use valgrind's libpthread.so, but apparently
> /lib/i686/libpthread-0.10 is nice enough.
That shouldn't work - the i686 libpthread will use clone just as much
as the tls one will. You really need the valgrind one.
The selection between the i686 and tls versions should be triggered by
the setting of LD_ASSUME_KERNEL.
I don't understand where that RPATH setting in the binary is coming
from though if you don't have those directories in LD_RUN_PATH and
aren't using linker command line options to set it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|