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
(3) |
|
2
(1) |
3
(1) |
4
(2) |
5
(5) |
6
(4) |
7
(4) |
8
(6) |
|
9
|
10
(3) |
11
(6) |
12
(3) |
13
(2) |
14
(2) |
15
|
|
16
|
17
(7) |
18
(2) |
19
(15) |
20
(9) |
21
(5) |
22
(3) |
|
23
(5) |
24
(3) |
25
(3) |
26
(4) |
27
(5) |
28
(16) |
29
(7) |
|
30
|
31
(5) |
|
|
|
|
|
|
From: Alex B. <ker...@be...> - 2006-07-11 13:47:44
|
Hi,
So it came to pass I started looking at a couple of the errors thrown up
by valgrind. This one made me blink:
==16647== Conditional jump or move depends on uninitialised value(s)
==16647== at 0x700F1C29: MyClass::branchI(long, ConditionCode, bool)
(MyClass.cc:1917)
Looking at the code it referenced:
// Decide if we're going to take the branch
bool takeBranch = sic->createIccCondition(cond);
if(takeBranch)
{
As I've got a lot of trust in valgrind these days I didn't dismiss it as
impossible. The reason of course is the un-initialised value is
propagating from sic->createIccCondition(cond). I've been going around
back down the line to places where the variables are set and adding:
if (a)
{
magicValgrindValue = 0;
} else {
magicValgrindValue = 1;
}
To try and figure out how the value became initialised. However this is
quite tedious work. Does valgrind know this information anayway? Is
there anyway to get it to tell me where the value was reset to its
initialised state from?
--
Alex, homepage: http://www.bennee.com/~alex/
A great nation is any mob of people which produces at least one honest
man a century.
|
|
From: Tom H. <to...@co...> - 2006-07-10 19:28:28
|
In message <115...@ok...>
Alex Bennee <ker...@be...> wrote:
> I'm testing a multi-threaded app although the second thread is just a
> background listening thread. Semi-redacted the subject was at:
>
> Thread 1: status = VgTs_Runnable
> ==31252== at 0x4104F57: operator new(unsigned long)
> (vg_replace_malloc.c:167)
>
> And
>
> Thread 2: status = VgTs_WaitSys
> ==31252== at 0x3B73EBC6B2: poll (in /lib64/tls/libc-2.3.4.so)
>
> And the error that got dumped:
>
> ==31252== Address 0x4361678 is not stack'd, malloc'd or (recently)
> free'd
> --31252-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11
> (SIGSEGV) - exiting
> --31252-- si_code=1; Faulting address: 0x0; sp: 0x4032AEE00
>
> valgrind: the 'impossible' happened:
> Killed by fatal signal
> ==31252== at 0x380218A7: unlinkBlock (m_mallocfree.c:189)
> ==31252== by 0x38021EB3: vgPlain_arena_malloc (m_mallocfree.c:1055)
> ==31252== by 0x38037A9A: vgPlain_cli_malloc
> (replacemalloc_core.c:101)
> ==31252== by 0x380015DC: vgMemCheck___builtin_new
> (mc_malloc_wrappers.c:182)
> ==31252== by 0x38039B9E: do_client_request (scheduler.c:1158)
> ==31252== by 0x38039453: vgPlain_scheduler (scheduler.c:869)
> ==31252== by 0x3804CD6E: thread_wrapper (syswrap-linux.c:87)
> ==31252== by 0x3804CE65: run_a_thread_NORETURN (syswrap-linux.c:120)
>
> Need any more information?
This is almost certainly caused by your program corrupting the heap
data structure by writing past the end of an allocated block.
Fix the errors valgrind has already reported (especially any invalid
write errors) and see if it still happens after that.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Alex B. <ker...@be...> - 2006-07-10 18:21:35
|
Hi, I'm testing a multi-threaded app although the second thread is just a background listening thread. Semi-redacted the subject was at: Thread 1: status = VgTs_Runnable ==31252== at 0x4104F57: operator new(unsigned long) (vg_replace_malloc.c:167) And Thread 2: status = VgTs_WaitSys ==31252== at 0x3B73EBC6B2: poll (in /lib64/tls/libc-2.3.4.so) And the error that got dumped: ==31252== Address 0x4361678 is not stack'd, malloc'd or (recently) free'd --31252-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --31252-- si_code=1; Faulting address: 0x0; sp: 0x4032AEE00 valgrind: the 'impossible' happened: Killed by fatal signal ==31252== at 0x380218A7: unlinkBlock (m_mallocfree.c:189) ==31252== by 0x38021EB3: vgPlain_arena_malloc (m_mallocfree.c:1055) ==31252== by 0x38037A9A: vgPlain_cli_malloc (replacemalloc_core.c:101) ==31252== by 0x380015DC: vgMemCheck___builtin_new (mc_malloc_wrappers.c:182) ==31252== by 0x38039B9E: do_client_request (scheduler.c:1158) ==31252== by 0x38039453: vgPlain_scheduler (scheduler.c:869) ==31252== by 0x3804CD6E: thread_wrapper (syswrap-linux.c:87) ==31252== by 0x3804CE65: run_a_thread_NORETURN (syswrap-linux.c:120) Need any more information? -- Alex, homepage: http://www.bennee.com/~alex/ Alden's Laws: (1) Giving away baby clothes and furniture is the major cause of pregnancy. (2) Always be backlit. (3) Sit down whenever possible. |
|
From: Alex B. <ker...@be...> - 2006-07-10 08:58:29
|
On Sat, 2006-07-08 at 18:14 +1000, Nicholas Nethercote wrote:
> On Sat, 8 Jul 2006, Alex Bennee wrote:
>
> > I've been trying to track down some failures in my program when compiled
> > with -O0 (it's normally compiled -O3 however I like to be able to run
> > -O0 for debugging). I have found problems before with some inlined asm
> > routines before which when not inlined in -O0 don't reserve stack space.
> <snip>
>
> Maybe you can give some more specific detail? I can't tell from your
> description above what it is you want Valgrind to detect.
>
> Nick
Well here is an segment of example of code that failed before I added a
special sub for -O0 builds.
void MyClass::setIfCondition_Zero(uint8_t &condStatus, uint64_t eflags)
{
__asm__ volatile
(
#ifdef OPTIMIZE
#if OPTIMIZE==0
"sub $0x10, %%rsp\n\t"
#endif
#endif
"pushf \n\t"
"push %1 \n\t"
"popf \n\t"
"setz %0 \n\t"
"popf \n\t"
: "=r"(condStatus): "r"(eflags));
}
void MyClass::decodeJumpCC(uint8_t parameter)
{
//lets read our current eflags register
uint64_t intFlags=getEFLAGSValue();
uint8_t doBranch=0;
switch(parameter)
{
// Zero (or not)
case CONDITION_NZ:
inverse=true;
case CONDITION_Z:
setIfCondition_Zero(doSet,intFlags);
break;
...
...
}
In the normal case (-O3) the setIfConditionZero function gets inlined in
the decodeJumpCC code and the pushf/popf gets away with it
because ::decodeJumpCC has a normal stack frame reserved by the compiler
with space for this sort of thing. However in the -O0 case the compiler
won't reserve any space in setIfConditionZero() as it has no local
variables of its own. In this case (after a lot of head scratching) we
fixed it by adding a stack sub to add space for the push/pop operation.
RSP then gets cleaned up by the normal function prolog.
I'm sure there are other cases where we use inline assembler which
doesn't take these sort of stack related things into account. These are
the sort of things it would be useful for Valgrind to detect.
--
Alex, homepage: http://www.bennee.com/~alex/
What I tell you three times is true.
|
|
From: John R.
|
Tom Hughes wrote: > The problem with that is that trapping returns is in general very hard. But a "solution" with 99+% theoretical coverage (such as, omitting coverage for a hand-written return which uses "pop %ecx; ...; jmp *%ecx" instead of 'ret', but covering all cases of actual 'ret') still will be enormously valuable to users. It's an optional mode where the intermediate code for 'ret' is always "call a subroutine and figure it out." Yes, such a 'ret' will be 20x as expensive as before, but it will still be thousands of times faster than the user scratching his head, wondering which piece of code overwrote the return address. And, emphasizing an implicit point in my previous post, the error report: ----- ==3989== Jump to the invalid address stated on the next line ==3989== at 0x0: ??? ==3989== by 0x544D7E: (below main) (in /lib/libc-2.3.6.so) ==3989== Address 0x0 is not stack'd, malloc'd or (recently) free'd ----- is almost useless because it omits the PC _before_ the jump/ret, which is the most important piece of information the user wants to know. Being very explicit, the report should have read something like: ----- ==3989== Jump to the invalid address stated on the next line ==3989== at 0x0: ??? ==3989== by 0x8048377: smash+7 ==3989== by 0x544D7E: (below main) (in /lib/libc-2.3.6.so) ==3989== Address 0x0 is not stack'd, malloc'd or (recently) free'd ----- where the "0x8048377: smash+7" is _essential_. Again, the mechanism is obvious: keep one variable [per thread] which remembers the PC of any instruction which could cause a non-sequential transfer of control (or at least, a transfer to an address that is not statically known.) Put the current value of that variable into every traceback, or at least the ones for "Jump to invalid address." -- |
|
From: Tom H. <to...@co...> - 2006-07-08 16:04:38
|
In message <44AFCD99.5040008@BitWagon.com>
John Reiser <jreiser@BitWagon.com> wrote:
> Nicholas Nethercote wrote:
> > On Sat, 8 Jul 2006, Alex Bennee wrote:
>
> >> I have found problems before with some inlined asm
> >>routines before which when not inlined in -O0 don't reserve stack space.
>
> > Maybe you can give some more specific detail? I can't tell from your
> > description above what it is you want Valgrind to detect.
>
> For instance on x86, there should be an option to detect when
> a return address (the word pushed onto the stack by any CALL instruction)
> gets written before it is POP'ed. Similarly for clobbering a
> frame pointer (the word pushed onto the stack by the sequence
> "pushl %ebp; movl %esp,%ebp"). And possibly also for saved registers
> (%ebx, %esi, %edi) that are pushed in a stylized way during subroutine
> prolog; but this last piece might be problematic because various compilers
> do it differently (before or after allocating space for local automatic
> variables, for instance.) The mechanism is obvious: mark these locations
> on the stack as "read-only"; and if there is no such state, then mark
> them as "not written" (or even "not allocated"), with a special-case
> in the trap so that there is no complaint upon reading, which will happen
> exactly once per frame.
The problem, as you seem to have deduced, is that valgrind (or rather
memcheck) has no concept of read only memory. Only addressable and/or
defined memory.
One option is to mark it as inaccessible (ie effectively not allocated) and
then restore that to the defined state before the return. I think that is
the solution my colleage used when he played with doing this in valgrind. The
problem with that is that trapping returns is in general very hard.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: John R.
|
Nicholas Nethercote wrote:
> On Sat, 8 Jul 2006, Alex Bennee wrote:
>> I have found problems before with some inlined asm
>>routines before which when not inlined in -O0 don't reserve stack space.
> Maybe you can give some more specific detail? I can't tell from your
> description above what it is you want Valgrind to detect.
For instance on x86, there should be an option to detect when
a return address (the word pushed onto the stack by any CALL instruction)
gets written before it is POP'ed. Similarly for clobbering a
frame pointer (the word pushed onto the stack by the sequence
"pushl %ebp; movl %esp,%ebp"). And possibly also for saved registers
(%ebx, %esi, %edi) that are pushed in a stylized way during subroutine
prolog; but this last piece might be problematic because various compilers
do it differently (before or after allocating space for local automatic
variables, for instance.) The mechanism is obvious: mark these locations
on the stack as "read-only"; and if there is no such state, then mark
them as "not written" (or even "not allocated"), with a special-case
in the trap so that there is no complaint upon reading, which will happen
exactly once per frame.
Example:
-----main.c
main()
{
smash();
return 0;
}
-----smash.S
smash: .globl smash
movl $0,(%esp) # clobbers the return address
ret
-----
$ gcc main.c smash.S
$ valgrrind ./a.out
. . .
==3989== Using valgrind-3.2.0, a dynamic binary instrumentation framework.
. . .
==3989== Jump to the invalid address stated on the next line
==3989== at 0x0: ???
==3989== by 0x544D7E: (below main) (in /lib/libc-2.3.6.so)
==3989== Address 0x0 is not stack'd, malloc'd or (recently) free'd
-----
In the above example, valgrind-3.2.0 tells you too late, only after the 'ret'
has been performed, and valgrind does not tell you the PC of the 'ret',
which is the most useful piece of information at this point.
Instead, valgrind should tell you that you are clobbering
a "reserved stack location" as soon as you execute the "movl $0,(%esp)",
and the error report should include the PC of the 'movl'.
Then the user has some real information to find the bug.
--
|
|
From: Nicholas N. <nj...@cs...> - 2006-07-08 08:14:45
|
On Sat, 8 Jul 2006, Alex Bennee wrote: > I've been trying to track down some failures in my program when compiled > with -O0 (it's normally compiled -O3 however I like to be able to run > -O0 for debugging). I have found problems before with some inlined asm > routines before which when not inlined in -O0 don't reserve stack space. > I've got several test cases to test the code so it would be nice if > Valgrind could point me at the functions that break things. > > Is this something Valgrind can detect on its own or do I need to > recompile the program with additional instrumentation? > > The basic memcheck run didn't seem to come up with anything. Maybe you can give some more specific detail? I can't tell from your description above what it is you want Valgrind to detect. Nick |
|
From: Alex B. <ker...@be...> - 2006-07-08 08:02:37
|
Hi, I've been trying to track down some failures in my program when compiled with -O0 (it's normally compiled -O3 however I like to be able to run -O0 for debugging). I have found problems before with some inlined asm routines before which when not inlined in -O0 don't reserve stack space. I've got several test cases to test the code so it would be nice if Valgrind could point me at the functions that break things. Is this something Valgrind can detect on its own or do I need to recompile the program with additional instrumentation? The basic memcheck run didn't seem to come up with anything. -- Alex, homepage: http://www.bennee.com/~alex/ ... I don't know why but, suddenly, I want to discuss declining I.Q. LEVELS with a blue ribbon SENATE SUB-COMMITTEE! |
|
From: Patrick O. <pat...@in...> - 2006-07-07 12:10:54
|
On Fri, 2006-07-07 at 10:41 +0000, Oleksandr K. wrote: > Julian Seward <jseward <at> acm.org> writes: > > As a result of recent memcheck hackery in the 3.0 line, I broke > > support for the VALGRIND_SET_VBITS and VALGRIND_GET_VBITS > > client requests. I haven't fixed them; instead I am hoping to > > get rid of them altogether. They were introduced as an experimental > > hack, and as far as I know nobody ever used them. > > > > So my question is: does anybody use these? > > > > If you haven't a clue what this is about, it's a pretty safe bet > > you don't use them. > > > > Hi, > > I do need the GET/SET VBITS requests! They are supported again since at least 3.2.0. Just beware that the client request mechanism has changed and therefore you have to use the header files from that valgrind version to use the new requests. -- 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: Oleksandr K. <ti...@gm...> - 2006-07-07 10:45:07
|
Julian Seward <jseward <at> acm.org> writes: > > > All, > > As a result of recent memcheck hackery in the 3.0 line, I broke > support for the VALGRIND_SET_VBITS and VALGRIND_GET_VBITS > client requests. I haven't fixed them; instead I am hoping to > get rid of them altogether. They were introduced as an experimental > hack, and as far as I know nobody ever used them. > > So my question is: does anybody use these? > > If you haven't a clue what this is about, it's a pretty safe bet > you don't use them. > Hi, I do need the GET/SET VBITS requests! The case is when one implements virtual memory-like system in which memory contents may be offloaded from RAM even if memory page's contents is only partially defined (and the page is dirty already). It is actually for "memory buffer" of a database management system (for non- standard embedded environment). All data is processed in one region of memory where memory pages loaded and offloaded from/to disk. The pattern to use is: GET_VBITS(...); // save vbits state MAKE_READABLE(page, page_size); // prevent complaints when page data is writen to file MemoryBuffer::SavePage(page, ..); // save(flush) page - it stays in memory SET_VBITS(...); // restore It becomes even worse, if there is a need to preserve VBITS for completely offloaded pages. Then, in debug builds VBITS must be stored along with memory pages' data in file system and restored when page is brought back into the memory buffer! - Oleksandr |
|
From: Tom H. <to...@co...> - 2006-07-07 07:21:28
|
In message <200...@cl...>
Jeff Head <hj...@cl...> wrote:
> This is the first time I've used valgrind, so I'm a little lost by this error.
> My guess is this is an internal assertion failure since I don't recognize
> this resource, but here is what I get:
>
> ***************** Start Valgrind Output *****************
>
> ==11383== Memcheck, a memory error detector.
> ==11383== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
> ==11383== Using LibVEX rev 1471, a library for dynamic binary translation.
> ==11383== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
> ==11383== Using valgrind-3.1.0, a dynamic binary instrumentation framework.
> ==11383== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
> ==11383== For more details, rerun with: -v
> ==11383==
> depth: 24
>
> ** (process:11383): CRITICAL **: ws_window_redirect_subwindows: assertion
> `WS_RESOURCE (window)->display->composite.available' failed
>
> ** ERROR **: Display and XID must be specified when creating a resource
> aborting...
That isn't an assertion in valgrind at all, it's an assertion in your
program (or a library that it uses).
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeff H. <hj...@cl...> - 2006-07-07 06:31:09
|
This is the first time I've used valgrind, so I'm a little lost by this error. My guess is this is an internal assertion failure since I don't recognize this resource, but here is what I get: ***************** Start Valgrind Output ***************** ==11383== Memcheck, a memory error detector. ==11383== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==11383== Using LibVEX rev 1471, a library for dynamic binary translation. ==11383== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==11383== Using valgrind-3.1.0, a dynamic binary instrumentation framework. ==11383== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==11383== For more details, rerun with: -v ==11383== depth: 24 ** (process:11383): CRITICAL **: ws_window_redirect_subwindows: assertion `WS_RESOURCE (window)->display->composite.available' failed ** ERROR **: Display and XID must be specified when creating a resource aborting... ==11383== ==11383== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 35 from 1) ==11383== malloc/free: in use at exit: 1,175,860 bytes in 673 blocks. ==11383== malloc/free: 1,600 allocs, 927 frees, 1,586,439 bytes allocated. ==11383== For counts of detected errors, rerun with: -v ==11383== searching for pointers to 673 not-freed blocks. ==11383== checked 1,414,544 bytes. ==11383== ==11383== 400 bytes in 1 blocks are definitely lost in loss record 29 of 46 ==11383== at 0x40051F9: malloc (vg_replace_malloc.c:149) ==11383== by 0x6141A1: XGetVisualInfo (in /usr/lib/libX11.so.6.2.0) ==11383== by 0x721EC54: glXChooseVisual (in /usr/lib/libGL.so.1.0.8756) ==11383== by 0x4F: ??? ==11383== ==11383== ==11383== 800 bytes in 20 blocks are possibly lost in loss record 30 of 46 ==11383== at 0x40045EB: calloc (vg_replace_malloc.c:279) ==11383== by 0x9A369D: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1000.3) ==11383== by 0xA2B90F: (within /usr/lib/libgobject-2.0.so.0.1000.3) ==11383== by 0xA2BAA4: (within /usr/lib/libgobject-2.0.so.0.1000.3) ==11383== by 0xA2C08C: g_type_init_with_debug_flags (in /usr/lib/libgobject-2.0.so.0.1000.3) ==11383== by 0xA2C1F1: g_type_init (in /usr/lib/libgobject-2.0.so.0.1000.3) ==11383== by 0x8048F78: (within /usr/bin/scenetest) ==11383== by 0x474723: __libc_start_main (in /lib/libc-2.4.so) ==11383== ==11383== ==11383== 10,360 bytes in 17 blocks are possibly lost in loss record 39 of 46 ==11383== at 0x40044B3: memalign (vg_replace_malloc.c:332) ==11383== by 0x4004509: posix_memalign (vg_replace_malloc.c:384) ==11383== by 0x9B25C8: (within /usr/lib/libglib-2.0.so.0.1000.3) ==11383== by 0x9B3003: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1000.3) ==11383== by 0x9B3154: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.1000.3) ==11383== by 0xA33279: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.1000.3) ==11383== by 0xA1B011: (within /usr/lib/libgobject-2.0.so.0.1000.3) ==11383== by 0xA18E69: g_object_newv (in /usr/lib/libgobject-2.0.so.0.1000.3) ==11383== by 0xA1993E: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.1000.3) ==11383== by 0xA19AEF: g_object_new (in /usr/lib/libgobject-2.0.so.0.1000.3) ==11383== by 0x7001A5: ws_display_new (in /usr/lib/libcm.so.7.0.0) ==11383== by 0x8048F9B: (within /usr/bin/scenetest) ==11383== ==11383== LEAK SUMMARY: ==11383== definitely lost: 400 bytes in 1 blocks. ==11383== possibly lost: 11,160 bytes in 37 blocks. ==11383== still reachable: 1,164,300 bytes in 635 blocks. ==11383== suppressed: 0 bytes in 0 blocks. ==11383== Reachable blocks (those to which a pointer was found) are not shown. ==11383== To see them, rerun with: --show-reachable=yes ****************** End Valgrind Output ****************** Any help interpreting this error would be greatly appreciated. Jeff Head hj...@cl... |
|
From: Eric L. <ew...@an...> - 2006-07-06 20:32:26
|
What does the Binary IOp DivModU64to32 do? The inline comments in the source say (I64, I32) -> I64. I interpreted it as arg1 is 64-bit dividend, arg2 is 32-bit divisor, result is 64 bits of which high 32 bits is arg1 mod arg2 and low 32 bits is arg1 div arg2. But arg1 div arg2 could be more than 32 bits so how can it fit in only the low 32 bits? Thanks, Eric |
|
From: Tom H. <to...@co...> - 2006-07-06 07:39:47
|
In message <209...@ha...>
Evgenia Abramov <evg...@in...> wrote:
> On one of our test application Valgrind fails just on the start with the
> following error message:
>
>> /p/dt/sde/tools/i386_linux26/valgrind-3.2.0/bin/valgrind -v
> --trace-children=yes --leak-check=full --leak-resolution=high
> --show-reachable=yes --num-callers=50
> /p/dt/ccrel/OUT_AREA/lvt/lvt_t2_06/lvt_t2_06a/tacsi/i386_linux26/Lst/api
> Test
>
> valgrind:
> /p/dt/ccrel/OUT_AREA/lvt/lvt_t2_06/lvt_t2_06a/tacsi/i386_linux26/Lst/api
> Test: Value too large for defined data type
I suspect this is another version of the stat/stat64 problem I just
fixed for you.
Is that literally all the output you get?
Does it fail the same way if you run it from local disk?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2006-07-06 07:39:47
|
In message <209...@ha...>
Evgenia Abramov <evg...@in...> wrote:
> On one of our test application Valgrind fails just on the start with the
> following error message:
>
>> /p/dt/sde/tools/i386_linux26/valgrind-3.2.0/bin/valgrind -v
> --trace-children=yes --leak-check=full --leak-resolution=high
> --show-reachable=yes --num-callers=50
> /p/dt/ccrel/OUT_AREA/lvt/lvt_t2_06/lvt_t2_06a/tacsi/i386_linux26/Lst/api
> Test
>
> valgrind:
> /p/dt/ccrel/OUT_AREA/lvt/lvt_t2_06/lvt_t2_06a/tacsi/i386_linux26/Lst/api
> Test: Value too large for defined data type
I suspect this is another version of the stat/stat64 problem I just
fixed for you.
Is that literally all the output you get?
Does it fail the same way if you run it from local disk?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Abramov, E. <evg...@in...> - 2006-07-06 07:31:42
|
Hi, =20 On one of our test application Valgrind fails just on the start with the following error message: > /p/dt/sde/tools/i386_linux26/valgrind-3.2.0/bin/valgrind -v --trace-children=3Dyes --leak-check=3Dfull --leak-resolution=3Dhigh --show-reachable=3Dyes --num-callers=3D50 /p/dt/ccrel/OUT_AREA/lvt/lvt_t2_06/lvt_t2_06a/tacsi/i386_linux26/Lst/api Test valgrind: /p/dt/ccrel/OUT_AREA/lvt/lvt_t2_06/lvt_t2_06a/tacsi/i386_linux26/Lst/api Test: Value too large for defined data type =20 > file /p/dt/ccrel/OUT_AREA/lvt/lvt_t2_06/lvt_t2_06a/tacsi/i386_linux26/Lst/api Test /p/dt/ccrel/OUT_AREA/lvt/lvt_t2_06/lvt_t2_06a/tacsi/i386_linux26/Lst/api Test: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped =20 The previous valgring version 3.1.0 also fails. =20 What is wrong here? =20 Thanks, Genia =20 |
|
From: franchouze <f_c...@ya...> - 2006-07-05 15:34:30
|
You were right. Thanks a lot. Francois -- View this message in context: http://www.nabble.com/valgrind-error-%3A--Can%27t-create-log-file--solved--tf1894805.html#a5183969 Sent from the Valgrind - Users forum at Nabble.com. |
|
From: Julian S. <js...@ac...> - 2006-07-05 14:21:24
|
Your program changes working directory and then does fork/exec. The child valgrind cannot write a log file in the new directory. You can get round this by giving a fully qualified file name to --log-file=. J On Wednesday 05 July 2006 14:47, franchouze wrote: > Hi > > Here is my valgrind command line : > valgrind --tool=memcheck --trace-children=yes --track-fds=yes > --leak-check=full --show-reachable=yes --log-file=debug --num-callers=16 > prog/args > > the program runs normally and create logfiles and then I got a core dumped > and this message : > > ==10940== Can't create log file 'debug.10940' (Permission denied); giving > up! > valgrind: Bad option '--log-file=<file> (didn't work out for some > reason.)'; aborting. > valgrind: Use --help for more information. > ==10941== Can't create log file 'debug.10941' (Permission denied); giving > up! > valgrind: Bad option '--log-file=<file> (didn't work out for some > reason.)'; aborting. > valgrind: Use --help for more information. > > I still have space on the hard drive and I have rights to write in the > current directory (valgrind wrote some logfiles). > > Anyone has got an idea about the "some reason" that crashed the program ? > > Thanks for your help > > Fran?ois |
|
From: franchouze <f_c...@ya...> - 2006-07-05 14:05:07
|
Hi Here is my valgrind command line : valgrind --tool=memcheck --trace-children=yes --track-fds=yes --leak-check=full --show-reachable=yes --log-file=debug --num-callers=16 prog/args the program runs normally and create logfiles and then I got a core dumped and this message : ==10940== Can't create log file 'debug.10940' (Permission denied); giving up! valgrind: Bad option '--log-file=<file> (didn't work out for some reason.)'; aborting. valgrind: Use --help for more information. ==10941== Can't create log file 'debug.10941' (Permission denied); giving up! valgrind: Bad option '--log-file=<file> (didn't work out for some reason.)'; aborting. valgrind: Use --help for more information. I still have space on the hard drive and I have rights to write in the current directory (valgrind wrote some logfiles). Anyone has got an idea about the "some reason" that crashed the program ? Thanks for your help Fran?ois -- View this message in context: http://www.nabble.com/valgrind-error-%3A--Can%27t-create-log-file-tf1894805.html#a5181944 Sent from the Valgrind - Users forum at Nabble.com. |
|
From: Olly B. <ol...@su...> - 2006-07-05 11:35:14
|
On 2006-07-05, Thomas Porschberg <tho...@os...> wrote: > is there any plans to port valgrind to the mingw/msys environment ? See: http://www.valgrind.org/info/platforms.html Which says: In particular Windows is not under consideration here because porting to it would require so many changes it would almost be a separate project. Also, non-open-source OSes are difficult to deal with; being able to see the OS and associated (libc) source code makes things much easier. And mingw is essentially just a very thin wrapper around the MS libc DLL. Perhaps the FAQ should have an entry for "Are you planning to port to Windows?" refering the the reader to platforms.html? Cheers, Olly |
|
From: Thomas P. <tho...@os...> - 2006-07-05 05:20:14
|
Hi, is there any plans to port valgrind to the mingw/msys environment ? Cheers, Thomas -- |
|
From: Christian L. <chr...@le...> - 2006-07-04 18:30:59
|
On Tue, Jul 04, 2006 at 05:51:14AM -0700, Rana Chawla wrote: > I have been unsuccessful in trying to build and install Valgrind on > PowerPC running Linux. > > The ./configure command runs fine, and executes config.status at the end. > The make command, however, continues to run config.status in an infinite > loop. This "bugreport" is useless, it doesn't contain the exact version, the circumstances or output. I think your build system is seriously screwed up, for example the question is if building other normal programms that make use of autoconf and automake is working. (try to compile gmp, whatever) It's really unlikely that this is a valgrind bug. Is this probably some odd simulator with jumping time or some other fancy stuff? Regards Christian Leber -- "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." (Aurelius Augustinus) Translation: <http://gnuhh.org/work/fsf-europe/augustinus.html> |
|
From: Rana C. <mch...@ya...> - 2006-07-04 12:51:23
|
Hi All, I have been unsuccessful in trying to build and install Valgrind on PowerPC running Linux. The ./configure command runs fine, and executes config.status at the end. The make command, however, continues to run config.status in an infinite loop. Help is required urgently on this problem! Thanks and regards, Rana --------------------------------- Want to be your own boss? Learn how on Yahoo! Small Business. |
|
From: Dennis L. <pla...@pr...> - 2006-07-03 11:09:11
|
Am Mittwoch, den 28.06.2006, 22:55 +0100 schrieb Tom Hughes: > In message <e05...@jp...> > Catherine Moroney <Cat...@jp...> wrote: > That constant (in coregrind/m_aspacemgr/aspacemgr.c) controls the > size of the array used to hold details of each chunk of memory that > is mapped into the process address space. > > Unfortunately making that table dynamically sized introduces a > circular problem of having to allocate memory in order to record > what memory is allocated, so it has to be kept as a fixed size > table. Just a rough guess without knowing what Im talking about: could you maybe have a small fixed table, use it in the beginning and then start dynamically allocating it? greets Dennis |