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
(6) |
2
(16) |
3
(3) |
4
(11) |
5
(2) |
|
6
(4) |
7
(11) |
8
(4) |
9
(6) |
10
(25) |
11
(10) |
12
(1) |
|
13
(2) |
14
(6) |
15
(16) |
16
(19) |
17
(16) |
18
(5) |
19
|
|
20
(4) |
21
(5) |
22
(21) |
23
(4) |
24
(14) |
25
(3) |
26
(9) |
|
27
(3) |
28
(13) |
29
(6) |
30
(16) |
|
|
|
|
From: Julian S. <js...@ac...> - 2003-04-07 23:27:37
|
... from the usual place, http://developer.kde.org/~sewardj The release notes follow. J Version 1.9.5 (7 April 2003) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It occurs to me that it would be helpful for valgrind users to record in the source distribution the changes in each release. So I now attempt to mend my errant ways :-) Changes in this and future releases will be documented in the NEWS file in the source distribution. Major changes in 1.9.5: - (Critical bug fix): Fix a bug in the FPU simulation. This was causing some floating point conditional tests not to work right. Several people reported this. If you had floating point code which didn't work right on 1.9.1 to 1.9.4, it's worth trying 1.9.5. - Partial support for Red Hat 9. RH9 uses the new Native Posix Threads Library (NPTL), instead of the older LinuxThreads. This potentially causes problems with V which will take some time to correct. In the meantime we have partially worked around this, and so 1.9.5 works on RH9. Threaded programs still work, but they may deadlock, because some system calls (accept, read, write, etc) which should be nonblocking, in fact do block. This is a known bug which we are looking into. If you can, your best bet (unfortunately) is to avoid using 1.9.5 on a Red Hat 9 system, or on any NPTL-based distribution. If your glibc is 2.3.1 or earlier, you're almost certainly OK. Minor changes in 1.9.5: - Added some #errors to valgrind.h to ensure people don't include it accidentally in their sources. This is a change from 1.0.X which was never properly documented. The right thing to include is now memcheck.h. Some people reported problems and strange behaviour when (incorrectly) including valgrind.h in code with 1.9.1 -- 1.9.4. This is no longer possible. - Add some __extension__ bits and pieces so that gcc configured for valgrind-checking compiles even with -Werror. If you don't understand this, ignore it. Of interest to gcc developers only. - Removed a pointless check which caused problems interworking with Clearcase. V would complain about shared objects whose names did not end ".so", and refuse to run. This is now fixed. In fact it was fixed in 1.9.4 but not documented. - Fixed a bug causing an assertion failure of "waiters == 1" somewhere in vg_scheduler.c, when running large threaded apps, notably MySQL. - Add support for the munlock system call (124). Some comments about future releases: 1.9.5 is, we hope, the most stable Valgrind so far. It pretty much supersedes the 1.0.X branch. If you are a valgrind packager, please consider making 1.9.5 available to your users. You can regard the 1.0.X branch as obsolete: 1.9.5 is stable and vastly superior. There are no plans at all for further releases of the 1.0.X branch. If you want a leading-edge valgrind, consider building the cvs head (from SourceForge), or getting a snapshot of it. Current cool stuff going in includes MMX support (done); SSE/SSE2 support (in progress), a significant (10-20%) performance improvement (done), and the usual large collection of minor changes. Hopefully we will be able to improve our NPTL support, but no promises. |
|
From: Nicholas N. <nj...@ca...> - 2003-04-07 15:36:47
|
On Mon, 7 Apr 2003, Josef Weidendorfer wrote: > > Another approach: I've been thinking about, and half-implemented, this > > solution: when a program munmap()s an executable segment, Valgrind doesn't > > really munmap it, but just leaves it in that address space. Then the > > symbols don't get unloaded. The only downside is that it wastes address > > space, but hopefully code sizes aren't so big that this is a problem. > > I really see a problem if an application loads the same plugin multiple times > in a row, and you get thus one plugin mapped multiple times simultaniously. > E.g. in KDevelop (a C++ IDE), every feature for project development is in a > plugin. Now every time you open another project, the plugins of the old > project are unmapped and the plugins of the new one are mapped (around 20). Urgh. > > One problem is that debug info is currently read in lazily, which clashes > > with this, for tedious reasons. Getting back to this is somewhere in the > > Why? If the same plugin is loaded at mostly once, I don't see a problem. It's a problem for Memcheck: if you have a leak in foo.so, often foo.so is dlclose()d before the program ends, currently the leak checker gives hopeless error messages about foo.so because the debug info has been unloaded. Now imagine I've implemented the don't-unload-the-symbols scheme, but there are no other errors in the program using foo.so. So the first time the debug info for foo.so is needed is during the leak check. But by this time, foo.so has already been loaded and unloaded, its debug info was never read (because it wasn't needed) and the error message is still uninformative. If debug info was needed even once before foo.so was dlclose()d there would be no problem, but we can't rely on that. N |
|
From: Josef W. <Jos...@in...> - 2003-04-07 15:21:20
|
On Monday 07 April 2003 16:55, Nicholas Nethercote wrote: > On Mon, 7 Apr 2003, Josef Weidendorfer wrote: > > > Hmm, in theory there should be no problems, Valgrind (and hence > > > Cachegrind) can handle dlopen'd plugins ok... > > > > But they are unmapped before program termination. You only get one cost > > line "discarded" for all plugins. The solution would be to allow dumping > > while the plugin is mapped. Or you dump the information of BBCCs when the > > according object is unmapped. > > > > Or you don't delete BBCCs and accumate cost to "discarded", but keep > > them. Now you have the problem that a BB start address isn't unique to > > get to the right BBCC, but you have to store the SegInfo* in the BBCCs to > > distinguish among BBs from different plugins at the same address. > > > > BTW, my Calltree skin should be buggy in this regard, as it doesn't > > delete any BBCCs on unmapping, but still only uses the BB address. But > > checking the SegInfo* should be easy enough for a fix. > > Perhaps it's even better to take BBCCs of unmapped objects from the hash > > into a list, and put them in again if the object is mapped again after > > adjusting the addresses if needed. The same object could be mapped on a > > different base address. > > Another approach: I've been thinking about, and half-implemented, this > solution: when a program munmap()s an executable segment, Valgrind doesn't > really munmap it, but just leaves it in that address space. Then the > symbols don't get unloaded. The only downside is that it wastes address > space, but hopefully code sizes aren't so big that this is a problem. I really see a problem if an application loads the same plugin multiple times in a row, and you get thus one plugin mapped multiple times simultaniously. E.g. in KDevelop (a C++ IDE), every feature for project development is in a plugin. Now every time you open another project, the plugins of the old project are unmapped and the plugins of the new one are mapped (around 20). It's easy to keep a list of objects the application has unmapped, and in a mmap, eventually return the already mapped object if a plugin is loaded a second time. > One problem is that debug info is currently read in lazily, which clashes > with this, for tedious reasons. Getting back to this is somewhere in the Why? If the same plugin is loaded at mostly once, I don't see a problem. Josef > lower half of my ever-growing todo list... > > N > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- -- Dipl.-Inform. Josef Weidendorfer LRR-TUM - Raum 01.06.056 - Tel. +49 / (0)89 / 289 - 18454 |
|
From: Nicholas N. <nj...@ca...> - 2003-04-07 14:55:32
|
On Mon, 7 Apr 2003, Josef Weidendorfer wrote: > > Hmm, in theory there should be no problems, Valgrind (and hence > > Cachegrind) can handle dlopen'd plugins ok... > > But they are unmapped before program termination. You only get one cost line > "discarded" for all plugins. The solution would be to allow dumping while the > plugin is mapped. Or you dump the information of BBCCs when the according > object is unmapped. > > Or you don't delete BBCCs and accumate cost to "discarded", but keep them. > Now you have the problem that a BB start address isn't unique to get to the > right BBCC, but you have to store the SegInfo* in the BBCCs to distinguish > among BBs from different plugins at the same address. > > BTW, my Calltree skin should be buggy in this regard, as it doesn't delete any > BBCCs on unmapping, but still only uses the BB address. But checking the > SegInfo* should be easy enough for a fix. > Perhaps it's even better to take BBCCs of unmapped objects from the hash into > a list, and put them in again if the object is mapped again after adjusting > the addresses if needed. The same object could be mapped on a different base > address. Another approach: I've been thinking about, and half-implemented, this solution: when a program munmap()s an executable segment, Valgrind doesn't really munmap it, but just leaves it in that address space. Then the symbols don't get unloaded. The only downside is that it wastes address space, but hopefully code sizes aren't so big that this is a problem. One problem is that debug info is currently read in lazily, which clashes with this, for tedious reasons. Getting back to this is somewhere in the lower half of my ever-growing todo list... N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-07 14:50:53
|
Hi,
I just committed a change to the CVS head that speeds up the Memcheck and
Addrcheck skins a lot: by up to 28% and 36% respectively. Here are some
figures for the SPEC2000 benchmark suite, using the "test" inputs:
========
memcheck
========
164.gzip: vg1: 46.00s, vg2: 37.12s, speed-up: 19.3%
300.twolf: vg1: 7.34s, vg2: 6.63s, speed-up: 9.7%
197.parser: vg1: 70.60s, vg2: 57.24s, speed-up: 18.9%
186.crafty: vg1: 166.83s, vg2: 156.80s, speed-up: 6.0%
255.vortex: vg1: 392.94s, vg2: 283.37s, speed-up: 27.9%
256.bzip2: vg1: 152.97s, vg2: 141.28s, speed-up: 7.6%
176.gcc: vg1: 60.27s, vg2: 52.06s, speed-up: 13.6%
181.mcf: vg1: 4.24s, vg2: 4.11s, speed-up: 3.1%
254.gap: vg1: 31.40s, vg2: 24.73s, speed-up: 21.2%
--------
179.art: vg1: 364.32s, vg2: 373.53s, speed-up: -2.5%
183.equake: vg1: 68.86s, vg2: 63.54s, speed-up: 7.7%
188.ammp: vg1: 463.18s, vg2: 455.46s, speed-up: 1.7%
177.mesa: vg1: 113.69s, vg2: 100.01s, speed-up: 12.0%
========
addrcheck
========
164.gzip: vg1: 35.97s, vg2: 27.37s, speed-up: 23.9%
300.twolf: vg1: 5.18s, vg2: 4.48s, speed-up: 13.5%
197.parser: vg1: 57.92s, vg2: 40.95s, speed-up: 29.3%
186.crafty: vg1: 119.23s, vg2: 93.99s, speed-up: 21.2%
255.vortex: vg1: 349.38s, vg2: 223.08s, speed-up: 36.1%
256.bzip2: vg1: 105.23s, vg2: 90.89s, speed-up: 13.6%
176.gcc: vg1: 43.52s, vg2: 33.97s, speed-up: 21.9%
181.mcf: vg1: 2.20s, vg2: 2.07s, speed-up: 5.9%
254.gap: vg1: 22.90s, vg2: 17.82s, speed-up: 22.2%
--------
179.art: vg1: 298.79s, vg2: 294.92s, speed-up: 1.3%
183.equake: vg1: 59.73s, vg2: 57.94s, speed-up: 3.0%
188.ammp: vg1: 404.55s, vg2: 399.96s, speed-up: 1.1%
177.mesa: vg1: 92.93s, vg2: 79.65s, speed-up: 14.3%
For those of you interested in the details: the speed-up was possible
because the skins' handling of %esp updates was decidedly sub-optimal...
every %esp adjustment requires updating the accessibility bits of the
relevant stack words. This was handled with the core events
{new,die}_stack_mem{_aligned,}, after the core computed the %esp-delta at
run-time. And %esp is updated very frequently.
But most of the time the %esp-delta can be computed at compile time, which
saves an extra function call. Now %esp updates are handled with
{new,die}_stack_mem, and optionally the specialised versions
{new,die}_stack_mem_{4,8,12,16,32}. The core uses these specialised
versions if they are present, or falls back to the generic version if not,
or if the delta cannot be determined at compile time. Addrcheck and
Memcheck have unrolled-loop versions for the specialised cases.
Thanks to Julian for pointing out the inefficiency in the old approach.
I haven't tested this super-thoroughly, so I would appreciate it if others
could try it out. I would also be interested to hear what kind of
speed-ups others get on different machines, environments, etc.
Also, since a few things got moved around in the source, this might cause
some CVS clashes with those of actively hacking Valgrind; apologies if
so, but I hope you agree the performance improvements are worth it.
N
|
|
From: Josef W. <Jos...@gm...> - 2003-04-07 14:48:57
|
On Monday 07 April 2003 14:40, Nicholas Nethercote wrote: > On Fri, 4 Apr 2003, Charlls Quarra wrote: > > I wonder if there are issues about profiling > > dinamically loaded plugins? valgrind --skin=cachegrind > > doesnt seem to produce any relevant info about code in > > those plugins, only code in statically linked > > libraries > > Hmm, in theory there should be no problems, Valgrind (and hence > Cachegrind) can handle dlopen'd plugins ok... But they are unmapped before program termination. You only get one cost line "discarded" for all plugins. The solution would be to allow dumping while the plugin is mapped. Or you dump the information of BBCCs when the according object is unmapped. Or you don't delete BBCCs and accumate cost to "discarded", but keep them. Now you have the problem that a BB start address isn't unique to get to the right BBCC, but you have to store the SegInfo* in the BBCCs to distinguish among BBs from different plugins at the same address. BTW, my Calltree skin should be buggy in this regard, as it doesn't delete any BBCCs on unmapping, but still only uses the BB address. But checking the SegInfo* should be easy enough for a fix. Perhaps it's even better to take BBCCs of unmapped objects from the hash into a list, and put them in again if the object is mapped again after adjusting the addresses if needed. The same object could be mapped on a different base address. Josef > > N > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb: > Dedicated Hosting for just $79/mo with 500 GB of bandwidth! > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@ca...> - 2003-04-07 12:40:40
|
On Fri, 4 Apr 2003, Charlls Quarra wrote: > I wonder if there are issues about profiling > dinamically loaded plugins? valgrind --skin=cachegrind > doesnt seem to produce any relevant info about code in > those plugins, only code in statically linked > libraries Hmm, in theory there should be no problems, Valgrind (and hence Cachegrind) can handle dlopen'd plugins ok... N |
|
From: Robert W. <rj...@du...> - 2003-04-07 06:12:52
|
> IIRC, the wine folks have a reasonable configure time check for NPTL in > CVS, so maybe you can simply swipe their code ? I can't find that. I can see a --with-nptl switch, but no automated check. If doing it the automated way is too difficult, maybe having a --with-nptl switch is the way to go? Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Robert W. <rj...@du...> - 2003-04-07 06:07:39
|
> Now what? If the symbol is in the DSO, why can't I link to it? > Mystified. You seem to be saying "Mystified" a lot about the NPTL :-) This does seem strange, though. Are you sure you're picking up the correct library? Maybe you need to say "extern int pthread_join_np();" instead of just "extern int pthread_join_np;" (i.e. declare it as an external function and not variable.) I haven't checked, so this may be a red herring. BTW: my file-descriptor leakage support is almost ready. I'm just testing the "passing fds over a unix-domain socket" support at the moment. Sockets are weird. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Biswapesh C. <bis...@tc...> - 2003-04-07 04:22:43
|
IIRC, the wine folks have a reasonable configure time check for NPTL in
CVS, so maybe you can simply swipe their code ?
Of course, the issue they are facing is that what if the program
(wine/valgrind) is compiled with one kind of threading support and the
binary shipped to a system with a different type of threading ?
Basically, in that case, you need a runtime check as well.
> On Sunday 06 April 2003 6:48 pm, Robert Walsh wrote:
> > > Anyone have a reliable check easily to hand?
> >
> > Yeugh. I don't know if this is reliable, but pthread_tryjoin_np is
> > implemented in nptl but not in the original pthread stuff. Perhaps a
> > check for that will let you know? It will certainly let you know if
> > pthread_tryjoin_np is implemented, but you might allow yourself to infer
> > from that that it's nptl... :-)
>
> Hmm. Sounds a plausible scheme, but ...
>
> On the one hand (on RH 9), nm /lib/tls/libpthread.so.0 | grep tryjoin
> shows pthread_tryjoin_np as an exported text symbol ("T").
>
> On the other hand, you can't link against it:
>
> sewardj@localhost:~/VgHEAD/valgrind$ cat nptltest.c
>
> #include <pthread.h>
> extern int pthread_tryjoin_np;
> int main (int argc, char * argv )
> {
> int* p = (int*)(& pthread_tryjoin_np);
> return 0;
> }
>
> sewardj@localhost:~/VgHEAD/valgrind$ gcc -o nptltest nptltest.c
> -lpthread
> /tmp/ccWjnvw9.o(.text+0x13): In function `main':
> : undefined reference to `pthread_tryjoin_np'
> collect2: ld returned 1 exit status
>
> Now what? If the symbol is in the DSO, why can't I link to it?
> Mystified.
>
> J
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
--
Biswa.
|
|
From: Ranko Z. <ra...@sp...> - 2003-04-07 01:40:14
|
Hi All, First of all I would like to thank Julian for making this tool available. It is great! I'm addressing you because I'm experiencing something that for last two days drove me completely bannanas. I was checking one of my multithreaded app. against the Valgrind, found few mistakes and cleaned some of them up - but some of them I simply cannot understand how do they happen. And I was hoping that some of you might have expirienced the same - and found the solution. Basically, when I'm writing to a file via either write or pwrite I can see in gdb that I'm passing the correct pointers, but when libc performs a syscall, the buffer pointer gets somehow shifted for one byte inside the allocated buffer and crossing the allocated space thus having Valgrind complain about it. The behavior is not consistent because at some places pwrite works like a charm and at certain places it does this funny stuff. The error Valgrind gives is "Address 0x412C72B9 is 1 bytes inside a block of size 32 alloc'd" and the address offset is exactly 1 bytes from what I have passed to the pwrite according to gdb (0x412C72B8). I also see that Valgrind passes the same correct pointer to the library (at vg_libpthread.c:2142). The same error is being reported by both 1.0.4 and 1.9.4. What could be the cause of this behavior? Btw, application seems to be working fine without the Valgrind because the resulting files are correct in the format and the content (they are not missing the first byte or something), but then again, I'm afraid that I might be corrupting something someplace that could fire back afterwards. I've also tried to reproduce the problem in a smaller program, but unfortunately with no luck there. Thanks in advance, Ranko -- Ranko Zivojnovic, NOC Manager ra...@sp... Network Operations Center Spidernet Services Ltd., Tel: +357 22 844844 Nicosia, Cyprus FAX: +357 22 669470 |