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
(8) |
3
(9) |
4
(6) |
5
(13) |
6
(18) |
7
(2) |
|
8
(1) |
9
(6) |
10
(4) |
11
(6) |
12
(11) |
13
(3) |
14
|
|
15
(4) |
16
(5) |
17
(11) |
18
(3) |
19
(31) |
20
(2) |
21
(5) |
|
22
(3) |
23
(4) |
24
(1) |
25
(4) |
26
(7) |
27
(2) |
28
(6) |
|
29
(2) |
30
(2) |
31
(4) |
|
|
|
|
|
From: Andi K. <ak...@mu...> - 2005-05-17 20:36:33
|
Jeremy Fitzhardinge <je...@go...> writes: > Beorn Johnson wrote: > >>Then I realized my problem: my process uses 'seteuid( )' >>(before 'dlopen( )'-ing it's shared objects), which changes >>the effective uid of the process but not of '/proc/self/'. >>So, 'readlink( )' can't read "/proc/self/fd/nn", >>and the 'mmap( )' doesn't have the associated filename >>with which to generate address->name mapping. >> > Hm, interesting. I wonder if that could be considered a kernel bug... It's a redhat specific bug, side effect of execshield which considers your /proc/self/maps as a secret and changes the permissions. Just unapply the execshield patch or use a mainline kernel. -Andi |
|
From: Jeremy F. <je...@go...> - 2005-05-17 19:34:15
|
Beorn Johnson wrote:
>Then I realized my problem: my process uses 'seteuid( )'
>(before 'dlopen( )'-ing it's shared objects), which changes
>the effective uid of the process but not of '/proc/self/'.
>So, 'readlink( )' can't read "/proc/self/fd/nn",
>and the 'mmap( )' doesn't have the associated filename
>with which to generate address->name mapping.
>
Hm, interesting. I wonder if that could be considered a kernel bug...
J
|
|
From: Julian S. <js...@ac...> - 2005-05-17 13:22:02
|
> That could be it. Dennis, are you interested in taking a look to see if > that's the case, ie. how it compares with an up-to-date GNU demangler? I'd second that -- pulling the demangler more up to date would be a really useful thing to do, if you have the enthusiasm. J |
|
From: Igmar P. <mai...@jd...> - 2005-05-17 13:17:24
|
> I'm using > > GNU c++filt (C++ demangler), version 2.12.90.0.1 The one that comes from binutils 2.15 / 2.16 seems to understand both, bot the second one doesn't look right to me. Regards, Igmar |
|
From: Nicholas N. <nj...@cs...> - 2005-05-17 12:34:52
|
On Tue, 17 May 2005, Tom Hughes wrote: >>>> _ZNSt8_Rb_treeIPKcSt4pairIKS1_N5iwear14iwear_languageEESt10_Select1stIS6_ >>>> ENS4_12cstring_lessESaIS6_EEC1ERKS9_RKSA_ (stl_tree.h:730) >>>> >>>> _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE (stl_map.h:120) > > My one can sort of handle the second one: > > dellow [~] % c++filt > _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE > global constructors keyed to _ZN5iwear4i18n17locale_code_tableE And mine can handle the first, but not the second: [~] c++filt _ZNSt8_Rb_treeIPKcSt4pairIKS1_N5iwear14iwear_languageEESt10_Select1stIS6_ENS4_12cstring_lessESaIS6_EEC1ERKS9_RKSA_ std::_Rb_tree<char const*, std::pair<char const* const, iwear::iwear_language>, std::_Select1st<std::pair<char const* const, iwear::iwear_language> >, iwear::cstring_less, std::allocator<std::pair<char const* const, iwear::iwear_language> > >::_Rb_tree[in-charge](iwear::cstring_less const&, std::allocator<std::pair<char const* const, iwear::iwear_language> > const&) _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE I'm using GNU c++filt (C++ demangler), version 2.12.90.0.1 > Of course valgrind's copy of the demangler is fairly old now so we > might need to update it at some point. That could be it. Dennis, are you interested in taking a look to see if that's the case, ie. how it compares with an up-to-date GNU demangler? If you look at the 2.4 repository at KDE, look in coregrind/demangle/. If you look at the 3.0 repository at valgrind.org, look in coregrind/m_demangle/. The code within those directories is largely just a cut-and-paste job of the GNU demangler code, I believe. It might be instructive to first start by diff'ing Valgrind's code against the demangler code. Thanks. N |
|
From: Tom H. <to...@co...> - 2005-05-17 10:42:05
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> On Tuesday 17 May 2005 03:59, Nicholas Nethercote wrote:
>> On Mon, 16 May 2005, Dennis Lubert wrote:
>> > with valgrind 2.4 svn rev 414744 I have a problem with sometimes symbols
>> > not demangled. In one case it lloks just like a usual longer symbol :
>> >
>> > _ZNSt8_Rb_treeIPKcSt4pairIKS1_N5iwear14iwear_languageEESt10_Select1stIS6_
>> >ENS4_12cstring_lessESaIS6_EEC1ERKS9_RKSA_ (stl_tree.h:730)
>> >
>> > while in the other case it has some _GLOBAL prefix :
>> >
>> > _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE (stl_map.h:120)
>> >
>> > is there any trick to get valgrind to demangling these symbols too ?
>>
>> Does increasing M_VG_ERRTXT help? Probably not, but I can't think of
>> anything else.
>
> Valgrind just uses the standard GNU C++ demangler (c++filt) code.
> So first thing to try is to see if c++filt can make sense of
> either of these symbols (it can't).
My one can sort of handle the second one:
dellow [~] % c++filt
_GLOBAL__I__ZN5iwear4i18n17locale_code_tableE
global constructors keyed to _ZN5iwear4i18n17locale_code_tableE
Of course valgrind's copy of the demangler is fairly old now so we
might need to update it at some point.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-05-17 10:21:29
|
On Tuesday 17 May 2005 03:59, Nicholas Nethercote wrote: > On Mon, 16 May 2005, Dennis Lubert wrote: > > with valgrind 2.4 svn rev 414744 I have a problem with sometimes symbols > > not demangled. In one case it lloks just like a usual longer symbol : > > > > _ZNSt8_Rb_treeIPKcSt4pairIKS1_N5iwear14iwear_languageEESt10_Select1stIS6_ > >ENS4_12cstring_lessESaIS6_EEC1ERKS9_RKSA_ (stl_tree.h:730) > > > > while in the other case it has some _GLOBAL prefix : > > > > _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE (stl_map.h:120) > > > > is there any trick to get valgrind to demangling these symbols too ? > > Does increasing M_VG_ERRTXT help? Probably not, but I can't think of > anything else. Valgrind just uses the standard GNU C++ demangler (c++filt) code. So first thing to try is to see if c++filt can make sense of either of these symbols (it can't). J |
|
From: Beorn J. <beo...@ya...> - 2005-05-17 05:36:30
|
I have discovered the solution to my own problem. Internally, valgrind uses 'readlink( )' on "/proc/self/fd/nn" when 'mmap( )'-ing fd #nn (which is done for 'dlopen( )'). In my case, 'readlink()' was failing. Internally, I could use the 'allocated_fds' list (with '--track-fds=yes') to get the right behavior. Then I realized my problem: my process uses 'seteuid( )' (before 'dlopen( )'-ing it's shared objects), which changes the effective uid of the process but not of '/proc/self/'. So, 'readlink( )' can't read "/proc/self/fd/nn", and the 'mmap( )' doesn't have the associated filename with which to generate address->name mapping. I hope someone else can benefit from my experience. - Beorn Johnson Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html |
|
From: Dennis L. <pla...@in...> - 2005-05-17 04:28:56
|
Am Montag, den 16.05.2005, 03:31 +0200 schrieb Admir Efendic: > Hi! > > How do you go about checking for leaks using glib-2.0? I allocate memory > with glib functions, mainly: > - g_string_new() - for GString* > - g_new() - for mostly everything else > - g_free() - instead of doing free(). > > Now I believe the above functions use something like g_malloc, > g_realloc, etc, which may or may not be macros (not sure). > > I have a multithreaded app, using glib and NPTL threads on gentoo linux. > It goes something like: > > main.c spawns threads > my_threads.c is the code where the actual leak is > > the valgrind reports leaks in following order: > > glib.2.xxx.so > main.c > > or similar, the point being that it does not report where in > my_threads.c the leak is. It doesnt mention my_threads.c at all. Have you checked FAQ 4.4 so you use --num-callers for complete stacktrace and everything else to make stack trace more helpful ? |
|
From: Nicholas N. <nj...@cs...> - 2005-05-17 02:59:43
|
On Mon, 16 May 2005, Dennis Lubert wrote: > with valgrind 2.4 svn rev 414744 I have a problem with sometimes symbols > not demangled. In one case it lloks just like a usual longer symbol : > > _ZNSt8_Rb_treeIPKcSt4pairIKS1_N5iwear14iwear_languageEESt10_Select1stIS6_ENS4_12cstring_lessESaIS6_EEC1ERKS9_RKSA_ (stl_tree.h:730) > > while in the other case it has some _GLOBAL prefix : > > _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE (stl_map.h:120) > > is there any trick to get valgrind to demangling these symbols too ? Does increasing M_VG_ERRTXT help? Probably not, but I can't think of anything else. N |
|
From: John R.
|
> valgrind-2.4.0:
> ==21494== Valgrind detected that your program requires
> ==21494== the following unimplemented functionality:
> ==21494== x86 segment override (SEG=SS) prefix
Hopefully valgrind has reported the address of the offending instruction.
In the worst case you can fix them one at a time, as noted below.
> I don't have access to the code that uses this thing, it is inside a
> libary that I bought. Another problem is that althought I know something
> of Intel 32bits x86 Assembler I really don't know what is "segment
> override (SEG=SS) prefix".
Linux on i386 and up uses a "flat" address space map, with ss==es==ds.
[Write a hello.c program, invoke gdb on it, put a breakpoint on main(),
and run the program. When the breakpoint is hit, say "info reg"
and note that ss==es==ds==0x2b.] Thus the segment prefixes {ss, es, ds}
are interchangeable, including the default of no prefix at all (which
usually implies DS, except for some string instructions where the default
is ES.)
So, if the SS prefix is first (also there could be any of: OperandSize 0x66
[switch 16<->32 bit data], AddressSize 0x67 [switch 16<->32 bit address],
Lock 0xf0, and 2-byte opcode escape 0x0f), then it is safe to change
the SEG =SS prefix byte 0x36 into a NOP 0x90; use a binary file editor.
Otherwise: re-arrange the prefixes so that SS is first (the order does
not matter, except possibly that the 2-byte opcode escape 0x0f might
have to be last), then change it to NOP.
Either valgrind should implement all segment prefixes (it must implement
the GS segment prefix anyway to deal with gcc+glibc pthreads, and the
other segment overrides require exactly the same work), or at worst
valgrind should check that ss==ds, then ignore the SS prefix. In other
words, valgrind 2.4.0 is lazy in the derogatory sense.
--
|
|
From: Dennis L. <pla...@in...> - 2005-05-16 23:51:04
|
Hi, with valgrind 2.4 svn rev 414744 I have a problem with sometimes symbols not demangled. In one case it lloks just like a usual longer symbol : _ZNSt8_Rb_treeIPKcSt4pairIKS1_N5iwear14iwear_languageEESt10_Select1stIS6_ENS4_12cstring_lessESaIS6_EEC1ERKS9_RKSA_ (stl_tree.h:730) while in the other case it has some _GLOBAL prefix : _GLOBAL__I__ZN5iwear4i18n17locale_code_tableE (stl_map.h:120) is there any trick to get valgrind to demangling these symbols too ? greets Dennis |
|
From: Stuart B. <st...@li...> - 2005-05-16 21:52:01
|
Hi,
I'm trying to profile a new app I have written in C++ using valgrind (2.4.0=
).=20
The app uses QT embedded for the GUI (I'm running on a host machine using=20
SuSE 9.2 and a virtual frame buffer). The app also uses threads and STL=20
classes.
When I run the app from the command line, everything seems to work fine.
When I run using valgrind, the report exits early indication a segmentation=
=20
fault (see below).
=3D=3D10260=3D=3D Memcheck, a memory error detector for x86-linux.
=3D=3D10260=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward =
et al.
=3D=3D10260=3D=3D Using valgrind-2.4.0, a program supervision framework for=
x86-linux.
=3D=3D10260=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward =
et al.
=3D=3D10260=3D=3D Valgrind library directory: /usr/lib/valgrind
=3D=3D10260=3D=3D Command line
=3D=3D10260=3D=3D verifydp
=3D=3D10260=3D=3D -qws
=3D=3D10260=3D=3D Startup, with flags:
=3D=3D10260=3D=3D -v
=3D=3D10260=3D=3D Contents of /proc/version:
=3D=3D10260=3D=3D Linux version 2.6.11.9LinuSoft (stuart@vaio) (gcc versi=
on 3.3.4=20
(pre 3.3.5 20040809)) #1 Mon May 16 09:23:04 BST 2005
=3D=3D10260=3D=3D Reading syms from /home/stuart/Development/veripos/bin/ve=
rifydp=20
(0x8048000)
=3D=3D10260=3D=3D Reading syms from /lib/ld-2.3.3.so (0x1B8E4000)
=3D=3D10260=3D=3D object doesn't have any debug info
=3D=3D10260=3D=3D Reading syms from /usr/lib/valgrind/stage2 (0xB0000000)
=3D=3D10260=3D=3D Reading syms from /lib/ld-2.3.3.so (0xB1000000)
=3D=3D10260=3D=3D object doesn't have any debug info
=3D=3D10260=3D=3D Reading syms from /lib/libdl.so.2 (0xB1030000)
=3D=3D10260=3D=3D object doesn't have any debug info
=3D=3D10260=3D=3D Reading syms from /lib/tls/libc.so.6 (0xB1034000)
=3D=3D10260=3D=3D object doesn't have any debug info
=3D=3D10260=3D=3D Reading syms from /usr/lib/valgrind/vgskin_memcheck.so (0=
xB124B000)
=3D=3D10260=3D=3D Reading suppressions file: /usr/lib/valgrind/default.supp
=3D=3D10260=3D=3D
=3D=3D10260=3D=3D Signal 11 (SIGSEGV) appears to have lost its siginfo; I c=
an't go on.
=3D=3D10260=3D=3D This may be because one of your programs has consumed y=
our
=3D=3D10260=3D=3D ration of siginfo structures.
=3D=3D10260=3D=3D
=3D=3D10260=3D=3D Process terminating with default action of signal 11 (SIG=
SEGV)
=3D=3D10260=3D=3D at 0x1B8E5069: _dl_start (in /lib/ld-2.3.3.so)
=3D=3D10260=3D=3D by 0x1B8E47A6: (within /lib/ld-2.3.3.so)
=3D=3D10260=3D=3D
=3D=3D10260=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 fr=
om 0)
=3D=3D10260=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
=3D=3D10260=3D=3D malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
=3D=3D10260=3D=3D
=3D=3D10260=3D=3D No malloc'd blocks -- no leaks are possible.
=2D-10260-- TT/TC: 0 tc sectors discarded.
=2D-10260-- 2 tt_fast misses.
=2D-10260-- translate: new 2 (21 -> 435; ratio 207:10)
=2D-10260-- discard 0 (0 -> 0; ratio 0:10).
=2D-10260-- chainings: 0 chainings, 0 unchainings.
=2D-10260-- dispatch: 2 jumps (bb entries); of them 2 (100%) unchained.
=2D-10260-- 1/3 major/minor sched events.
=2D-10260-- reg-alloc: 0 t-req-spill, 79+0 orig+spill uis,
=2D-10260-- 7 total-reg-rank
=2D-10260-- sanity: 2 cheap, 1 expensive checks.
=2D-10260-- ccalls: 13 C calls, 62% saves+restores avoided (48 bytes)
=2D-10260-- 19 args, avg 0.94 setup instrs each (2 bytes)
=2D-10260-- 0% clear the stack (39 bytes)
=2D-10260-- 0 retvals, 100% of reg-reg movs avoided (0 bytes)
Segmentation fault
I check the archives, and this seemed to be attributed to the kernel (2.6.8=
).=20
I have since updated the kernel to 2.6.11, but still get the same result.
Could someone please explain what the report means, and any possible=20
solutions.
Many thanks,
Stuart.
=2D-=20
=2D--------------------------------------
Stuart Bailey BSc (hons) CEng CITP MBCS
=A0 =A0 =A0 =A0 =A0LinuSoft (Proprietor)
Linux Specialist
=A0 =A0 =A0 =A0 =A0 =A0 (01953) 601294
=A0 =A0 =A0 =A0 =A0 =A0 (07778) 383739
=A0 =A0 =A0 =A0http://www.linusoft.co.uk
=2D---------------------------------------
**********************************************************************
This email and any files transmitted with it are confidential. If you
are not the intended recipient, please email pos...@li...=20
immediately.
You should not copy or use this email or attachments for any purpose
nor disclose their contents to any other person.
NO BINDING CONTRACT WILL RESULT FROM THIS E-MAIL UNTIL SUCH TIME AS A=20
WRITTEN DOCUMENT IS SIGNED ON BEHALF OF LinuSoft.
LinuSoft cannot accept any responsibility for the completeness or=20
accuracy of this message as it has been transmitted over public networks.
*************************************************************************
|
|
From: Daniel v. H. C. <da...@ma...> - 2005-05-16 13:12:12
|
valgrind-2.4.0: ==21494== Valgrind detected that your program requires ==21494== the following unimplemented functionality: ==21494== x86 segment override (SEG=SS) prefix ==21494== This may be because the functionality is hard to implement, ==21494== or because no reasonable program would behave this way, ==21494== or because nobody has yet needed it. In any case, let us know at ==21494== valgrind.kde.org and/or try to work around the problem, if you can. ==21494== ==21494== Valgrind has to exit now. Sorry. Bye! Hi all! I cannot work around the problem (unfortunaly). So... What is the case? Hard to implement, this is not a common feature or nobody has yet needed it? I don't have access to the code that uses this thing, it is inside a libary that I bought. Another problem is that althought I know something of Intel 32bits x86 Assembler I really don't know what is "segment override (SEG=SS) prefix". I can disable this part of the code in the program, but I would not do a real test in that case. Dead end? Thank you all! Daniel Colchete |
|
From: Admir E. <ef...@so...> - 2005-05-16 01:31:35
|
Hi! How do you go about checking for leaks using glib-2.0? I allocate memory with glib functions, mainly: - g_string_new() - for GString* - g_new() - for mostly everything else - g_free() - instead of doing free(). Now I believe the above functions use something like g_malloc, g_realloc, etc, which may or may not be macros (not sure). I have a multithreaded app, using glib and NPTL threads on gentoo linux. It goes something like: main.c spawns threads my_threads.c is the code where the actual leak is the valgrind reports leaks in following order: glib.2.xxx.so main.c or similar, the point being that it does not report where in my_threads.c the leak is. It doesnt mention my_threads.c at all. The memory leak is proportional to the amount of work done by threads, so I sure it is there. Is there a way to set g_new() or g_string_new() as aliases to malloc, even tho they don't have the same form? Just in order to make sure valgrind traces them as well? Or is the problem NPTL-related? Greetings, /Admir |
|
From: Beorn J. <beo...@ya...> - 2005-05-15 19:06:46
|
[ Sigh -- by habit, I signed up for the digests, so I can't form a proper follow-up ] > You are presumably dlclosing those same files, which causes valgrind > to discard the name to address mapping so it can't then translate > stack traces involving those addresses. Good guess. However, I never call 'dlclose( )'. [I guess another hint on writing bug reports is to include information on obvious points that you are not doing]. Perhaps some other standard library might do this for me on shutdown, or perhaps an errant 'munmap( )'. But, this would not eliminate the "Reading syms ..." messages would it? Which is generated on 'dlopen( )', no? Output from a test program suggests this is true: ==15536== Reading syms from /lib/tls/libc-2.3.2.so (0x1B9FC000) ==15536== object doesn't have any debug info ==15536== TRANSLATE: 0x1B8E4C30 redirected to 0x52BFF020 before dlopen() >>> ==15536== TRANSLATE: 0x1BA6CA80 redirected to 0x1B9034E0 ==15536== TRANSLATE: 0x1BA6D140 redirected to 0x1B903E1C ==15536== Reading syms from /home/beorn/test/val/shlib2.so (0x1B90A000) before dlclose() >>> ==15536== discard syms at 0x1B90A000-0x1B90C000 in /home/beorn/test/val/shlib2.so due to munmap() ==15536== TRANSLATE: 0x1BA6CC00 redirected to 0x1B9039FC after dlclose() >>> ABCDEFG ==15536== ==15536== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 1) I omitted some details in the original post: I have set VG_N_THREADS to 1000, and VG_N_THREAD_KEYS to 500. Also, when setting one of the debug variables (mem_debug, at file scope), the debugging output ends with: unmap: addr=0x1C1EF000-0x1C1FB000 s=0xB00B4C88 ->addr=0x1C1FA000-0x1C1FB000 len=4096 ==22462== discard syms at 0x1C1EF000-0x1C1FB000 in /lib/libnss_files-2.3.2.so due to munmap() case 3: s==0xB00B4C88 deleted ==22462== ==22462== ERROR SUMMARY: 11 errors from 4 contexts (suppressed: 205 from 1) Only normal 'valgrind' output follows from there (note, this was a different run from the one I originally quoted, so the PIDs don't match). (Either way, the 'dlclose()' point is a good FAQ item). Any further hints? Thanks, - Beorn Johnson __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail |
|
From: Nicholas N. <nj...@cs...> - 2005-05-15 15:01:43
|
On Sun, 15 May 2005, Tom Hughes wrote: > You are presumably dlclosing those same files, which causes valgrind > to discard the name to address mapping so it can't then translate > stack traces involving those addresses. > > The mappings are discarded because another library might later be > loaded at the same address and valgrind wouldn't know which set of > mappings to use. > > The usual workaround is to prevent things being dlclosed when > running under valgrind. I've added a note about this to FAQ 4.4 (text)/5.4 (web). N |
|
From: Tom H. <to...@co...> - 2005-05-15 08:33:32
|
In message <200...@we...>
Beorn Johnson <beo...@ya...> wrote:
> The application depends on shared libraries, which in turn load more
> shared objects via dlopen( ). All of the shared objects explicitly
> loaded with dlopen( ) (and seemingly only these) fail to have their
> addresses translated. The program also uses pthreads, mmap/munmap,
> and shared memory (shmget( ), etc). I can look at /proc/$$/maps,
> and the addresses map to the expected shared objects in all cases I
> have checked. The run does not fork( ). It does catch lots
> of signals.
You are presumably dlclosing those same files, which causes valgrind
to discard the name to address mapping so it can't then translate
stack traces involving those addresses.
The mappings are discarded because another library might later be
loaded at the same address and valgrind wouldn't know which set of
mappings to use.
The usual workaround is to prevent things being dlclosed when
running under valgrind.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Beorn J. <beo...@ya...> - 2005-05-15 06:05:54
|
Hello,
I am having trouble getting the leak-checker to translate locations
into symbolic form (probably all of valgrind, but I'm only using
mem-check/leak-check). A typical example is here:
==31429== 84 bytes in 1 blocks are possibly lost in loss record 488 of 713
==31429== at 0x1B9036DA: operator new(unsigned) (vg_replace_malloc.c:132)
==31429== by 0x1DB63EEB: ???
==31429== by 0x1BD322F3: BasicClass::DFS(char const*, char const*, bool)
(BasicClass.cpp:71)
==31429== by 0x1DB4B800: ???
==31429== by 0x1BD32412: BasicClass::DFS(char const*, char const*, bool)
(BasicClass.cpp:92)
==31429== by 0x1D65E007: ???
==31429== by 0x1BD32412: BasicClass::DFS(char const*, char const*, bool)
(BasicClass.cpp:92)
==31429== by 0x1D0A70D8: ???
==31429== by 0x1BD32412: BasicClass::DFS(char const*, char const*, bool)
(BasicClass.cpp:92)
==31429== by 0x804AC1B: xxx_main(int, char**) (MainClass.h:66)
==31429== by 0x8049EE6: main (main.cpp:24)
(some names have been changed here).
The application depends on shared libraries, which in turn load more
shared objects via dlopen( ). All of the shared objects explicitly
loaded with dlopen( ) (and seemingly only these) fail to have their
addresses translated. The program also uses pthreads, mmap/munmap,
and shared memory (shmget( ), etc). I can look at /proc/$$/maps,
and the addresses map to the expected shared objects in all cases I
have checked. The run does not fork( ). It does catch lots
of signals.
----- Version information:
This is running valgrind 2.4.0 on Redhat AS 3.0; the application is mixed C/C++
using gcc/g++ 3.2.3; the system info is:
==31429== Contents of /proc/version:
==31429== Linux version 2.4.21-9.ELsmp (bhc...@st...)
(gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-26)) #1 SMP Thu Jan 8 17:08:56
EST 2004
uname -a is:
Linux XXX.com 2.4.21-9.ELsmp #1 SMP Thu Jan 8 17:08:56 EST 2004 i686
i686 i386 GNU/Linux)
Libc is:
-rwxr-xr-x 1 root root 1565724 Nov 7 2003
/lib/libc-2.3.2.so
lrwxr-xr-x 1 root root 13 May 6 08:29 /lib/libc.so.6
-> libc-2.3.2.so
----- What else I have tried / noticed:
I have tried a simplified test which does the same sort of
dlopen( ) operations, but there is no problem. The key bit of evidence
is that none of the 'dlopen()'-ed objects generate a "Reading syms from"
message; the last few "reading syms" messages are:
==31429== Reading syms from /lib/libgcc_s-3.2.3-20031114.so.1 (0x1BF96000)
==31429== Reading syms from /lib/tls/libc-2.3.2.so (0x1BFA2000)
==31429== Reading syms from /lib/tls/libpthread-0.60.so (0x1C0DB000)
==31429== Reading syms from /lib/libnss_files-2.3.2.so (0x1C1EF000)
Note 'ldd' on the base executable gives:
...
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6f63000)
libc.so.6 => /lib/tls/libc.so.6 (0xb6e2b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb75eb000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb6e1a000)
Later on, I get:
==31429== discard syms at 0x1C1EF000-0x1C1FB000 in /lib/libnss_files-2.3.2.so
due to munmap()
I believe this occurs before the 'dlopen()'s start; I am unsure what
is going on with this particular shared object ('libnss_file').
I tried LD_PRELOADING this library, which got rid of the
"discard syms" message, but otherwise did not change the
original problem.
I have tried turning on some of the 'debug' variables, but
never having looked into the internals of valgrind, this
hasn't been very informative to me.
Thank you for any information/suggestings/hints that you can help
out with,
Beorn Johnson
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
Discover Yahoo!
Use Yahoo! to plan a weekend, have fun online and more. Check it out!
http://discover.yahoo.com/
|
|
From: Aloys <dul...@dd...> - 2005-05-13 18:29:18
|
more people buy drugs online http://amxeyh.wth70fw7t6em0xe.meshednlngh.com |
|
From: Nicholas N. <nj...@cs...> - 2005-05-13 13:53:11
|
On Thu, 12 May 2005, Josef Weidendorfer wrote: > Have you ever tought about using Cachegrind's format for Massif for consensus > points? I.e. event names: "Number of user bytes allocated", "Number of red > zone bytes allocated", "Number of bytes freed", I have honestly never thought of doing that. > I know that the relation should be to call chains, not simple source > positions. Yes. Hmm, it could be useful. But it's not on my TODO list :) N |
|
From: Mathieu M. <mma...@ny...> - 2005-05-13 02:50:02
|
> In the newest GCC Versions its GLIBCXX_FORCE_NEW not GLIBCPP_FORCE_NEW Thanks a bunch everybody ! |
|
From: Jeroen N. W. <jn...@xs...> - 2005-05-12 15:58:17
|
> Am Donnerstag, den 12.05.2005, 17:08 +0200 schrieb Jeroen N. Witmond: >> Unfortunately, the gcc version number in the updates seems incorrect. >> From >> the original post: >> >> At 12:40 12.05.2005, mma...@ny... wrote: >> >Hello, >> > >> > I am working on a debian testing with gcc-snapshot (sudo apt-get >> >install gcc-snapshot). Which is currently a gcc 4.1. I am getting this >> >kind of error (*), eventhough my command line is: >> > >> >> >From the patch: >> >> +- With gcc 3.4 and later, that variable has changed name to >> + GLIBCXX_FORCE_NEW. >> >> Regards, >> >> Jeroen. > No, 3.4 is correct. The Variable Name has changed in 3.4 to CXX > It's good to know that. Thanks. Jeroen. |
|
From: Dennis L. <pla...@in...> - 2005-05-12 15:50:16
|
Am Donnerstag, den 12.05.2005, 17:08 +0200 schrieb Jeroen N. Witmond: > Unfortunately, the gcc version number in the updates seems incorrect. From > the original post: > > At 12:40 12.05.2005, mma...@ny... wrote: > >Hello, > > > > I am working on a debian testing with gcc-snapshot (sudo apt-get > >install gcc-snapshot). Which is currently a gcc 4.1. I am getting this > >kind of error (*), eventhough my command line is: > > > > >From the patch: > > +- With gcc 3.4 and later, that variable has changed name to > + GLIBCXX_FORCE_NEW. > > Regards, > > Jeroen. No, 3.4 is correct. The Variable Name has changed in 3.4 to CXX |
|
From: Josef W. <Jos...@gm...> - 2005-05-12 15:35:32
|
On Thursday 12 May 2005 16:46, Nicholas Nethercote wrote: > On Thu, 12 May 2005, Josef Weidendorfer wrote: > > But perhaps it is best to call it CG-format (for cachegrind or > > callgrind), and thus call the converter "op2cg". > > I'd call it the "callgrind format". Cachegrind's cg_annotate script > cannot read that format, so it seems useful to preserve the distinction > between "cachegrind format" and "callgrind format". OK. Yes, makes sense. Have you ever tought about using Cachegrind's format for Massif for consensus points? I.e. event names: "Number of user bytes allocated", "Number of red zone bytes allocated", "Number of bytes freed", I know that the relation should be to call chains, not simple source positions. Callgrind can relate events to call chains, too, and uses a concatenation of the function names in the chain (seperated by an apostrophe) for the output. Hmm... as cg_annotate would have to know about this, the separation char should be part of the format. Josef > But I guess it's up > to you, Josef. > > N > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |