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
(1) |
2
(4) |
3
|
4
(18) |
5
(20) |
6
(2) |
7
|
|
8
|
9
|
10
(6) |
11
|
12
(12) |
13
(3) |
14
(1) |
|
15
(2) |
16
(3) |
17
|
18
(9) |
19
(10) |
20
(18) |
21
(1) |
|
22
(10) |
23
(3) |
24
(25) |
25
(13) |
26
(2) |
27
(5) |
28
|
|
29
(1) |
30
(1) |
31
(6) |
|
|
|
|
|
From: <Woe...@on...> - 2006-10-19 22:18:59
|
Hi,
I get this warnings from Qt 3 code with GCC 4.1.1 on AMD64:
Conditional jump or move depends on uninitialised value(s)
for this code:
if (atEnd()) ...
with=20
inline bool QXmlSimpleReader::atEnd()
{ return (c.unicode()|0x0001) =3D=3D 0xffff; }
class QChar {
ushort &unicode() { return ucs; }
ushort ucs;
}
the disassembly is:
mov 0x40(%rbp),%eax
or $0x1,%eax
inc %ax
je 0x504ba10 <_ZN16QXmlSimpleReader11parsePrologEv+1120>
I don't know why an ushort is loaded to eax but as only ax is=20
incremented why does this trigger a warning in valgrind?
Cheers,
Andr=E9
|
|
From: Tom H. <to...@co...> - 2006-10-19 21:11:14
|
In message <200...@we...>
Praveen K <pra...@ya...> wrote:
> Im trying to run valgrind on a piece of code which makes function calls
> from within a macro expansion. As a result, the trace looks like this:
>
> ==5712== at 0x401D7AA: calloc (vg_replace_malloc.c:279)
> ==5712== by 0x43DAFC9: ???
> ==5712== by 0x43E8CDF: ???
> ==5712== by 0x43E9C1E: ???
> ==5712== by 0x43C7E62: ???
> ==5712== by 0x43C7EDA: ???
> ==5712== by 0x43618EC: ???
> ==5712== by 0x805E14C: plugins_call_init (plugin.c:407)
> ==5712== by 0x804D2BB: main (server.c:806)
>
> How can I see what function is exactly being called, and/or how can I get a
> complete trace.
I'm not sure what macro expansions have to do with anything - the
reason you're getting the ??? in the trace is that there is no
symbol information available.
Given the name of the functions we can see I'm guessing that you
are calling a dynamically loaded plugin that is getting unloaded
which means that there is no symbol table available when valgrind
comes to print the report (this is a memory leak I assume?).
I would advise tweaking your program to not unload plugins on
exit when running under valgrind.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Praveen K <pra...@ya...> - 2006-10-19 17:48:36
|
Hi all,=0A=0AIm trying to run valgrind on a piece of code which makes funct= ion calls from within a macro expansion. As a result, the trace looks like = this:=0A=0A=0A=0A=3D=3D5712=3D=3D at 0x401D7AA: calloc (vg_replace_mallo= c.c:279)=0A=0A=3D=3D5712=3D=3D by 0x43DAFC9: ???=0A=0A=3D=3D5712=3D=3D = by 0x43E8CDF: ???=0A=0A=3D=3D5712=3D=3D by 0x43E9C1E: ???=0A=0A=3D=3D5= 712=3D=3D by 0x43C7E62: ???=0A=0A=3D=3D5712=3D=3D by 0x43C7EDA: ???= =0A=0A=3D=3D5712=3D=3D by 0x43618EC: ???=0A=0A=3D=3D5712=3D=3D by 0x8= 05E14C: plugins_call_init (plugin.c:407)=0A=0A=3D=3D5712=3D=3D by 0x804D= 2BB: main (server.c:806)=0A=0AHow can I see what function is exactly being = called, and/or how can I get a complete trace.=0A=0AThanks,=0APraveen=0A=0A= ----=0AI'll be more enthusiastic about encouraging thinking outside the box= when there's evidence of any thinking going on inside it.=0A=0A - Terry P= ratchett=0A=0A=0A=0A=0A=0A=0A |
|
From: Nicholas N. <nj...@cs...> - 2006-10-19 10:16:46
|
On Thu, 19 Oct 2006, Pim Nijdam wrote: > Yes you're right Tom. My fallacy was the folowing: I reasoned that as > soon as the current running thread would write to the pipe another > thread would be scheduled. But of course the scheduler may choose to > continue running the current running thread, enabling it to reclaim > Valgrinds lock. Yes, that's how it works with single-threaded programs :) Nick> |
|
From: Pim N. <pn...@ai...> - 2006-10-19 10:00:52
|
Julian Seward wrote: >>>priority thread is scheduled. Two threads will run interleaved (one with >>>possibly a lower priority). Is my concern grounded? >> >>Well set_sleeping will write to the pipe that all the other threads >>that are ready to run (ie not blocked in a system call made by the >>client) are trying to read from. >> >>How the kernel chooses which of threads which are trying to read from >>the pipe to wake up is up to it - but I assume it would respect the >>currently active scheduler algorithm? Yes you're right Tom. My fallacy was the folowing: I reasoned that as soon as the current running thread would write to the pipe another thread would be scheduled. But of course the scheduler may choose to continue running the current running thread, enabling it to reclaim Valgrinds lock. > I agree with Tom. Valgrind only really provides a lock which stops > more than one thread running at once. It doesn't mess with scheduling > or priorities in any other way. So unless the kernel is doing something > strange, your priorities should be observed. Can you create a small > test case that shows the problem? I tried, but it showed me I was wrong. Well I can happily use Valgrind without having to worry about this! Thanks to both of you for your quick replies. Pim Nijdam -- This message has been scanned for viruses and is believed to be clean |
|
From: Nicholas N. <nj...@cs...> - 2006-10-19 03:54:15
|
On Thu, 19 Oct 2006, Axel Liljencrantz wrote: > I reported a bug in Massif about 4 months ago, see > http://bugs.kde.org/show_bug.cgi?id=129576. The problem, i.e. massif > 'losing track' of allocated memory and reporting far lower memory > usage than it should, is still present, so I was wondering if this > will be fixed or if Massif is 'going away'. Also, is there is anything > I can do to help out? Massif isn't going away, but it doesn't get maintained much due to lack of time on my part. The files mentioned in that bug report no longer exist at the given URLs. IIRC I didn't find the bug report compelling... you basically said "the output is a bit different to what I expected", which didn't convince me that Massif was doing the wrong thing -- maybe your program just doesn't behave exactly how you expect. Especially if it's in C++ and uses the STL. > I just tried to run massif on the standard 'bash' on my FC5 install, > and I could see what I strongly belive to be the same bug happening > there as well, so this should not be a hard problem to reproduce. Best thing you can do is to write a small test case that conclusively shows the alleged problem. Nick |
|
From: Axel L. <lil...@gm...> - 2006-10-18 23:27:53
|
Hi, I reported a bug in Massif about 4 months ago, see http://bugs.kde.org/show_bug.cgi?id=129576. The problem, i.e. massif 'losing track' of allocated memory and reporting far lower memory usage than it should, is still present, so I was wondering if this will be fixed or if Massif is 'going away'. Also, is there is anything I can do to help out? I just tried to run massif on the standard 'bash' on my FC5 install, and I could see what I strongly belive to be the same bug happening there as well, so this should not be a hard problem to reproduce. Thanks for a very nice program. -- Axel |
|
From: Julian S. <js...@ac...> - 2006-10-18 15:23:16
|
> > priority thread is scheduled. Two threads will run interleaved (one with > > possibly a lower priority). Is my concern grounded? > > Well set_sleeping will write to the pipe that all the other threads > that are ready to run (ie not blocked in a system call made by the > client) are trying to read from. > > How the kernel chooses which of threads which are trying to read from > the pipe to wake up is up to it - but I assume it would respect the > currently active scheduler algorithm? I agree with Tom. Valgrind only really provides a lock which stops more than one thread running at once. It doesn't mess with scheduling or priorities in any other way. So unless the kernel is doing something strange, your priorities should be observed. Can you create a small test case that shows the problem? J |
|
From: Tom H. <to...@co...> - 2006-10-18 15:14:30
|
In message <453...@ai...>
Pim Nijdam <pn...@ai...> wrote:
>> Note that it is still the kernel scheduler which decide which thread
>> to run next when set_sleeping is called, so the thread should still
>> run in FIFO order if that is what you have told the kernel to do - all
>> we do is control when the switch occurs.
>
> That's the point. When a thread is 'sleeping' (blocked for valgrind's
> run semafor) another thread will be scheduled. But maybe there was no
> reason (higher priority thread) to switch to another thead. I'm
> concerned that instead of running one thread untill say a higher
> priority thread is scheduled. Two threads will run interleaved (one with
> possibly a lower priority). Is my concern grounded?
Well set_sleeping will write to the pipe that all the other threads
that are ready to run (ie not blocked in a system call made by the
client) are trying to read from.
How the kernel chooses which of threads which are trying to read from
the pipe to wake up is up to it - but I assume it would respect the
currently active scheduler algorithm?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Pim N. <pn...@ai...> - 2006-10-18 14:44:17
|
Thanks for your reply. Tom Hughes wrote: > Because valgrind deliberately only allows one thread to run at a > time (because none of the translation machinery, or things like > memcheck, is threadsafe) so it has to switch threads manually. > > All threads except the running one will be blocked waiting for > valgrinds master lock, which the set_sleeping call will release > allowing the kernel scheduler to give control to another thread. Ah, that's the thing I forgot: all other threads are blocked and won't be scheduled by the kernel. > Note that it is still the kernel scheduler which decide which thread > to run next when set_sleeping is called, so the thread should still > run in FIFO order if that is what you have told the kernel to do - all > we do is control when the switch occurs. That's the point. When a thread is 'sleeping' (blocked for valgrind's run semafor) another thread will be scheduled. But maybe there was no reason (higher priority thread) to switch to another thead. I'm concerned that instead of running one thread untill say a higher priority thread is scheduled. Two threads will run interleaved (one with possibly a lower priority). Is my concern grounded? Pim Nijdam -- This message has been scanned for viruses and is believed to be clean |
|
From: Patrick O. <pat...@in...> - 2006-10-18 12:42:18
|
Hi all, while debugging an unknown, rather large application I found use-after-free errors pretty quickly thanks to valgrind, but then trying to make sense of them took a while until I realized that the free() occurred in another thread while the failing one was iterating over the same data. So the real problem was not incorrect tracking of resources, but rather missing locking. It would have been easier to recognize that if valgrind had included some kind of thread identifier in its output, something like "invalid memory access in thread #1: ... memory was freed by thread #2: ...". What do you think? How difficult would it be to add that? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. |
|
From: Tom H. <to...@co...> - 2006-10-18 12:21:41
|
In message <453...@ai...>
Pim Nijdam <pn...@ai...> wrote:
> I noticed that Valgrinds scheduler yields the processor to another
> thread after excecuting N basic blocks. Does someone know why Valgrinds
> scheduler uses slices instead of just relying on the scheduling of the
> threads?
Because valgrind deliberately only allows one thread to run at a
time (because none of the translation machinery, or things like
memcheck, is threadsafe) so it has to switch threads manually.
All threads except the running one will be blocked waiting for
valgrinds master lock, which the set_sleeping call will release
allowing the kernel scheduler to give control to another thread.
> I try to run Valgrind 3.2.1 on an embedded system (ppc32) where the
> application sets a fifo scheduling policy for the threads.
> Since I need to keep fifo scheduling I need to disable this slice
> system. Is it save to comment out the following lines in the scheduler?
>
> while(!VG_(is_exiting)(tid)) {
> if (VG_(dispatch_ctr) == 1) {
> VG_(set_sleeping)(tid, VgTs_Yielding); // <-- comment out
> /* nothing */
> VG_(set_running)(tid); // <-- comment out
> ...
>
> This seemed to me the least aggresive change. Running this seems to be
> fine, but I figured there would be a reason for this slice business and
> maybe I screw it up.
With your change control will only ever move to a new thread when a
system call blocks, so a thread which makes no blocking system calls
will run forever.
Note that it is still the kernel scheduler which decide which thread
to run next when set_sleeping is called, so the thread should still
run in FIFO order if that is what you have told the kernel to do - all
we do is control when the switch occurs.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Pim N. <pn...@ai...> - 2006-10-18 11:59:41
|
Hi,
First of all. Valgrind works great! However I'm having some trouble with
thread scheduling.
I noticed that Valgrinds scheduler yields the processor to another
thread after excecuting N basic blocks. Does someone know why Valgrinds
scheduler uses slices instead of just relying on the scheduling of the
threads?
I try to run Valgrind 3.2.1 on an embedded system (ppc32) where the
application sets a fifo scheduling policy for the threads.
Since I need to keep fifo scheduling I need to disable this slice
system. Is it save to comment out the following lines in the scheduler?
while(!VG_(is_exiting)(tid)) {
if (VG_(dispatch_ctr) == 1) {
VG_(set_sleeping)(tid, VgTs_Yielding); // <-- comment out
/* nothing */
VG_(set_running)(tid); // <-- comment out
...
This seemed to me the least aggresive change. Running this seems to be
fine, but I figured there would be a reason for this slice business and
maybe I screw it up.
--
Do you know about the dangers of DRM? Find out at
http://www.defectivebydesign.org/what_is_drm
--
This message has been scanned for viruses and is believed to be clean
|
|
From: Nicholas N. <nj...@cs...> - 2006-10-18 02:36:18
|
On Tue, 17 Oct 2006, Mohit Tiwari wrote: > 1. I compared the runtimes of nulgrind with that of reduced memcheck, that > performs no instrumentation and has its MC_(instrument) function simply > return bb_in, > and noticed that there is a significant difference in their running times. > For gcc, with a lgred data input, the timing is 134s for nulgrind and 170s > for reduced emcheck. Why could that be? Shouldn't their performance be > similar? Memcheck also replaces malloc, free and related functions with its own version. That will make a difference, especially on an allocation-heavy program like gcc. I expect the difference would be smaller on Fortran benchmarks, for example. Also, Memcheck's event handlers (for new_mem_*, die_mem_*, etc) will still be running, eg. for when system calls execute. You'll need to disable them too. > 2. I wished to find out how the peformance of an instrumented program > degrades depending upon the number of instructions that get inserted by the > *_(instrument) function. Is there a way I can find out how many IRs and x86 > instructions got added in? Try the --help-debug flag, and look at the output. --trace-flags shows you the IR at every stage. It doesn't count it though, you'll have to add code to do that yourself. Nick |
|
From: Mohit T. <moh...@gm...> - 2006-10-18 02:10:47
|
Hello, I am new to Valgrind and had two questions regarding the functioning of Valgrind. (I am using VG 3.1.1.) 1. I compared the runtimes of nulgrind with that of reduced memcheck, that performs no instrumentation and has its MC_(instrument) function simply return bb_in, and noticed that there is a significant difference in their running times. For gcc, with a lgred data input, the timing is 134s for nulgrind and 170s for reduced emcheck. Why could that be? Shouldn't their performance be similar? 2. I wished to find out how the peformance of an instrumented program degrades depending upon the number of instructions that get inserted by the *_(instrument) function. Is there a way I can find out how many IRs and x86 instructions got added in? Thanks a lot, Mohit |
|
From: <joh...@gm...> - 2006-10-16 13:41:59
|
Why do I get spam ( I assume!!) on this mailing list, but not on any others? John |
|
From: Jayne W. <jwo...@ho...> - 2006-10-16 11:19:54
|
This is an HTML email, please use HTML format to open it! |
|
From: Zhiyao T. <mc...@gm...> - 2006-10-16 06:54:39
|
Hi, I tried to use memcheck tool to check whether there're memory leaks in my program. In the initialization part of my program, I created 2 threads through ACE's wrappers class ACE_Task (my program is based on ACE library). These two threads are almost same. But the memcheck tool reports that one of them definitely has memory leak while another possibly has memory leak (when creating): ==22571== 144 bytes in 1 blocks are possibly lost in loss record 97 of 133 ==22571== at 0x4A1AB36: calloc (vg_replace_malloc.c:279) ==22571== by 0x400EA4D: _dl_allocate_tls (in /lib/ld-2.3.6.so) ==22571== by 0x6447500: pthread_create@@GLIBC_2.2.5 (in /lib/libpthread-2.3.6.so) ==22571== by 0x577E23C: ACE_OS::thr_create(void* (*)(void*), void*, long, unsigned long*, unsigned long*, long, void*, unsigned long, ACE_Base_Thread_Adapter*) (in /usr/lib/libACE.so.5.5.2) ==22571== by 0x57B185E: ACE_Thread_Manager::spawn_i(void* (*)(void*), void*, long, unsigned long*, unsigned long*, long, int, void*, unsigned long, ACE_Task_Base*) (in /usr/lib/libACE.so.5.5.2) ==22571== by 0x57B4F30: ACE_Thread_Manager::spawn_n(unsigned long, void* (*)(void*), void*, long, long, int, ACE_Task_Base*, unsigned long*, void**, unsigned long*) (in /usr/lib/libACE.so.5.5.2) ==22571== by 0x57AF3F4: ACE_Task_Base::activate(long, int, int, long, int, ACE_Task_Base*, unsigned long*, void**, unsigned long*, unsigned long*) (in /usr/lib/libACE.so.5.5.2) ==22571== by 0x40E162: MyProgram::init(ACE_Reactor*) (aaa.cpp:198) ==22571== ==22571== ==22571== 144 bytes in 1 blocks are definitely lost in loss record 98 of 133 ==22571== at 0x4A1AB36: calloc (vg_replace_malloc.c:279) ==22571== by 0x400EA4D: _dl_allocate_tls (in /lib/ld-2.3.6.so) ==22571== by 0x6447500: pthread_create@@GLIBC_2.2.5 (in /lib/libpthread-2.3.6.so) ==22571== by 0x577E23C: ACE_OS::thr_create(void* (*)(void*), void*, long, unsigned long*, unsigned long*, long, void*, unsigned long, ACE_Base_Thread_Adapter*) (in /usr/lib/libACE.so.5.5.2) ==22571== by 0x57B185E: ACE_Thread_Manager::spawn_i(void* (*)(void*), void*, long, unsigned long*, unsigned long*, long, int, void*, unsigned long, ACE_Task_Base*) (in /usr/lib/libACE.so.5.5.2) ==22571== by 0x57B4F30: ACE_Thread_Manager::spawn_n(unsigned long, void* (*)(void*), void*, long, long, int, ACE_Task_Base*, unsigned long*, void**, unsigned long*) (in /usr/lib/libACE.so.5.5.2) ==22571== by 0x57AF3F4: ACE_Task_Base::activate(long, int, int, long, int, ACE_Task_Base*, unsigned long*, void**, unsigned long*, unsigned long*) (in /usr/lib/libACE.so.5.5.2) ==22571== by 0x40E028: MyProgram::init(ACE_Reactor*) (aaa.cpp:191) Definitely I clean both of them after my program finished. So what's the possible reason of the inconsistency? Can someone give me some ideas? The valgrind I used is valgrind-3.2.0-Debian and the platform/OS are x86_64, Debian-Linux 2.6.16-2-em64t-p4-smp. Thanks a lot! |
|
From: Julian S. <js...@ac...> - 2006-10-15 01:45:30
|
This can has been known to happen before, typically if you are using high performance video drivers. Anyway I believe it is fixed in 3.2.1 so try that. J On Sunday 15 October 2006 02:36, Stephen Schaeffer wrote: > Hi all, > > I'm new to Valgrind, so please forgive any painful ignorance on my part. > > I'm trying to use Valgrind to debug a program, and it will generate all > the debug output then lock my laptop up to the point where I have to > reboot. There's no mouse motion, no Ctrl-Alt-Backspace or -Delete, no > switching virtual terminals, nothing. I haven't tried ssh'ing in from > another machine, but I'm guessing that if it's locked to this degree, > it's done for. > > I'm using Fedora Core 5, patched up as high as my repositories allow, > which means Valgrind 3.1.0-2. I also have valgrind-callgrind installed > (0.10.1-1.1) I've tried using the Valgrind interface through Kdevelop > and straight from the command line, and in either case I get the same > behavior. I've also tried uninstalling and reinstalling in case > something got corrupted somewhere, but nothing has worked for me. > > Is this an issue with a known work-around, or is this just me and my > configuration? I can give more info, but at this point I'm not sure what > is relevant. > > Thanks for any help. I know that Valgrind is a great tool, and I'd love > to use it, but I'd also like to not have to reboot every time I use it. > > Steph > > > ------------------------------------------------------------------------- > 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: Stephen S. <ste...@cc...> - 2006-10-15 01:37:14
|
Hi all, I'm new to Valgrind, so please forgive any painful ignorance on my part. I'm trying to use Valgrind to debug a program, and it will generate all the debug output then lock my laptop up to the point where I have to reboot. There's no mouse motion, no Ctrl-Alt-Backspace or -Delete, no switching virtual terminals, nothing. I haven't tried ssh'ing in from another machine, but I'm guessing that if it's locked to this degree, it's done for. I'm using Fedora Core 5, patched up as high as my repositories allow, which means Valgrind 3.1.0-2. I also have valgrind-callgrind installed (0.10.1-1.1) I've tried using the Valgrind interface through Kdevelop and straight from the command line, and in either case I get the same behavior. I've also tried uninstalling and reinstalling in case something got corrupted somewhere, but nothing has worked for me. Is this an issue with a known work-around, or is this just me and my configuration? I can give more info, but at this point I'm not sure what is relevant. Thanks for any help. I know that Valgrind is a great tool, and I'd love to use it, but I'd also like to not have to reboot every time I use it. Steph |
|
From: Chris J. <ch...@bu...> - 2006-10-14 11:35:00
|
Hello, I've been successfully been using valgrind for a long time now for finding memory leaks and profiling my application. Now I would like to use valgrind to produce a computer and run independant method of measuring the run-time of my application. Cachegrind dumps number of instructions used, number of cache misses/etc. I'm sure this is a FAQ (maybe it should be added to the FAQs?) but is there an accepted best way to get a computer independant measure of "run-time" from the various numbers which are outputted? Chris |
|
From: Bryan O'S. <bo...@se...> - 2006-10-13 18:56:07
|
Josef Weidendorfer quoted Nick: >> I'm not aware of any easy solution. I don't think anyone has ever really >> got UML and Valgrind working together properly. I've heard that some kernel >> developers test with Valgrind by pulling out large chunks of kernel code >> into user-space test harnesses. This is doable, but quite painful in my experience. > Using VMWare could be more promising, as this is a hosted VM, ie. a > real linux user level process. Try Qemu instead, since it can be quite a bit more easily modified. <b |
|
From: Josef W. <Jos...@gm...> - 2006-10-13 13:16:31
|
On Friday 13 October 2006 00:46, Nicholas Nethercote wrote: > On Thu, 12 Oct 2006, Jim Cromie wrote: > > > Are UML or Xen my best bet for getting some cachegrind data on a kernel > > driver ? > > or is there another way I havent thought of ? > > I'm not aware of any easy solution. I don't think anyone has ever really > got UML and Valgrind working together properly. I've heard that some kernel > developers test with Valgrind by pulling out large chunks of kernel code > into user-space test harnesses. Seems to be the best route. Xen is out of question, as guests directly run on the Xen hypervisor, and their is no way to control/observe such a guest from a user process inside of another guest (even from domain 0). Using VMWare could be more promising, as this is a hosted VM, ie. a real linux user level process. However, VMWare obviously uses similar code rewriting/JIT techniques as Valgrind itself (ie. similar complex as running Valgrind self-hosting); additional, VMWare is a binary blob. And to get useful profiling results out of it, there would need to be some debug info redirection to make VMWares JITter transparently - so probably also a no-go. Josef PS: VG client requests to provide debug info redirection for post processing would be interesting: Think about a Java VM, and cachegrind directly could annotate Java code. |
|
From: <val...@ya...> - 2006-10-13 12:50:42
|
<HTML> <BODY> <HTML><BODY>Jack Rabbit Vibrator Sex Toy <BR><BR> <a href=http://plakomnaro.info/toys/> <acl></acl>TRY <acq></acq>NOW!!!</a></b><BR> Girls if you l0ve your <acz></acz>boy <aci></aci>you need to <acr></acr>try it;) <p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p> <p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p> <p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p> <p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p> <p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p> <p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p> <p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p> <p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p> <p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p> <BR>-----------------------------------------------------------<BR>I went often to look at <acl></acl>the collection of curiosities <acw></acw> in HeidelbergCastle, and one day I surprised the keeper <aco></aco>of it with my German. I spokeentirely in that language. He was greatly interested; <acl></acl>and after I had talked Still, those years with his sister, filled <acu></acu>with labor <acp></acp>beyond his age <acg></acg>as <ace></ace>they were, had been the happiest of <aco></aco>his life. In an <acd></acd>almost complete isolation the two had toiled together five <acu></acu>years, the most impressionable of his life; and all his affection <acx></acx>centred <aca></aca>on the silent, loving, always comprehending <acd></acd>sister. His <acm></acm>own father <acd></acd>and mother grew to seem far away and alien, and his sister came to <aca></aca>be like a part of himself. To her alone of all <acq></acq>living souls <acx></acx>had he spoken freely of his passion for adventuring far from home, of the <acx></acx>lust for wandering <acz></acz>which devoured his <acv></acv>boy-soul. He was sixteen when her husband finally came back from the war, and he had no secrets <acb></acb>from the young matron of twenty-six, who listened with such wide tender eyes of <acm></acm>sympathy to his half-frantic outpourings of longing to escape from the <acu></acu>dark, narrow valley where his fathers had lived their dark, narrow lives. has gone to <ace></ace>a better Land; all that <acc></acc>is left of it for its loved <acr></acr>Ones tolament over, is this poor smoldering Ash-heap. Ah, woeful, woeful Ash-heap!Let us take him up tenderly, reverently, upon the <aci></aci>lowly Shovel, and <acx></acx>bear himto his long Rest, with the <aci></aci> Prayer that when he rises again it <aca></aca>will <acc></acc>be aRealm where he will have one good square responsible Sex, and have it all toimself, <acz></acz>instead <ach></ach>of having a mangy lot of assorted Sexes scattered all <acq></acq>overhim in Spots. The congregation responded <aci></aci>in a timid inarticulate gabble, above which rose Deacon Bradleys loud <acw></acw>voice, -- Our soul <acp></acp>is escaped even as a bird out of the snare of the <acv></acv>fowler. The snare is broken and we are <act></act>escaped. He read the responses in a slow, booming roar, at <acj></acj>least half a sentence <ack></ack>behind <acw></acw>the rest, but the minister always waited for him. <acf></acf>As he finished, he <acg></acg>saw the sexton standing in the open <ace></ace>door. A little <acr></acr>more steam, Jehiel, he added commandingly, running the words on <acu></acu>to the end of the text. stumbled through the dark, unfinished part of the cellar he thought to himself, Well, thats the last time hell give me <acn></acn>an <acn></acn>order for one while! </BODY></HTML> </BODY> </HTML> <acj></acj> |
|
From: Nicholas N. <nj...@cs...> - 2006-10-12 22:46:35
|
On Thu, 12 Oct 2006, Jim Cromie wrote: > Are UML or Xen my best bet for getting some cachegrind data on a kernel > driver ? > or is there another way I havent thought of ? I'm not aware of any easy solution. I don't think anyone has ever really got UML and Valgrind working together properly. I've heard that some kernel developers test with Valgrind by pulling out large chunks of kernel code into user-space test harnesses. Nick |