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
(3) |
2
(1) |
|
3
(3) |
4
(6) |
5
(6) |
6
(9) |
7
(11) |
8
(8) |
9
(1) |
|
10
(4) |
11
(4) |
12
(13) |
13
(21) |
14
(5) |
15
(4) |
16
(6) |
|
17
(4) |
18
(12) |
19
(3) |
20
(20) |
21
(8) |
22
(4) |
23
(1) |
|
24
(1) |
25
(8) |
26
(11) |
27
(3) |
28
(8) |
29
(1) |
30
(3) |
|
From: Tom H. <to...@co...> - 2006-09-07 15:16:40
|
In message <115...@ok...>
Alex Bennee <ker...@be...> wrote:
>> There is no way to spot writes made by valgrind itself other than
>> by running it under gdb and using the normal gdb watchpoint support.
>
> (gdb) r --smc-check=all dynamite -z config applu < applu.test.in
> Starting program: /usr/local/bin/valgrind --smc-check=all dynamite -z
> config applu < applu.test.in
> ==6286== Memcheck, a memory error detector.
> ==6286== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
> ==6286== Using LibVEX rev 1426, a library for dynamic binary
> translation.
> ==6286== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
> ==6286== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation
> framework.
> ==6286== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
> ==6286== For more details, rerun with: -v
> ==6286==
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000004033d2f66 in ?? ()
> (gdb) x/i $pc
> 0x4033d2f66: mov %ebx,0x0(%r12)
> (gdb) p/x $r12
> $1 = 0x7feffef7c
> (gdb) x/w $1
> 0x7feffef7c: Cannot access memory at address 0x7feffef7c
> (gdb)
>
> Hmmm not a good sign that it doesn't get as far in gdb as running from
> the command line. Now our app does move around in memory, I wonder if
> the combination of Valgrind, Our app and gdb's memory demands are just
> too much to handle?
It is normal for some SEGVs to occur under valgrind - they are caused
by the client program's stack growing beyond it's current limit. They
are caught and fixed up by valgrind though.
See README_DEVELOPERS for instructions on running under gdb.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Alex B. <ker...@be...> - 2006-09-07 15:00:52
|
On Thu, 2006-09-07 at 15:32 +0100, Tom Hughes wrote: > In message <115...@ok...> > Alex Bennee <ker...@be...> wrote: > > >> > Is there a way to log the loads and stores valgrind makes? > >> > >> No. I'm not even entirely sure what loads and stores you are talking > >> about, but the answer is no anyway. > > > > Well something is writing the memory. As we known the address of the > > memory in question is there a way to hook into valgrind and ask it "let > > me know the 2nd time a value is written to this address"? > > There's the old watchpoint patch somewhere but I have no idea if > it still applies... That will only catches writes made by your > code though. I'll give that a try and see it I can get it to apply. How come it never got merged in the first place? It does seem like quite a useful facility > There is no way to spot writes made by valgrind itself other than > by running it under gdb and using the normal gdb watchpoint support. (gdb) r --smc-check=all dynamite -z config applu < applu.test.in Starting program: /usr/local/bin/valgrind --smc-check=all dynamite -z config applu < applu.test.in ==6286== Memcheck, a memory error detector. ==6286== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==6286== Using LibVEX rev 1426, a library for dynamic binary translation. ==6286== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==6286== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==6286== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==6286== For more details, rerun with: -v ==6286== Program received signal SIGSEGV, Segmentation fault. 0x00000004033d2f66 in ?? () (gdb) x/i $pc 0x4033d2f66: mov %ebx,0x0(%r12) (gdb) p/x $r12 $1 = 0x7feffef7c (gdb) x/w $1 0x7feffef7c: Cannot access memory at address 0x7feffef7c (gdb) Hmmm not a good sign that it doesn't get as far in gdb as running from the command line. Now our app does move around in memory, I wonder if the combination of Valgrind, Our app and gdb's memory demands are just too much to handle? > Tom > -- Alex, homepage: http://www.bennee.com/~alex/ Kansas state law requires pedestrians crossing the highways at night to wear tail lights. |
|
From: Tom H. <to...@co...> - 2006-09-07 14:32:14
|
In message <115...@ok...>
Alex Bennee <ker...@be...> wrote:
>> > Is there a way to log the loads and stores valgrind makes?
>>
>> No. I'm not even entirely sure what loads and stores you are talking
>> about, but the answer is no anyway.
>
> Well something is writing the memory. As we known the address of the
> memory in question is there a way to hook into valgrind and ask it "let
> me know the 2nd time a value is written to this address"?
There's the old watchpoint patch somewhere but I have no idea if
it still applies... That will only catches writes made by your
code though.
There is no way to spot writes made by valgrind itself other than
by running it under gdb and using the normal gdb watchpoint support.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Alex B. <ker...@be...> - 2006-09-07 14:26:52
|
On Thu, 2006-09-07 at 15:09 +0100, Tom Hughes wrote: > In message <115...@ok...> > Alex Bennee <ker...@be...> wrote: > > Additionally running the program native with the instrumentation never > > clobbers the pid variable to 0. I think this points more towards a a bug > > with Valgrind. > > I think it's very unlikely. I can't think of a single case of such a > bug in valgrind where it was wrongly writing to client memory. > > Or are you suggesting a translation error so that valgrind is > producing incorrect code? Those are pretty rare as well... > > Far more likely is that running under valgrind has changed the > layout of memory in your program so that an existing problem in > your program is manifesting itself by overwriting something more > important. Could be I guess. But that still leads to the initial problem of how do identify the thing that is clobbering the variable. The value itself is stored in a uint32_t so I tried adding a uint16_t in front of it to see if it was getting lucky doing a 32 bit write into that address. However nothing came up from that. Setting the variable to a 64 bit one didn't pick up a rouge 32 bit write either (if valgrind would pick that up?). > > > Is there a way to log the loads and stores valgrind makes? > > No. I'm not even entirely sure what loads and stores you are talking > about, but the answer is no anyway. Well something is writing the memory. As we known the address of the memory in question is there a way to hook into valgrind and ask it "let me know the 2nd time a value is written to this address"? > > Tom > -- Alex, homepage: http://www.bennee.com/~alex/ WARNING TO ALL PERSONNEL: Firings will continue until morale improves. |
|
From: Tom H. <to...@co...> - 2006-09-07 14:10:04
|
In message <115...@ok...>
Alex Bennee <ker...@be...> wrote:
> On Thu, 2006-09-07 at 10:31 +0100, Alex Bennee wrote:
>> On Wed, 2006-09-06 at 18:49 +0100, Tom Hughes wrote:
>> > In message <115...@ok...>
>> > Alex Bennee <al...@tr...> wrote:
>> Sorry the pid mentioned in getLock is a value stored in our task
>> structure. It is only ever set in the setPid(0 function and after that
>> is a read only value.
>
> Additionally running the program native with the instrumentation never
> clobbers the pid variable to 0. I think this points more towards a a bug
> with Valgrind.
I think it's very unlikely. I can't think of a single case of such a
bug in valgrind where it was wrongly writing to client memory.
Or are you suggesting a translation error so that valgrind is
producing incorrect code? Those are pretty rare as well...
Far more likely is that running under valgrind has changed the
layout of memory in your program so that an existing problem in
your program is manifesting itself by overwriting something more
important.
> Is there a way to log the loads and stores valgrind makes?
No. I'm not even entirely sure what loads and stores you are talking
about, but the answer is no anyway.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Alex B. <ker...@be...> - 2006-09-07 14:05:17
|
On Thu, 2006-09-07 at 10:31 +0100, Alex Bennee wrote: > On Wed, 2006-09-06 at 18:49 +0100, Tom Hughes wrote: > > In message <115...@ok...> > > Alex Bennee <al...@tr...> wrote: > Sorry the pid mentioned in getLock is a value stored in our task > structure. It is only ever set in the setPid(0 function and after that > is a read only value. Additionally running the program native with the instrumentation never clobbers the pid variable to 0. I think this points more towards a a bug with Valgrind. Is there a way to log the loads and stores valgrind makes? -- Alex, homepage: http://www.bennee.com/~alex/ Conversation, n.: A vocal competition in which the one who is catching his breath is called the listener. |
|
From: Alex B. <ker...@be...> - 2006-09-07 09:31:51
|
On Wed, 2006-09-06 at 18:49 +0100, Tom Hughes wrote: > In message <115...@ok...> > Alex Bennee <al...@tr...> wrote: > > > I also added a client side check to the getPid() function to see if it > > was getting trampled. The output was something like: > > > > setPid tc=0x424e170 pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > getLock tc=0x424e170, pid=15979 > > ==15979== Warning: set address range perms: large range 198787072 > > (defined) > > getLock tc=0x424e170, pid=0 > > I assume you mean getpid() and not some special getPid() function of > your own? There is nothing special about the getpid system call under > valgrind so it is unlikely to be a valgrind bug. Sorry the pid mentioned in getLock is a value stored in our task structure. It is only ever set in the setPid(0 function and after that is a read only value. One option could be the variable is being overwritten by an access to some of the structures before it in our tc class. I'm guessing as Valgrind has no knowledge of the internal structure of the class it couldn't tell if being overwritten by the same sized write was a bad thing. I had a quick look at the client request mechanism and I couldn't see if there is a way to write-protect an area of memory once you know its been set and shouldn't change. I shall try adding some overflow structures in and seeing if that changes anything. > > Try adding --trace-syscalls=yes and see if the getpid system call is > really being called at that point. > > > The "set address range perms" is interestingly placed. Whats it mean? > > It means something has caused 190Mb of memory to be marked as > defined in one fell swoop. > > Tom -- Alex, homepage: http://www.bennee.com/~alex/ The hearing ear is always found close to the speaking tongue, a custom whereof the memory of man runneth not howsomever to the contrary, nohow. |
|
From: Josef W. <Jos...@gm...> - 2006-09-07 00:40:14
|
On Monday 04 September 2006 11:21, Christoph Bartoschek wrote: > Currently I see that starting callgrind with --instr-atstart=no causes a > degradation by a factor of 10 (32 hours instead of 3). Callgrind in "No-instrumentation-mode" should have the same slowdown as "valgrind --tool=none ...". > Using the real > instrumentation seems to cause another factor of 8. Altogether I see a > slowdown factor of 80 in the part of the programm I want to profile. > > Are the values reasonable Yes. If you only are interested in the call graph and call counts, you could run without the cache simulation, which should make the profiled parts twice as fast as full simulation. Josef > or is there something wrong here? > > Christoph > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > |
|
From: Josef W. <Jos...@in...> - 2006-09-07 00:10:55
|
On Friday 01 September 2006 09:54, Christoph Bartoschek wrote: > Hi, >=20 > I am currently experimenting with callgrind. What is the correct way to=20 > achieve the following: >=20 > Profile two different actions done in the same process and examine the=20 > profiles separately. > > Till now I would do: >=20 > 1. Start the programm with --instr-atstart=3Dno > 2. Wait till programm flow reaches the desired state. > 3. Start instrumenting: callgrind_control -i on > 4. Start the first action. > 5. Dump a profile: callgrind_control -d first > 6. Start the second action. > 7. Dump a profile: callgrind_control -d second > 8. Stop instrumenting: callgrind_control -i off > 9. Finish the programm. That should do it. However, you probably are confusing "instrumentation off" with "collection of events off". The first includes the second, but also includes "cache simulation off" - which is perhaps not what you want: directly after (3), you will see a cache warmup phase with lots of cold misses, as the cache simulator starts with an empty cache. The only use of "instrumentation off" really is to speed up callgrind a lot on execution uninteresting code sections. The "collection off" is more or less a side effect of this "speedup" feature. Perhaps the following is better: (1) Start the program with callgrind (2) Wait for desired state, and zero counters (3) Run action, and dump counters afterwards =2E.. Depending on your needs, you can do the zeroing/dumping either with callgrind_control, with command options (--zero-before=3Dmyfunc), or with macros in your code (#include "callgrind.h"). Instead of "zero/dump counters", you could also switch collection state on/off. Eg. to only see the events happening between entering/leaving function "myfunc", do "... --collect-atstart=3Dno --toggle-collect=3Dmyfunc= ...".=20 > Is this correct? And how to get separate profiling sessions in kcachegrin= d? Every dump produces a new data file. kcachegrind does not have a special compare mode (yet). You have to load the 2 files into two kcachegrind windo= ws. It is a little bit involved to get source annotations for both old and new source versions nearside on the screen, as KCachegrind loads the source at visualization time; you need both old and new sources in diff= erent directories, and probably profile runs of different binaries where the debug information points to the different versions of the sources. This should be made easier; actually, callgrind_annotate is better for gene= rating source annotations which can be looked at later (after changing the code). To see the difference between an original code version and an optimized one= , it is better to have both in the code and execute them as action 1 and 2 in one program run (as you do). > Does this work seamlessly with the -dump-every-bb option? The effect of this option is some kind of rough interval aggregation, to see changes over time in one program run. The control over when a dump is happe= ning is not really good this way. Josef >=20 > Greetings > Christoph Bartoschek >=20 > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job ea= sier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users >=20 >=20 =2D-=20 Dr. Josef Weidendorfer LRR-TUM (Bode) - Raum 01.06.056 - Tel. +49 / (0)89 / 289 - 18454 Institut f=FCr Informatik, Technische Universit=E4t M=FCnchen |
|
From: Bryan M. <om...@br...> - 2006-09-06 21:19:13
|
Just found an interesting bug in the new function return tracking when using C++. Don't think that C will be affected as you can't do anything like the stuff you can do inside a class constructor. Any C++ users out there getting an error like this before your program actually even gets into main() ?: ==4018== Process terminating with default action of signal 11 (SIGSEGV) ==4018== Access not within mapped region at address 0xFFFFFFFFFFFFFFF8 If so, I'm on it and hope to have a proper solution in the next day or two (I'm ill at the moment so things have slowed down a bit). I know what it is but I will be chatting with the guys on the developer list to get a proper solution together that will always work. Sorry for the inconvenience, Bryan "Brain Murders" Meredith Bryan Meredith wrote: > Fellow Valgrinders, > > please see http://www.brainmurders.eclipse.co.uk/omega.html for a > complete overview of what this tool can do for you! > > (We use this heavily at work - feel free to give it a spin...) > >>From the web page: > ================== > Omega addresses what I perceive to be one of the few shortfalls of the > excellent Valgrind Memcheck Tool - where Memcheck reports the location > that a leaked block was allocated, Omega also shows where it was leaked. > > > New in Beta5: > ============= > Aggregates the circular references together into common contexts, giving > a repeat count and leak amount for that context and makes display optional. > Broke the debugger attach :( > On the positive side, it gives much more accurate leak reports in some > cases, having finally closed off some edge cases with functions that > return values. > A reported bug with realloc() on x86 (not x86-64) was also fixed (thanks > for the report). > Exposed some internal sizing information for users with HUGE programs to > tweak for potentially faster execution. > > The next patch is likely to be a release candidate unless you find me > some juicy bugs to chomp on. > > > Known Issues: > ============= > I have a wrapper around main() to detect when to stop tracking - if you > are using threads and they don't exit before main() does, there will be > problems. I haven't particularly tested this with threads yet - that's > targeted for the later on. It can also affect the stack trace slightly. > > > Requested Features? > =================== > I am still toying with the idea of allowing targeted tracking through > the use of the suppression system - > > exclusively report on a specified malloc() call. > show hanging pointers at a targeted call to free(). > turn on more verbose output for a given memory block. > > Generate leak reports in some XML format to make machine parsing simple. > > > If you use Omega and think any of these features would be useful or have > requests of your own, please let me know. > > > As ever, I would welcome your comments, bug reports and especially any > news of success stories. Please share them with us on the list and copy > me in so I don't miss them. > > thanks and happy hunting, > Bryan "Brain Murders" Meredith > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Tom H. <to...@co...> - 2006-09-06 17:51:16
|
In message <115...@ok...>
Alex Bennee <ker...@be...> wrote:
> I have to Ctrl-C valgrind at which point I get:
>
> ==15125== Invalid read of size 1
> ==15125== at 0x40016C7: _vgnU_freeres (vg_preloaded.c:56)
> ==15125== Address 0xFFFFFFFFFFFFFFFC is not stack'd, malloc'd or
> (recently) free'd
> ==15125==
> ==15125== Process terminating with default action of signal 11
> (SIGSEGV): dumping core
> ==15125== Access not within mapped region at address 0xFFFFFFFFFFFFFFFC
> ==15125== at 0x40016C7: _vgnU_freeres (vg_preloaded.c:56)
I'm not sure this is anything to worry about - it has crashed
trying to run the glibc cleanup code but if glibc has already
corrupted it's state then it's not entirely surprising if that
fails.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2006-09-06 17:49:27
|
In message <115...@ok...>
Alex Bennee <al...@tr...> wrote:
> I also added a client side check to the getPid() function to see if it
> was getting trampled. The output was something like:
>
> setPid tc=0x424e170 pid=15979
> getLock tc=0x424e170, pid=15979
> getLock tc=0x424e170, pid=15979
> getLock tc=0x424e170, pid=15979
> getLock tc=0x424e170, pid=15979
> getLock tc=0x424e170, pid=15979
> getLock tc=0x424e170, pid=15979
> getLock tc=0x424e170, pid=15979
> getLock tc=0x424e170, pid=15979
> getLock tc=0x424e170, pid=15979
> ==15979== Warning: set address range perms: large range 198787072
> (defined)
> getLock tc=0x424e170, pid=0
I assume you mean getpid() and not some special getPid() function of
your own? There is nothing special about the getpid system call under
valgrind so it is unlikely to be a valgrind bug.
Try adding --trace-syscalls=yes and see if the getpid system call is
really being called at that point.
> The "set address range perms" is interestingly placed. Whats it mean?
It means something has caused 190Mb of memory to be marked as
defined in one fell swoop.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Alex B. <al...@tr...> - 2006-09-06 17:28:37
|
On Wed, 2006-09-06 at 17:54 +0100, Alex Bennee wrote: > So I think I have a bug in my code, unfortunately I'm not sure if its > exposed a bug in valgrind as well. It seems odd that I'm seeing a bad > read in the linker code. Further to my previous comments I think it may well be a valgrind bug. I instrumented my code with a few printfs and I can see where the lock value get written and what gets read back. I also added a client side check to the getPid() function to see if it was getting trampled. The output was something like: setPid tc=0x424e170 pid=15979 getLock tc=0x424e170, pid=15979 getLock tc=0x424e170, pid=15979 getLock tc=0x424e170, pid=15979 getLock tc=0x424e170, pid=15979 getLock tc=0x424e170, pid=15979 getLock tc=0x424e170, pid=15979 getLock tc=0x424e170, pid=15979 getLock tc=0x424e170, pid=15979 getLock tc=0x424e170, pid=15979 ==15979== Warning: set address range perms: large range 198787072 (defined) getLock tc=0x424e170, pid=0 Before locking up. No client requests fired. The "set address range perms" is interestingly placed. Whats it mean? > > Any ideas? > > -- > Alex, homepage: http://www.bennee.com/~alex/ > Ask not for whom the tolls. > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Alex Bennee - al...@tr... Your job is being a professor and researcher: That's one hell of a good excuse for some of the brain-damages of minix. (Linus Torvalds to Andrew Tanenbaum) |
|
From: Alex B. <ker...@be...> - 2006-09-06 16:54:20
|
Hi, I'm trying to get to the bottom of a crash I'm seeing while valgrinding: ==15125== Invalid read of size 8 ==15125== at 0x3B731073FE: do_lookup_x (in /lib64/ld-2.3.4.so) ==15125== by 0x3B7310782D: _dl_lookup_symbol_x (in /lib64/ld-2.3.4.so) ==15125== by 0x3B7310A609: fixup (in /lib64/ld-2.3.4.so) ==15125== by 0x3B7310A4D1: _dl_runtime_resolve (in /lib64/ld-2.3.4.so) ==15125== by 0x70258ED7: moveFd(int, bool) ==15125== by 0x700CEFFA: Fuse::openDebugFile() ==15125== by 0x700CF1EB: Fuse::getDebugOutputFD() ==15125== by 0x700C5C40: ErrorReporter::reportError(SeverityLevel,ErrorType, char const*, ...) ==15125== by 0x702B08C4: getLock(unsigned*, ThreadContext*) Unfortunately this doesn't get hit outside of valgrind. I suspect that the act of valgrinding makes us hit a deadlock check in getLock which sends us down the reportError case. However I've been unable to attach gdb to investigate. I have to Ctrl-C valgrind at which point I get: ==15125== Invalid read of size 1 ==15125== at 0x40016C7: _vgnU_freeres (vg_preloaded.c:56) ==15125== Address 0xFFFFFFFFFFFFFFFC is not stack'd, malloc'd or (recently) free'd ==15125== ==15125== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==15125== Access not within mapped region at address 0xFFFFFFFFFFFFFFFC ==15125== at 0x40016C7: _vgnU_freeres (vg_preloaded.c:56) And then wait a while as valgrind calculates all the memory which will obviously be lost due to the early exit. It would be useful to see the data that reportError is about spew. Unfortunately the vgcore left over makes even less sense: 17:49 alexjb@strada [~] >gdb $APP_PATH vgcore.15436 GNU gdb Core was generated by `'. Program terminated with signal 11, Segmentation fault. #0 0x00000000040016c7 in ?? () (gdb) info threads * 1 process 15436 0x00000000040016c7 in ?? () (gdb) frame 0 #0 0x00000000040016c7 in ?? () (gdb) bt #0 0x00000000040016c7 in ?? () #1 0x0000000000000000 in ?? () (gdb) So I think I have a bug in my code, unfortunately I'm not sure if its exposed a bug in valgrind as well. It seems odd that I'm seeing a bad read in the linker code. Any ideas? -- Alex, homepage: http://www.bennee.com/~alex/ Ask not for whom the tolls. |
|
From: Lorenzo M. <rai...@li...> - 2006-09-06 15:14:26
|
> > In message <44FEDC18.4080101 <at> libero.it> > Lorenzo Miniero <rainmaker <at> libero.it> wrote: > > > I'm using Valgrind to check some custom modules I'm implementing in > > Asterisk, a vast opensource PBX. I've been using it with no problem for > > a long time, but a couple of days ago it started complaining giving me > > this fatal error upon Asterisk boot: > > > > --32215:0:aspacem Valgrind: FATAL: aspacem assertion failed: > > --32215:0:aspacem aspacem_minAddr <= holeStart > > --32215:0:aspacem at m_aspacemgr/aspacemgr.c:1997 > > (vgPlain_am_get_advisory) > > --32215:0:aspacem Exiting now. > > > > > > The problem was probably caused by the fact I've passed from the stable > > branch of Asterisk to the SVN trunk, since it didn't happen before. > > Digging through the old messages in the mailing list, I only could find > > one related message of about a month ago, with the difference that in > > that case the problem regarded holeEnd and not holeStart. > > It may well be the same problem though - try using the SVN build of > valgrind and see if that helps. You need at least revision 6001 to get > the fix for that problem. > > > Could you help me understanding where the problem is, and how I could > > try solving it? > > If there is still a problem it is in valgrind so you should open a > bug on the bug tracker. > > Tom > Hi Tom, thanks a lot for the very quick answer. I just upgraded Valgrind to the SVN version (rev.6044), but the error is still there: the only difference is in the reported aspacemgr.c line, not 1997 anymore but 2003. I'll try on other machines too before opening a new bug in the tracker. In case the problem should appear on them too, I'll follow the guidelines on the site and report the bug to the tracker. Best regards, Lorenzo -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. |
|
From: Tom H. <to...@co...> - 2006-09-06 14:48:48
|
In message <44F...@li...>
Lorenzo Miniero <rai...@li...> wrote:
> I'm using Valgrind to check some custom modules I'm implementing in
> Asterisk, a vast opensource PBX. I've been using it with no problem for
> a long time, but a couple of days ago it started complaining giving me
> this fatal error upon Asterisk boot:
>
> --32215:0:aspacem Valgrind: FATAL: aspacem assertion failed:
> --32215:0:aspacem aspacem_minAddr <= holeStart
> --32215:0:aspacem at m_aspacemgr/aspacemgr.c:1997
> (vgPlain_am_get_advisory)
> --32215:0:aspacem Exiting now.
>
>
> The problem was probably caused by the fact I've passed from the stable
> branch of Asterisk to the SVN trunk, since it didn't happen before.
> Digging through the old messages in the mailing list, I only could find
> one related message of about a month ago, with the difference that in
> that case the problem regarded holeEnd and not holeStart.
It may well be the same problem though - try using the SVN build of
valgrind and see if that helps. You need at least revision 6001 to get
the fix for that problem.
> Could you help me understanding where the problem is, and how I could
> try solving it?
If there is still a problem it is in valgrind so you should open a
bug on the bug tracker.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Lorenzo M. <rai...@li...> - 2006-09-06 14:32:57
|
Hi,
I'm using Valgrind to check some custom modules I'm implementing in
Asterisk, a vast opensource PBX. I've been using it with no problem for
a long time, but a couple of days ago it started complaining giving me
this fatal error upon Asterisk boot:
--32215:0:aspacem Valgrind: FATAL: aspacem assertion failed:
--32215:0:aspacem aspacem_minAddr <= holeStart
--32215:0:aspacem at m_aspacemgr/aspacemgr.c:1997
(vgPlain_am_get_advisory)
--32215:0:aspacem Exiting now.
The problem was probably caused by the fact I've passed from the stable
branch of Asterisk to the SVN trunk, since it didn't happen before.
Digging through the old messages in the mailing list, I only could find
one related message of about a month ago, with the difference that in
that case the problem regarded holeEnd and not holeStart.
Could you help me understanding where the problem is, and how I could
try solving it?
I thank you in advance, best regards,
Lorenzo
--
http://confiance.sourceforge.net/
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
|
|
From: David E. <de...@cs...> - 2006-09-06 02:56:55
|
I tried it with the debug info packages and malloc, and now there are only a few X/gtk errors. Anyone have suggestions on how to approach those? Maybe someone on the gtk-app-devel-list? Thanks, David Julian Seward wrote: >>Maybe you should set G_SLICE=always-malloc in the environment in order >>to make valgrind more useful: >> >> http://developer.gnome.org/doc/API/2.0/glib/glib-running.html >> >> > >I agree; from a guess I'd say that glib is using a private allocator, >which confuses the issue. > >Unrelatedly .. > >It looks like the 'valgrind-3.1.1-Debian' you are using has been >shipped without a set of suppressions suitable for getting rid of >all the complaints of the form > >==3722== Conditional jump or move depends on uninitialised value(s) >==3722== at 0x401139F: (within /lib/ld-2.3.6.so) >==3722== by 0x4006ACE: (within /lib/ld-2.3.6.so) >==3722== by 0x48A14AF: (within /lib/tls/i686/cmov/libc-2.3.6.so) >==3722== by 0x400BA5E: (within /lib/ld-2.3.6.so) > >which is a shame. It may be that if you install debug info packages >for /lib/ld-2.3.6.so and/or libc-2.3.6.so, that noise will go away. > >J > > |
|
From: Emre C. S. <ec...@nc...> - 2006-09-05 17:32:12
|
>
>> vex: priv/host-x86/isel.c:510 (doHelperCall): Assertion
>> `typeOfIRExpr(env->type_env, args[i]) == Ity_I32' failed.
>> vex storage: T total 1181960 bytes allocated
>
>> case Ist_Store:
>> {
>> IRExpr* data = st->Ist.Store.data;
>> IRExpr* addr = st->Ist.Store.addr;
>> if (addr!=NULL && data !=NULL)
>> {
>> IRExpr** argv = mkIRExprVec_2( addr, data ); di =
unsafeIRDirty_0_N( /*regparms*/2,
>> "check_write",
>> VG_(fnptr_to_fnentry)(
>> &check_write_1 ),
>> argv );
>> addStmtToIRBB( bbOut, IRStmt_Dirty(di) );
>> }
>> addStmtToIRBB( bbOut, st );
>> }
>
> I'd guess your problem is that the store data isn't of 32-bit type (that
is, 'data' in the above fragment has an IR type which isn't Ity_I32).
The VEX code generator only supports a very limited set of argument
types for helper functions - probably only I32
> and I64 on x86.
>
> If 'data' has type I8 or I16, I suggest you widen it to I32
> by wrapping Iop_8Uto32 or Iop_16Uto32 around it. You may find
> this useful:
>
> /* U-widen 8/16/32 bit int expr to 32. */
> static IRExpr* widenUto32 ( IRExpr* e )
> {
> switch (typeOfIRExpr(irbb->tyenv,e)) {
> case Ity_I32: return e;
> case Ity_I16: return unop(Iop_16Uto32,e);
> case Ity_I8: return unop(Iop_8Uto32,e);
> default: vpanic("widenUto32");
> }
> }
>
> If 'data' has type I64, you can probably leave it unchanged.
> If 'data' has type F64, I suggest you coerce it to I64 and
> then act as I64. If that doesn't make sense, look in
> guest-x86/toIR.c for "case 7: { /* FSTP extended-real */", which passes
a 64-bit float to a helper function.
>
> If 'data' has type V128 (128-bit vector), you're probably
> hosed :-)
>
> J
>
First of all thank you for the valuable reply. I pretty much copy pasted
the procedure with some minor changes (unop was replaced with
IRExpr_Unop). And wrapped the data argument with this function as follows:
static IRExpr* widenUto32 ( IRBB* irbb, IRExpr* e )
{
switch (typeOfIRExpr(irbb->tyenv,e)) {
case Ity_I32: return e;
case Ity_I16: return IRExpr_Unop(Iop_16Uto32,e);
case Ity_I8: return IRExpr_Unop(Iop_8Uto32,e);
default:
VG_(message)(**some error mesage**);
VG_(exit)(0);
}
}
Here is the instrument code:
...
case Ist_Store:
{
IRExpr* data = st->Ist.Store.data;
IRExpr* addr = st->Ist.Store.addr;
if (addr!=NULL && data !=NULL)
{
Change here -> IRExpr** argv = mkIRExprVec_2( addr, widenUto32(data) );
di = unsafeIRDirty_0_N( /*regparms*/2, "check_write",
VG_(fnptr_to_fnentry)(
&check_write_1 ),
argv );
addStmtToIRBB( bbOut, IRStmt_Dirty(di) );
}
addStmtToIRBB( bbOut, st );
}
break;
I get the following error with this code.
IN STATEMENT:
DIRTY 1:I1 ::: check_write[rp=2]{0x38000080}(t27,8Uto32(t24))
ERROR = IRStmt: is not flat
The code works fine if I only work with Ity_I32 type IRExpr's and don't
use widening. Does this error mean that I'm creating an IRExpr tree
instead of just a single expression?
Thank you in advance,
John
PS. Sorry for the double post. The previous email was incomplete.
|
|
From: Emre C. S. <ec...@nc...> - 2006-09-05 17:23:58
|
>
>> vex: priv/host-x86/isel.c:510 (doHelperCall): Assertion
>> `typeOfIRExpr(env->type_env, args[i]) == Ity_I32' failed.
>> vex storage: T total 1181960 bytes allocated
>
>> case Ist_Store:
>> {
>> IRExpr* data = st->Ist.Store.data;
>> IRExpr* addr = st->Ist.Store.addr;
>> if (addr!=NULL && data !=NULL)
>> {
>> IRExpr** argv = mkIRExprVec_2( addr, data );
>> di = unsafeIRDirty_0_N( /*regparms*/2,
>> "check_write",
>> VG_(fnptr_to_fnentry)(
>> &check_write_1 ),
>> argv );
>> addStmtToIRBB( bbOut, IRStmt_Dirty(di) );
>> }
>> addStmtToIRBB( bbOut, st );
>> }
>
> I'd guess your problem is that the store data isn't of 32-bit type
> (that is, 'data' in the above fragment has an IR type which isn't
> Ity_I32). The VEX code generator only supports a very limited set
> of argument types for helper functions - probably only I32
> and I64 on x86.
>
> If 'data' has type I8 or I16, I suggest you widen it to I32
> by wrapping Iop_8Uto32 or Iop_16Uto32 around it. You may find
> this useful:
>
> /* U-widen 8/16/32 bit int expr to 32. */
> static IRExpr* widenUto32 ( IRExpr* e )
> {
> switch (typeOfIRExpr(irbb->tyenv,e)) {
> case Ity_I32: return e;
> case Ity_I16: return unop(Iop_16Uto32,e);
> case Ity_I8: return unop(Iop_8Uto32,e);
> default: vpanic("widenUto32");
> }
> }
>
> If 'data' has type I64, you can probably leave it unchanged.
> If 'data' has type F64, I suggest you coerce it to I64 and
> then act as I64. If that doesn't make sense, look in
> guest-x86/toIR.c for "case 7: { /* FSTP extended-real */", which
> passes a 64-bit float to a helper function.
>
> If 'data' has type V128 (128-bit vector), you're probably
> hosed :-)
>
> J
>
First of thank you for the valuable reply. I pretty much copy pasted the
procedure with some minor changes (unop was replaced with IRExpr_Unop).
And wrapped the data argument with this function as follows:
static IRExpr* widenUto32 ( IRBB* irbb, IRExpr* e )
{
switch (typeOfIRExpr(irbb->tyenv,e)) {
case Ity_I32: return e;
case Ity_I16: return IRExpr_Unop(Iop_16Uto32,e);
case Ity_I8: return IRExpr_Unop(Iop_8Uto32,e);
default:
VG_(message)(**some error mesage**);
VG_(exit)(0);
}
}
case Ist_Store:
{
IRExpr* data = st->Ist.Store.data;
IRExpr* addr = st->Ist.Store.addr;
if (addr!=NULL && data !=NULL)
{
Only this line changed from previous code:
IRExpr** argv = mkIRExprVec_2( addr, widenUto32(data) );
di = unsafeIRDirty_0_N( /*regparms*/2, "check_write",
VG_(fnptr_to_fnentry)(
&check_write_1 ),
argv );
addStmtToIRBB( bbOut, IRStmt_Dirty(di) );
}
addStmtToIRBB( bbOut, st );
}
break;
Only this line changed from previous code:
IRExpr** argv = mkIRExprVec_2( addr, widenUto32( bbIn, data ) );
|
|
From: Christoph B. <bar...@or...> - 2006-09-05 15:13:39
|
Am Dienstag, 5. September 2006 16:09 schrieb Julian Seward: > > my callgrind test crashed today during the write of the results file such > > that nearly all results vanished. The logfile is attached. > > Depending on which bug it is, it may already have been fixed. > Can you re-run with --trace-syscalls=yes and send the result? > > J Is the current repository version stable enough to use it? Then I could test whether it is already fixed. Christoph |
|
From: Christoph B. <bar...@or...> - 2006-09-05 14:33:15
|
Am Dienstag, 5. September 2006 16:09 schrieb Julian Seward: > > my callgrind test crashed today during the write of the results file such > > that nearly all results vanished. The logfile is attached. > > Depending on which bug it is, it may already have been fixed. > Can you re-run with --trace-syscalls=yes and send the result? > Hi, the run takes more than 19 hours and I guess there are a lot of syscalls during this period. Is there a way to give you the necessary information without a whole trace? Christoph |
|
From: Julian S. <js...@ac...> - 2006-09-05 14:10:50
|
> my callgrind test crashed today during the write of the results file such > that nearly all results vanished. The logfile is attached. Depending on which bug it is, it may already have been fixed. Can you re-run with --trace-syscalls=yes and send the result? J |
|
From: Christoph B. <bar...@or...> - 2006-09-05 09:09:05
|
Hi, my callgrind test crashed today during the write of the results file such that nearly all results vanished. The logfile is attached. Christoph Bartoschek |
|
From: consensus <ade...@ro...> - 2006-09-04 13:20:29
|
Atttention all day traedrs and invsetors Breaking news will realease on monday !!! Watch it explode on monday!!! Latest news: Prmeium Pteroleum, Inc.: Acquires Additional Zone on Boyne Lake Prospect. Calgary, Alberta--(Makret W i r e)-- Permium Petroluem, Inc. (Other OTC:PPT L.PK - News) is pleased to announce that it has acquired production rights to an additional zone on the Boyne Lake prospect in Alberta Canada. Based on data collected throughout the drilling stage it was decided to purchase the rights for this zone. Due to wet weather conditions, the company has not been able to mobilize equipment onto the property to complete the well testing. The company anticipates the two zones will be tested within the next 30 days.As previously mentioned, the well is still on tight hole status, and therefore information regarding the testing results will not be released until a future date. The company anticipates that in the coming months it will be successful in acquiring prospective crown oil and gas lease(s) with significant upside potential. The company also continues to review potential joint venture opportunities with third parties.Bruce A. Thomson, B.A. Sc. ; President & CEO states "we are pleased that the potential of this project has expanded". Invsetor a lert don't miss another run on PPT L!!! Some stocks moving higher, some moving lower. You need to be on the constant watch. I have something which may be of great use for you, the clever trader. Cmopany: Permium Pertolm new Ticker: PPT L C u r r e n t p r i c e: $0.0130 T a r g e t p r i c e: $0.05 Recommednation: srtong b y e P r i c e increase fforeacast: Max Riskk Facttor: Loweest Watch PP TL like a hawk on monday September 4, About Innovation Holdings: Premium is set to exploit petroleum and natural gas reserves in an environment of unprecedented commodity p r i c e s and under the guidance of a highly qualified mangaement and technical team.Premium is an emerging junior oil and gas company finnacially well connected, coupled with a strong manaegment and technical team focused on exploiting oil and gas reserves in the Wsetern Caandian Sdeimentary basin to 6000 feet in depth. Managmeent intends to pursue a growth strategy through Land Assembly, Joint Ventures (Farmin / Farmout), and Acquisitions. The C o m p a n y has assembled a seasoned team of managers and technical professionals in the areas of geology, engineering, and legal. With the depth of the management and technical team we have assembled, Premium is poised for aggressive asset growth and development. Conclusion: The examples above show the awesome, earning potential of little known companies that explode onto i n v s e t o r's r a d a r screens; Many of you are already familiar with this. PP TL has already shown p r i c e growth up to $$0.05 in the past (see historical data ) it will b o o m this monday again! Get on P PTL first thing on monday!!! Is PP TL poised and positioned to do that for you? Then you may feel the time has come to act... And please watch this one t r a d e tomorrow! Go PP TL!!! Good setups are plentiful with this rare yet very promising stock. |