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
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
|
2
(2) |
3
|
4
|
|
5
(2) |
6
|
7
|
8
(3) |
9
|
10
|
11
|
|
12
|
13
(4) |
14
(3) |
15
|
16
(4) |
17
(1) |
18
(1) |
|
19
|
20
(1) |
21
(1) |
22
(1) |
23
(1) |
24
|
25
|
|
26
|
27
(1) |
28
|
29
|
30
(8) |
31
|
|
|
From: Julian S. <js...@ac...> - 2013-05-30 22:31:25
|
On 05/30/2013 09:52 PM, Dieter, William R wrote: > I followed the instructions in README.android, setting HWKIND to > generic, and making to following changes to get valgrind to build: Cross-compiling doesn't work well from MacOS hosts. Those instructions work better on Linux hosts. > and included the --smc-check=all in the VGPARAMS, because it sounded > like it would be required for an x86 build. Yes. > m_debuginfo/readelf.c:577 (get_elf_symbol_info): Assertion 'in_rx' failed. This happens when reading debug info (line numbers etc) from some .so, or the main executable. These tend to be hard to diagnose. First, find out which object is causing the problem, by rerunning with -v. Then, ideally send me the object. If you can't do that, get a diagnostic dump of the debuginfo reader by adding the flags --trace-symtab=yes --trace-symtab-patt=<whatever>. These generate a huge amount of output, so I suggest you play around with them first on a simple program (eg, ls) on the host, so you can see how to use --trace-symtab-patt= to get output for just the object in question. Really also you should file a bug report, since bugs reported by email tend to fall through the cracks. J |
|
From: Alan M. <ala...@jp...> - 2013-05-30 21:54:02
|
On 5/30/2013 11:22 AM, Alan Mazer wrote: > On 5/30/13 10:16 AM, Dan Kegel wrote: >> On Thu, May 30, 2013 at 9:15 AM, Alan Mazer >> <ala...@jp...> wrote: >>> This type of error is occurring in a variety of places, always >>> "definitely lost" memory at a function call. >>> >>> Anyone have any idea what I'm missing? I've tried multiple compilers >>> and a bazillion different options (on compiler and valgrind). I'm >>> stumped. >> Have you looked at what the compiler is generating, or single-stepped >> through that call? > > I just looked at the output from -S but nothing looks odd. It very > quickly jumps into strcmp calls that are near the top of the called > routine. > > I've been running this under OS X but I just tried it on a Linux > machine and there got more information: > > ==15252== 8,233 bytes in 1 blocks are definitely lost in loss record 4 > of 4 > ==15252== at 0x4A07152: operator new[](unsigned long) > (vg_replace_malloc.c:363) > ==15252== by 0x40E1A0: read_conf(char const*, char const*, char > const*, char const*, unsigned char, SL_List<char*>*, char**) > (parsing.cpp:295) > ==15252== by 0x41799A: main (main.cpp:404) > > On Linux valgrind gives me a line number within the routine (line 295) > that has a legitimate memory leak. > > So I guess I just need to run Valgrind on my Linux machine and avoid > the Mac? It looks like the problem is that valgrind can't locate the "new" usages within the routines. Looking at this more I can see that the reported memory leaks are all valid, and the tracebacks are perfect except for the locations within the "new"-using routines. That part of the traceback is omitted in every message. Compiling with the optimizer enabled heightens the effect, so I thought I might have some optimizations accidentally enabled but it doesn't look like it. It's something weird about g++ on OS X... |
|
From: Dieter, W. R <wil...@in...> - 2013-05-30 19:52:24
|
I am trying to build valgrind to help debug a native Android
application. The host I am compiling on is a Mac running Mac OS
10.8.3. The target is an internal prototype x86 tablet running
Android 4.0.4. I am using Android NDK r8e.
I started with the release version of Valgrind 3.8.1. When I ran into
the premature exit described at the end of this note, I switched to
the svn version.
I followed the instructions in README.android, setting HWKIND to
generic, and making to following changes to get valgrind to build:
1) In the environment variable definitions for the build tools,
substituted "darwin-x86_64" for "linux-x86" in the path to each of
the tools.
2) Added:
export
RANLIB=$NDKROOT/toolchains/x86-4.4.3/prebuilt/linux-x86/bin/i686-android-li
nux-ranlib
to get the right ranlib executable
3) The target cpu/kernel detection logic assumes it is building for
the host CPU. The --target and --host options cover most of the
issues, but the configure script tries to run "uname -r" to get the
kernel version.
The logic in configure.in that matches kernel versions treats 2.6.*
and 3.0.* the same way, so if you are building on a relatively
recent Linux system it will probably work fine. Mac OS is
returning an OS version of 12.3.0, which is unrelated to the
Android kernel version.
I hardcoded configure.in to use version "3.0.8" to match my actual
device, though maybe calling 'adb shell uname -r' would make more
sense for android targets.
4) The types uint32_t and uint64_t are referenced in the system elf.h,
and not defined by default on my system, so I added "#include
<stdint.h>" prior to each "#include <elf.h>"
(coregrind/m_main.c:2987, coregrind/m_coredump/coredump-elf.c:57,
coregrind/m_debuginfo/readelf.c:57,
coregrind/m_initimg/initimg-linux.c:60, coregrind/m_ume/elf.c:53,
coregrind/launcher-linux.c:47)
When I run "/data/local/Inst/bin/valgrind ls", ls runs without any
errors, and I get the expected output:
==32681== Memcheck, a memory error detector
==32681== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==32681== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright
info
==32681== Command: ls
==32681==
[... ls output deleted ... ]
==32681==
==32681== HEAP SUMMARY:
==32681== in use at exit: 1,024 bytes in 1 blocks
==32681== total heap usage: 41 allocs, 40 frees, 5,967 bytes allocated
==32681==
==32681== LEAK SUMMARY:
==32681== definitely lost: 0 bytes in 0 blocks
==32681== indirectly lost: 0 bytes in 0 blocks
==32681== possibly lost: 0 bytes in 0 blocks
==32681== still reachable: 1,024 bytes in 1 blocks
==32681== suppressed: 0 bytes in 0 blocks
==32681== Rerun with --leak-check=full to see details of leaked memory
==32681==
==32681== For counts of detected and suppressed errors, rerun with: -v
==32681== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
I then added a wrapper, as described by jseward's blog post
(http://blog.mozilla.org/jseward/2011/09/27/valgrind-on-android-current-sta
tus/),
and included the --smc-check=all in the VGPARAMS, because it sounded
like it would be required for an x86 build. The whole
/data/local/start_valgrind_myprog file looks like this:
#!/system/bin/sh
VGPARAMS='--error-limit=no --smc-check=all'
export TMPDIR=/data/data/com.intel.central
exec /data/local/Inst/bin/valgrind $VGPARAMS $*
When I start my application with:
am start -a android.intent.action.MAIN -n
com.intel.central/.MainActivity
I see the following in logcat:
I//data/local/start_valgrind_myprog(32640): ==32641== Using
Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
I//data/local/start_valgrind_myprog(32640): ==32641== Command:
/system/bin/app_process /system/bin --application
--nice-name=com.intel.central com.andr\
oid.internal.os.WrapperInit 32 17 android.app.ActivityThread
I//data/local/start_valgrind_myprog(32640): ==32641==
I//data/local/start_valgrind_myprog(32640): valgrind:
m_debuginfo/readelf.c:577 (get_elf_symbol_info): Assertion 'in_rx' failed.
I//data/local/start_valgrind_myprog(32640): ==32641== at 0x38033455:
report_and_quit (m_libcassert.c:260)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x38033851:
vgPlain_assert_fail (m_libcassert.c:340)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x3806D80E:
read_elf_symtab__normal (readelf.c:577)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x380705F3:
vgModuleLocal_read_elf_debug_info (readelf.c:2655)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x3806A449:
vgPlain_di_notify_mmap (debuginfo.c:629)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x38097510:
vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2087)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x380C9A0B:
vgSysWrap_x86_linux_sys_mmap2_before (syswrap-x86-linux.c:1247)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x3808C830:
vgPlain_client_syscall (syswrap-main.c:1522)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x38089C12:
vgPlain_scheduler (scheduler.c:1066)
I//data/local/start_valgrind_myprog(32640): ==32641== by 0x380C1188:
run_a_thread_NORETURN (syswrap-linux.c:103)
I//data/local/start_valgrind_myprog(32640): sched status:
I//data/local/start_valgrind_myprog(32640): running_tid=1
I//data/local/start_valgrind_myprog(32640): Thread 1: status =
VgTs_Runnable
I//data/local/start_valgrind_myprog(32640): ==32641== at 0xB000F261:
__dl___mmap2 (in /system/bin/linker)
I//data/local/start_valgrind_myprog(32640): Note: see also the FAQ in the
source distribution.
I//data/local/start_valgrind_myprog(32640): It contains workarounds to
several common problems.
I//data/local/start_valgrind_myprog(32640): In particular, if Valgrind
aborted or crashed after
I//data/local/start_valgrind_myprog(32640): identifying problems in your
program, there's a good chance
I//data/local/start_valgrind_myprog(32640): that fixing those problems
will prevent Valgrind aborting or
I//data/local/start_valgrind_myprog(32640): crashing, especially if it
happened in m_mallocfree.c.
I//data/local/start_valgrind_myprog(32640): If that doesn't help, please
report this bug to: www.valgrind.org
I//data/local/start_valgrind_myprog(32640): In the bug report, send all
the above text, the valgrind
I//data/local/start_valgrind_myprog(32640): version, and what OS and
version you are using. Thanks.
The wrapper script appears to be launching the application, but it
looks like valgrind is exiting immediately with an assertion failure.
Any ideas what could be going wrong or how to fix it?
Thanks,
Bill.
|
|
From: Alan M. <al...@ju...> - 2013-05-30 18:51:20
|
On 5/30/13 9:43 AM, David Chapman wrote:
> On 5/30/2013 9:15 AM, Alan Mazer wrote:
>> I've been using valgrind for many years and am finally stumped. After
>> not having used it recently, I'm now getting "definitely lost" memory
>> and the location of the "operator new" usage is a function call.
>>
>> For example...
>>
>> ==35995== 2,089 bytes in 1 blocks are definitely lost in loss record 9
>> of 10
>> ==35995== at 0x10008FC16: malloc (vg_replace_malloc.c:274)
>> ==35995== by 0x1000A126C: operator new(unsigned long) (in
>> /usr/local/lib/libstdc++.6.dylib)
>> ==35995== by 0x10001984C: main (main.cpp:405)
>>
>> where main.cpp:405 is...
>>
>> read_conf(conffile, ".conf;.test;.prot", preface,
>> trigger_statement,
>> skip_preprocessor, m4dirs, &text);
>>
>> Everything being passed is a pointer.
>>
>> If I don't call the routine, the error does go away.
>>
>> This type of error is occurring in a variety of places, always
>> "definitely lost" memory at a function call.
>>
>> Anyone have any idea what I'm missing? I've tried multiple compilers
>> and a bazillion different options (on compiler and valgrind). I'm
>> stumped.
>>
>> -- Alan
>>
>
> What is the signature of the function being called? You say that
> pointers are being passed in, but what does the function expect? For
> example, is the compiler automatically creating an object for the
> string constant using a default constructor? (I realize the loss
> record is longer than the string constant, but I don't know what the
> function expects.)
Sure. Good point.
extern int read_conf(const char *filename, const char *extensions,
const char *preface, const char *postscript, u_char skip_preprocessor,
SL_List<char *> *m4dirs, char **conf_text_p);
>
> Also, is the function in a .so file that has been stripped so that
> Valgrind cannot follow it, stack trace?
No, there are no .so files here. Just a bunch of object files linked
together, all compiled with -g and -Wall, linked with -lm. I've tried
with g++ 4.5.1 and 4.7.0. They both give the same result.
>
> And of course, what version of Valgrind are you using?
3.8.1.
-- Alan
|
|
From: Alan M. <al...@ju...> - 2013-05-30 18:23:28
|
On 5/30/13 10:16 AM, Dan Kegel wrote: > On Thu, May 30, 2013 at 9:15 AM, Alan Mazer <ala...@jp...> wrote: >> This type of error is occurring in a variety of places, always >> "definitely lost" memory at a function call. >> >> Anyone have any idea what I'm missing? I've tried multiple compilers >> and a bazillion different options (on compiler and valgrind). I'm stumped. > Have you looked at what the compiler is generating, or single-stepped > through that call? I just looked at the output from -S but nothing looks odd. It very quickly jumps into strcmp calls that are near the top of the called routine. I've been running this under OS X but I just tried it on a Linux machine and there got more information: ==15252== 8,233 bytes in 1 blocks are definitely lost in loss record 4 of 4 ==15252== at 0x4A07152: operator new[](unsigned long) (vg_replace_malloc.c:363) ==15252== by 0x40E1A0: read_conf(char const*, char const*, char const*, char const*, unsigned char, SL_List<char*>*, char**) (parsing.cpp:295) ==15252== by 0x41799A: main (main.cpp:404) On Linux valgrind gives me a line number within the routine (line 295) that has a legitimate memory leak. So I guess I just need to run Valgrind on my Linux machine and avoid the Mac? -- Alan |
|
From: David C. <dcc...@ac...> - 2013-05-30 17:36:51
|
On 5/30/2013 9:15 AM, Alan Mazer wrote:
> I've been using valgrind for many years and am finally stumped. After
> not having used it recently, I'm now getting "definitely lost" memory
> and the location of the "operator new" usage is a function call.
>
> For example...
>
> ==35995== 2,089 bytes in 1 blocks are definitely lost in loss record 9
> of 10
> ==35995== at 0x10008FC16: malloc (vg_replace_malloc.c:274)
> ==35995== by 0x1000A126C: operator new(unsigned long) (in
> /usr/local/lib/libstdc++.6.dylib)
> ==35995== by 0x10001984C: main (main.cpp:405)
>
> where main.cpp:405 is...
>
> read_conf(conffile, ".conf;.test;.prot", preface, trigger_statement,
> skip_preprocessor, m4dirs, &text);
>
> Everything being passed is a pointer.
>
> If I don't call the routine, the error does go away.
>
> This type of error is occurring in a variety of places, always
> "definitely lost" memory at a function call.
>
> Anyone have any idea what I'm missing? I've tried multiple compilers
> and a bazillion different options (on compiler and valgrind). I'm stumped.
>
> -- Alan
>
What is the signature of the function being called? You say that
pointers are being passed in, but what does the function expect? For
example, is the compiler automatically creating an object for the string
constant using a default constructor? (I realize the loss record is
longer than the string constant, but I don't know what the function
expects.)
Also, is the function in a .so file that has been stripped so that
Valgrind cannot follow its stack trace?
And of course, what version of Valgrind are you using?
--
David Chapman dcc...@ac...
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
|
|
From: Dan K. <da...@ke...> - 2013-05-30 17:17:06
|
On Thu, May 30, 2013 at 9:15 AM, Alan Mazer <ala...@jp...> wrote: > This type of error is occurring in a variety of places, always > "definitely lost" memory at a function call. > > Anyone have any idea what I'm missing? I've tried multiple compilers > and a bazillion different options (on compiler and valgrind). I'm stumped. Have you looked at what the compiler is generating, or single-stepped through that call? |
|
From: Alan M. <ala...@jp...> - 2013-05-30 16:15:40
|
I've been using valgrind for many years and am finally stumped. After
not having used it recently, I'm now getting "definitely lost" memory
and the location of the "operator new" usage is a function call.
For example...
==35995== 2,089 bytes in 1 blocks are definitely lost in loss record 9
of 10
==35995== at 0x10008FC16: malloc (vg_replace_malloc.c:274)
==35995== by 0x1000A126C: operator new(unsigned long) (in
/usr/local/lib/libstdc++.6.dylib)
==35995== by 0x10001984C: main (main.cpp:405)
where main.cpp:405 is...
read_conf(conffile, ".conf;.test;.prot", preface, trigger_statement,
skip_preprocessor, m4dirs, &text);
Everything being passed is a pointer.
If I don't call the routine, the error does go away.
This type of error is occurring in a variety of places, always
"definitely lost" memory at a function call.
Anyone have any idea what I'm missing? I've tried multiple compilers
and a bazillion different options (on compiler and valgrind). I'm stumped.
-- Alan
|