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
(7) |
2
(23) |
3
(1) |
4
|
|
5
(1) |
6
(2) |
7
(3) |
8
(7) |
9
(11) |
10
(10) |
11
(3) |
|
12
(1) |
13
(10) |
14
(8) |
15
(6) |
16
(4) |
17
(7) |
18
(2) |
|
19
(1) |
20
(2) |
21
(1) |
22
(2) |
23
(2) |
24
(7) |
25
(1) |
|
26
(2) |
27
(1) |
28
(5) |
29
(2) |
30
(20) |
|
|
|
From: Scott L. <sc...@sw...> - 2005-06-09 15:38:03
|
John Reiser wrote: > Other people do think it is practical. They pay money to use it. > Purify works this way. The no-recompile mode of Insure++ works this way. > Customers tolerate the small fraction of false positive complaints, > partly because of the bulls-eye identification of the instruction > which first loaded the uninit bits. So is there any comment on my idea, here? Let each register track the last memory location it was loaded from, and report that location if the uninitialized register is used. If there is something fundamental that makes that idea unfeasible I'd be very interested to hear what it is. As far as I can tell, it's a good solution which would avoid false positives and would probably be trivial to implement. -- Scott Long <sc...@sw...> Software Engineer SwiftView, Inc. (971) 223-2639 |
|
From: John R.
|
Paul Pluzhnikov wrote: >>Running the no-recompile >>mode of Insure++ on "/bin/bash -c true" reports 1 READ_UNINIT_MEM error > > > But I think that's simply because Chaperon applies significant effort > to "cull out" the other RUMs (via various heuristics). If Chaperon > didn't have its own mempcy(), memset(), etc. there probably would be > many more RUMs reported. The practical effect of Chaperon reducing the "clutter" caused by speculation in known routines of glibc (and generally in stereotypical code for bitfields) is much the same as the practical effect of memcheck's default suppressions for glibc, libX11, etc. Typical usage is willing to overlook these cases, and both checkers oblige by default. -- |
|
From: Paul P. <ppl...@gm...> - 2005-06-09 14:49:01
|
n 6/9/05, John Reiser <jr...@bi...> wrote: > Other people do think it is practical. They pay money to use it. > Purify works this way. The no-recompile mode of Insure++ works this way. Not really: most customers I deal with suppress READ_UNINIT_MEMs=20 right away :-( They do have an option of turning it back on, though. > Running the no-recompile > mode of Insure++ on "/bin/bash -c true" reports 1 READ_UNINIT_MEM error But I think that's simply because Chaperon applies significant effort=20 to "cull out" the other RUMs (via various heuristics). If Chaperon didn't have its own mempcy(), memset(), etc. there probably would be=20 many more RUMs reported. Cheers, |
|
From: Ludovic D. <ld...@li...> - 2005-06-09 14:37:58
|
Hi ! I'm currently trying to debug atftp, a multicast, multithreaded tftp server. http://packages.debian.org/testing/net/atftp I sometimes get a segfault in tftpd.c:736 in the 'free(data)'. So I ran it under Valgrind (Debian v2.4.0-2) and here's what I get: data: 1badda48 <--- debug info: a printf("%x", data); before the free(data) ==6998== Invalid write of size 4 ==6998== at 0x1B936C55: pthread_create@@GLIBC_2.1 (in /lib/libpthread-0.10.so ==6998== by 0x804A2C9: main (tftpd.c:469) ==6998== Address 0x1BADDA48 is 0 bytes inside a block of size 112 free'd ==6998== at 0x1B904B04: free (vg_replace_malloc.c:152) ==6998== by 0x804A682: tftpd_receive_request (tftpd.c:736) ==6998== by 0x1B934E50: pthread_start_thread (in /lib/libpthread-0.10.so) ==6998== by 0x1BA69929: clone (in /lib/libc-2.3.2.so) So it seems to say that pthread_create tried to use a freed block and that this block has been freed at tftpd.c:736 ? If that's what valgrind wants to say, then I do not understand anything ! Indeed for each incoming tftp request: 1- the thread specific 'data' block is calloced at tftpd.c:410 2- then passed to pthread_create() at tftpd.c:469 3- and finally freed by the thread at tftpd.c:736, before a pthread_exit(). Only one thing is sure: if I remove the free(data), no more segfaults... Maybe the stack is corrupt so that valgrind displays strange info ? -- Ludovic DROLEZ |
|
From: John R.
|
Nicholas Nethercote wrote:
> On Wed, 8 Jun 2005, John Reiser wrote:
>
>> Memcheck ought to have an _option_ to check and report as soon as
>> possible:
>> immediately upon each memory fetch. This would require patience in
>> dealing
>> with "false positive" complaints (such as copy of structures with holes,
>> speculative loads that are later ignored, etc.) but probably it would
>> help you in this and similar cases. Other memory checkers work this way.
>
>
> I've said before that I tried this once, and got hundreds of error
> reports even for tiny programs like 'true'. So I don't think it's
> practical.
Other people do think it is practical. They pay money to use it.
Purify works this way. The no-recompile mode of Insure++ works this way.
Customers tolerate the small fraction of false positive complaints,
partly because of the bulls-eye identification of the instruction
which first loaded the uninit bits. Some software quality policies
strongly encourage "never access uninit bits (for any reason.)"
Applying this policy to the most troublesome case (bit fields) can
_increase_ efficiency, particularly because gcc still generates
less-than-optimal code for sequences of assignments to adjacent
bit fields.
In most cases, 'true' is a shell builtin. Running the no-recompile
mode of Insure++ on "/bin/bash -c true" reports 1 READ_UNINIT_MEM error
from __gconv_transform_utf8_internal(), and two leaks from _dl_allocate_tls_storage().
The READ_UNINIT is genuine (bash 2.05b.0(1), /lib/tls/libc-2.3.2.so).
Compiling the C code
main() { exit(0); }
and running under the no-recompile mode of Insure++ gives no READ_UNINIT_MEM
errors, and the same two leaks. Please give a reproducible example of
your claim of "hundreds of errors."
--
|
|
From: Nicholas N. <nj...@cs...> - 2005-06-09 08:26:31
|
On Wed, 8 Jun 2005, John Reiser wrote: > Memcheck ought to have an _option_ to check and report as soon as possible: > immediately upon each memory fetch. This would require patience in dealing > with "false positive" complaints (such as copy of structures with holes, > speculative loads that are later ignored, etc.) but probably it would > help you in this and similar cases. Other memory checkers work this way. I've said before that I tried this once, and got hundreds of error reports even for tiny programs like 'true'. So I don't think it's practical. N |
|
From: Scott L. <sc...@sw...> - 2005-06-08 18:18:48
|
John Reiser wrote: > Memcheck waits until as late as possible (just before the program relies > on the uninit value) before complaining. In addition to some theoretic > beauty, this prevents "false positive" complaints. But as you experience, > it is not always the most helpful for finding and fixing problems. I'll throw an idea out there... Each register could carry with it the last memory address it was loaded from. This address is either "NONE" (if the register has been set via an immediate MOV, or other similar operation), or an actual address. Register copies would copy this address to the new register, as well. Then, if the uninitialized register is used, the last known address could be reported. Obviously, this can't work in all cases. Here's one case it wouldn't work (using bastardized AT&T syntax): mov [uninitialized_val], eax add [uninitialized_val], eax In that case, eax consists of a "mixture" of two uninitialized values. Only one of these could be reported (probably the second one). However, not all is lost. The developer would fix the reported case, re-run, and then the other uninitialized value would be reported. Does this idea have any merit? -- Scott Long <sc...@sw...> Software Engineer SwiftView, Inc. (971) 223-2639 |
|
From: John R.
|
> ... the necessary information is not being reported, although I know that > Valgrind has access to it. No, not directly, not with the current strategy and implementation. > ... What I really want to see is this: > > ==10199== Conditional jump or move depends on uninitialised value(s) > ==10199== at 0x816EAA4: foobar (abc.c:1202) > ==10199== by 0x816EBEB: zigzag (def.c:1256) > ==10199== by 0x816E726: bazquuz (xyz.c:1049) > ==10199== Address 0x1BB16B5C is 4 bytes within a block of size 512 > ==10199== alloc'd at 0x1BB16B58: malloc (vg_replace-malloc.c:131) > ==10199== by 0x819CA55: badfunction (memory1.c:154) > > That would allow me to instantly pinpoint the problem. It could also > make similar reports for variables (both auto and static). Memcheck waits until as late as possible (just before the program relies on the uninit value) before complaining. In addition to some theoretic beauty, this prevents "false positive" complaints. But as you experience, it is not always the most helpful for finding and fixing problems. Memcheck ought to have an _option_ to check and report as soon as possible: immediately upon each memory fetch. This would require patience in dealing with "false positive" complaints (such as copy of structures with holes, speculative loads that are later ignored, etc.) but probably it would help you in this and similar cases. Other memory checkers work this way. -- |
|
From: Nicholas N. <nj...@cs...> - 2005-06-08 17:17:40
|
On Tue, 7 Jun 2005, Julian Seward wrote: >> Is there some reason why Valgrind doesn't tell me this information? >> Surely it has access to it. The current behavior isn't helpful. > > No, it doesn't have that info readily to hand. See sec 3.5 > in http://www.valgrind.org/docs/manual/mc_main.html to understand > what Memcheck is really doing. In short, the undefined value is in a register, so you can't necessarily say anything about an uninitialised memory location. Nick |
|
From: Cerion Armour-B. <ce...@op...> - 2005-06-08 09:06:21
|
On Wednesday 08 June 2005 08:35, Igmar Palsenberg wrote: > Hi, > > Something hosed BDB : > > igmar@ouzo:~/trees/valgrind_3/valgrind$ svn update > svn: Berkeley DB error while opening environment for filesystem > /home/svn/repos/valgrind/db: > DB_RUNRECOVERY: Fatal error, run database recovery > svn: bdb: PANIC: fatal region error detected; run recovery groan. fixed. > While you're doing a recovery anyway : You might want to convert to > fsfs, it has less change getting corrupted. I'll take a look, cheers. Cerion |
|
From: Igmar P. <mai...@jd...> - 2005-06-08 07:16:22
|
> where can get the sources of valgrind for compilation on HP UNIX Valgrind is Linux only with the exception of a FreeBSD (?) port being present. Igmar |
|
From: Igmar P. <mai...@jd...> - 2005-06-08 06:35:12
|
Hi, Something hosed BDB : igmar@ouzo:~/trees/valgrind_3/valgrind$ svn update svn: Berkeley DB error while opening environment for filesystem /home/svn/repos/valgrind/db: DB_RUNRECOVERY: Fatal error, run database recovery svn: bdb: PANIC: fatal region error detected; run recovery While you're doing a recovery anyway : You might want to convert to fsfs, it has less change getting corrupted. Regards, Igmar |
|
From: <mil...@tc...> - 2005-06-08 04:54:05
|
hi where can get the sources of valgrind for compilation on HP UNIX rgds Milan Garg IT Analyst Tata Consultancy Services Limited Mailto: mil...@tc... Website: http://www.tcs.com Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you |
|
From: Julian S. <js...@ac...> - 2005-06-07 17:32:45
|
> Is there some reason why Valgrind doesn't tell me this information? > Surely it has access to it. The current behavior isn't helpful. No, it doesn't have that info readily to hand. See sec 3.5 in http://www.valgrind.org/docs/manual/mc_main.html to understand what Memcheck is really doing. That said, you can find out what you want using the VALGRIND_CHECK_DEFINED client request. See sec 3.7 of the same page for details. J |
|
From: Scott L. <sc...@sw...> - 2005-06-07 17:18:16
|
Hello all... I've been using Valgrind for what seems like several years now, and it's extremely helpful. I've recently run into a situation where the necessary information is not being reported, although I know that Valgrind has access to it. In a report of this form: ==10199== Conditional jump or move depends on uninitialised value(s) ==10199== at 0x816EAA4: foobar (abc.c:1202) ==10199== by 0x816EBEB: zigzag (def.c:1256) ==10199== by 0x816E726: bazquuz (xyz.c:1049) Why doesn't Valgrind tell me WHAT is uninitialized? I.e., what I really want to see is this: ==10199== Conditional jump or move depends on uninitialised value(s) ==10199== at 0x816EAA4: foobar (abc.c:1202) ==10199== by 0x816EBEB: zigzag (def.c:1256) ==10199== by 0x816E726: bazquuz (xyz.c:1049) ==10199== Address 0x1BB16B5C is 4 bytes within a block of size 512 ==10199== alloc'd at 0x1BB16B58: malloc (vg_replace-malloc.c:131) ==10199== by 0x819CA55: badfunction (memory1.c:154) That would allow me to instantly pinpoint the problem. It could also make similar reports for variables (both auto and static). Is there some reason why Valgrind doesn't tell me this information? Surely it has access to it. The current behavior isn't helpful. Thanks, Scott -- Scott Long <sc...@sw...> Software Engineer SwiftView, Inc. (971) 223-2639 |
|
From: <mar...@gr...> - 2005-06-07 12:52:11
|
(This may be a problem with curses rather than valgrind, but I thought the
valgrind-users list would be a hopeful place to report it.)
I find that vagrind (I am using 2.2.0 on Linux) reports space loss through use
of the curses library.
For example, the program,
---------------------------------------------
#include <stdio.h>
#include <term.h>
#include <ncurses.h>
int main() {
int r = 0;
int c = 0;
char * s;
setupterm(0, fileno(stdout), (int *)0);
r = tigetnum("lines");
c = tigetnum("cols");
s = tigetstr("cup");
putp(tparm(s, r - 1, 0));
printf("(terminal is %d by %d)\n", r, c);
return 0;
}
---------------------------------------------
compiled with,
gcc -o test -lncurses test.c
and run with 'valgrind ./test' produces,
---------------------------------------------
==4009== Memcheck, a memory error detector for x86-linux.
==4009== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==4009== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==4009== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==4009== For more details, rerun with: -v
==4009==
(terminal is 52 by 99)
==4009==
==4009== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1)
==4009== malloc/free: in use at exit: 3267 bytes in 10 blocks.
==4009== malloc/free: 12 allocs, 2 frees, 3303 bytes allocated.
==4009== For a detailed leak analysis, rerun with: --leak-check=yes
==4009== For counts of detected errors, rerun with: -v
---------------------------------------------
'uname -a' for my machine gives
Linux .. 2.6.8-1-686 #1 Thu Nov 25 04:34:30 UTC 2004 i686 GNU/Linux
1) Is there some way of releasing the space which curses is mallocing
here? I am not aware of any myself, and the little example program
above is more-or-less copied from a textbook.
2) Do I need to worry about the loss of space? Obviously it is a debugging
pain, since I have had to remove curses dependency in the software before I can
confidently debug it through valgrind. But it would be nice to know it was no
more than that.
Martin Porter
|
|
From: Jeremy F. <je...@go...> - 2005-06-06 22:00:43
|
Kjartan Maraas wrote:
>Where the environment is clearly free'd using the function that the
>first one suggests to use. Could this be a false positive from valgrind
>or am I missing some subtlety in the gnome functions?
>
You might want to try --leak-resolution=high. It could be that
Valgrind is commoning up two distinct cases and only presenting one
message for it (ie, the problem is in some other caller).
It would be a definite bug if Valgrind reports a block as leaked if it
had been freed; it's possible it might report a block as leaked if it
hasn't been freed but V didn't find any references (but this fairly rare).
J
|
|
From: Kjartan M. <km...@br...> - 2005-06-06 21:07:29
|
Hi.
First of all, I'm using valgrind 2.4.0 from Fedora Core 4 test (rawhide)
and this run was done using --tool=memcheck
I discussed some leaks reported by valgrind with one of the gnome-panel
maintainers today and we found that we couldn't really explain why
valgrind is reporting this as a leak. There are two similar cases in
different parts of the gnome stack:
==2047== 1619 (276 direct, 1343 indirect) bytes in 4 blocks are definitely lost in loss record 136 of 218
==2047== at 0x1B909222: malloc (vg_replace_malloc.c:130)
==2047== by 0x1C2445C1: g_malloc (gmem.c:137)
==2047== by 0x1B96097D: make_environment_for_screen (gnome-multiscreen.c:65)
==2047== by 0x1B960A88: gnome_url_show_on_screen (gnome-multiscreen.c:108)
==2047== by 0x8083714: activate_uri (panel-menu-items.c:100)
which translates to this piece of code:
* Returns: a newly-allocated %NULL-terminated array of strings or
* %NULL on error. Use g_strfreev() to free it.
**/
static char **
make_environment_for_screen (GdkScreen *screen)
{
char **retval = NULL;
char *display_name;
int i, env_len;
int display_index = -1;
g_return_val_if_fail (GDK_IS_SCREEN (screen), NULL);
for (env_len = 0; environ [env_len]; env_len++)
if (!strncmp (environ [env_len], "DISPLAY", 7))
display_index = env_len;
if (display_index == -1)
display_index = env_len++;
retval = g_new (char *, env_len + 1);
retval [env_len] = NULL;
display_name = gdk_screen_make_display_name (screen);
for (i = 0; i < env_len; i++)
if (i == display_index)
retval [i] = g_strconcat ("DISPLAY=", display_name, NULL);
else
retval [i] = g_strdup (environ [i]);
g_assert (i == env_len);
g_free (display_name);
return retval;
}
This is called in this function:
gboolean
gnome_url_show_on_screen (const char *url,
GdkScreen *screen,
GError **error)
{
char **env;
gboolean retval;
env = make_environment_for_screen (screen);
retval = gnome_url_show_with_env (url, env, error);
g_strfreev (env);
return retval;
}
Where the environment is clearly free'd using the function that the
first one suggests to use. Could this be a false positive from valgrind
or am I missing some subtlety in the gnome functions?
Cheers
Kjartan
|
|
From: Jesper O. <jes...@gm...> - 2005-06-05 06:00:15
|
Hi,
I just installed valgrind 2.4.0 under linux and am trying to use it on the=
=20
example from the=20
quick start guide:
#include <stdlib.h>
void f(void) {
int* x =3D malloc(10 * sizeof(int));
x[10] =3D 0; // problem 1: heap block overrun
} // problem 2: memory leak -- x not freed
int main(void) {
f();
return 0;
}
I use gcc 3.2.2 to compile:
% gcc -g test.c
When I invoke valgrind, the output (a lot of it) seems to be correct,
but the line numbers are missing. How come?
% valgrind a.out
<quote>
=3D=3D7772=3D=3D Invalid write of size 4
=3D=3D7772=3D=3D at 0x8048489: ???
=3D=3D7772=3D=3D by 0x80484AA: ???
=3D=3D7772=3D=3D by 0x1B91F62C: __libc_start_main (in
/lib/libc-2.3.2.so<http://2.3.2.so>
)
=3D=3D7772=3D=3D by 0x8048398: ???
=3D=3D7772=3D=3D Address 0x1BA384F0 is 0 bytes after a block of size 40 all=
oc'd
=3D=3D7772=3D=3D at 0x1B900534: malloc (vg_replace_malloc.c:130)
=3D=3D7772=3D=3D by 0x804847C: ???
=3D=3D7772=3D=3D by 0x80484AA: ???
=3D=3D7772=3D=3D by 0x1B91F62C: __libc_start_main (in
/lib/libc-2.3.2.so<http://2.3.2.so>
)
=3D=3D7772=3D=3D by 0x8048398: ???
</quote>
Cheers
Jesper
|
|
From: Gage W. <Wol...@ka...> - 2005-06-03 07:12:35
|
Hello, more than bow again.So ye've come, the Deputy-Governor hailed him, and = followed theI am happy to assure you, said Captain Blood, that the = reminderOh, aye - in England. But this ain't England, damme.them it = might speedily become so. A man was slung overboard to makeone of = your slaves was being murthered by the sun and the flies.confinement = under hatches, ill-nourishment and foul water, amastered him. = 'Swounds! You impudent dog! D'you trifle with me?They want to view = the treasure itself. They know - you compel mecity by surprise, not = only before it can put itself into a state ofscuttles in her deck, = whilst into her hull they packed all the tarA moment they stood = looking into each other's eyes.to himself, the Baron dictated his = terms. He demanded that allthe great blocks of ripening amber cane. = In the distance down oneHow the devil do I know? I was hoping you'd = have some ideasBut I see the Arabella. |
|
From: Eric H. <of...@bl...> - 2005-06-02 22:33:11
|
OK, what you want to do is: read the valgrind documentation and look
at the macros VALGRIND_CREATE_MEMPOOL, VALGRIND_MEMPOOL_ALLOC, and
VALGRIND_MEMPOOL_FREE. In my case, at least, those were all I needed
to tell valgrind "Hey, I'm managing my own memory here; please treat
the region that I just mapped as if it were part of the heap".
--
___
oo // \ "De Chelonian Mobile"
(_,/ _/ TortoiseSVN
_/__/> The coolest Interface to (Sub)Version Control
/_/ _ http://tortoisesvn.tigris.org
|
|
From: Robert W. <rj...@du...> - 2005-06-02 21:00:58
|
> So swapcontext cannot be used reliably with valgrind without > patching valgrind and modifying the code that uses swapcontext? > Is this correct? Yes, but I'll be pushing these changes back to both the 2.4 and 3.0 line this weekend, after I write some documentation, so it'll all be "official." Regards, Robert. |
|
From: Joshua Moore-O. <jo...@ch...> - 2005-06-02 20:45:49
|
> mprotect shouldn't affect addressability. > > Joshua: The only thing I can think of is whether you are using any of > the VALGRIND_* macros in your program? How are you invoking Valgrind? I wasn't using any VALGRIND_* macros in my program. Your later message talked about swapcontext... So swapcontext cannot be used reliably with valgrind without patching valgrind and modifying the code that uses swapcontext? Is this correct? Josh. |
|
From: Jeremy F. <je...@go...> - 2005-06-02 20:27:05
|
Robert Walsh wrote:
>If I were to guess, I'd suspect the swapcontext. I bet what's happening
>is that you've got multiple stacks allocated relatively close to each
>other (within 2MB of each other) and when you do a swapcontext to swap
>them around, Valgrind can't tell that the new one is a completely
>different stack, so it marks the space between the new %esp and the old
>%esp as invalid. Things go downhill from there.
>
>
Oh, yeah, I knew the swapcontext should have rung a bell. This seems
like the right explanation.
J
|
|
From: Jeremy F. <je...@go...> - 2005-06-02 20:27:04
|
Nicholas Nethercote wrote:
> Is there any way Memcheck could be lead to think the memory in the
> middle of the block is not accessible? Eg. mprotect() was called on it?
>
> It may also be a Memcheck bug. If you could make a reproducible test
> case that would be great.
mprotect shouldn't affect addressability.
Joshua: The only thing I can think of is whether you are using any of
the VALGRIND_* macros in your program? How are you invoking Valgrind?
J
|