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
(21) |
2
(16) |
3
(3) |
4
(8) |
5
(9) |
6
(9) |
|
7
(14) |
8
(16) |
9
(21) |
10
(39) |
11
(29) |
12
(23) |
13
(9) |
|
14
(5) |
15
(8) |
16
(17) |
17
(30) |
18
(8) |
19
(35) |
20
(2) |
|
21
|
22
(2) |
23
(8) |
24
(15) |
25
(6) |
26
(20) |
27
(4) |
|
28
(1) |
29
(4) |
30
(8) |
31
(19) |
|
|
|
|
From: Paul P. <ppl...@gm...> - 2005-08-08 04:12:46
|
On 8/7/05, Christian Parpart <tr...@ge...> wrote: ... > having a look at that line 241 that caused the "invalid read of size 1", = I see my > code like this: >=20 > if (foo) Most likely 'foo' is an instance variable and 'this' is NULL. If not, you'll need to establish a bit more context. > okay, foo is the problem, but still... why is foo my problem here? is thi= s space > already freed as well? but if so, why didn't valgrind tell me? The space was not free()d. It was never allocated or valid (not on stack, not in heap, nowehere at all). Cheers, |
|
From: Christian P. <tr...@ge...> - 2005-08-08 04:00:18
|
hi, this message sounds pretty usual; in fact, I usually know how to fix those issues as valgrind *usually* tells= me,=20 that this happenED because I accessed some space within an already freed ra= nge; however, here it doesn't. instead, right after this message, it even SEGVAU= LTs: =3D=3D27549=3D=3D Thread 5: =3D=3D27549=3D=3D Invalid read of size 1 =3D=3D27549=3D=3D at 0x15601485A: System::IO::Unix::TPollMgr::TInterest:= :notify(System::IO::Unix::TPollMask) (TPollMgr.cpp:241) =3D=3D27549=3D=3D by 0x156014484: System::IO::Unix::TPollMgr::process(Sy= stem::IO::Unix::TPollMgr::TInterest&, System::IO::Unix::TPollMask) (TPollMg= r.cpp:219) =3D=3D27549=3D=3D by 0x1560143CC: System::IO::Unix::TPollMgr::processPen= ding() (TPollMgr.cpp:203) =3D=3D27549=3D=3D by 0x156014033: System::IO::Unix::TPollMgr::dispatchOn= ce(System::TTimeSpan) (TPollMgr.cpp:162) =3D=3D27549=3D=3D by 0x156013610: System::IO::Unix::TPollMgr::threadRun(= System::TVarData) (TPollMgr.cpp:64) =3D=3D27549=3D=3D by 0x156018124: System::TMemFunHandler<System::TFuncto= r<void, System::TTypeList<System::TVarData, System::NullType> >, System::IO= ::Unix::TPollMgr*, void (System::IO::Unix::TPollMgr::*)(System::TVarData)>:= :operator()(System::TVarData) (TFunctor.h:300) =3D=3D27549=3D=3D by 0x155F2881B: System::TFunctor<void, System::TTypeLi= st<System::TVarData, System::NullType> >::operator()(System::TVarData) cons= t (TFunctor.cc:38) =3D=3D27549=3D=3D by 0x155F482C6: startSimpleThread (TThread.cpp:337) =3D=3D27549=3D=3D by 0x157A2F119: start_thread (in /lib/libpthread-2.3.5= =2Eso) =3D=3D27549=3D=3D by 0x1588093E1: clone (in /lib/libc-2.3.5.so) =3D=3D27549=3D=3D Address 0x3C is not stack'd, malloc'd or (recently) free= 'd =3D=3D27549=3D=3D =3D=3D27549=3D=3D Process terminating with default action of signal 11 (SIG= SEGV): dumping core =3D=3D27549=3D=3D Access not within mapped region at address 0x3C =3D=3D27549=3D=3D at 0x15601485A: System::IO::Unix::TPollMgr::TInterest:= :notify(System::IO::Unix::TPollMask) (TPollMgr.cpp:241) =3D=3D27549=3D=3D by 0x156014484: System::IO::Unix::TPollMgr::process(Sy= stem::IO::Unix::TPollMgr::TInterest&, System::IO::Unix::TPollMask) (TPollMg= r.cpp:219) =3D=3D27549=3D=3D by 0x1560143CC: System::IO::Unix::TPollMgr::processPen= ding() (TPollMgr.cpp:203) =3D=3D27549=3D=3D by 0x156014033: System::IO::Unix::TPollMgr::dispatchOn= ce(System::TTimeSpan) (TPollMgr.cpp:162) =3D=3D27549=3D=3D by 0x156013610: System::IO::Unix::TPollMgr::threadRun(= System::TVarData) (TPollMgr.cpp:64) =3D=3D27549=3D=3D by 0x156018124: System::TMemFunHandler<System::TFuncto= r<void, System::TTypeList<System::TVarData, System::NullType> >, System::IO= ::Unix::TPollMgr*, void (System::IO::Unix::TPollMgr::*)(System::TVarData)>:= :operator()(System::TVarData) (TFunctor.h:300) =3D=3D27549=3D=3D by 0x155F2881B: System::TFunctor<void, System::TTypeLi= st<System::TVarData, System::NullType> >::operator()(System::TVarData) cons= t (TFunctor.cc:38) =3D=3D27549=3D=3D by 0x155F482C6: startSimpleThread (TThread.cpp:337) =3D=3D27549=3D=3D by 0x157A2F119: start_thread (in /lib/libpthread-2.3.5= =2Eso) =3D=3D27549=3D=3D by 0x1588093E1: clone (in /lib/libc-2.3.5.so) having a look at that line 241 that caused the "invalid read of size 1", I = see my code like this: if (foo) okay, foo is the problem, but still... why is foo my problem here? is this = space=20 already freed as well? but if so, why didn't valgrind tell me? Thanks in advance, Christian Parpart. =2D-=20 05:54:01 up 137 days, 19:01, 0 users, load average: 2.28, 2.14, 2.15 |
|
From: John R.
|
>>valgrind-3.0.0 crashes with SIGILL [illegal instruction] >>at startup on AMD Athlon ["plain"]. Apparently valgrind-3.0.0 >>assumes SSE x86 hardware ["ldmxcsr" instruction introduced with SSE]. >>So if "cat /proc/cpuinfo | grep flags" does not show "sse", >>then valgrind-3.0.0 will not work your CPU. >> >>http://bugs.kde.org/show_bug.cgi?id=110274 > Fixed (vex 1321, valgrind 4339). Please verify. Verified (vex 1321, valgrind 4340). Thank you. -- |
|
From: Julian S. <js...@ac...> - 2005-08-08 00:45:56
|
Fixed (vex 1321, valgrind 4339). Please verify. J On Saturday 06 August 2005 03:54, John Reiser wrote: > valgrind-3.0.0 crashes with SIGILL [illegal instruction] > at startup on AMD Athlon ["plain"]. Apparently valgrind-3.0.0 > assumes SSE x86 hardware ["ldmxcsr" instruction introduced with SSE]. > So if "cat /proc/cpuinfo | grep flags" does not show "sse", > then valgrind-3.0.0 will not work your CPU. > > http://bugs.kde.org/show_bug.cgi?id=110274 |
|
From: <Woe...@on...> - 2005-08-07 20:15:46
|
On Sunday 07 August 2005 18:23, Tom Hughes wrote: > > Your patch is only correct if VG_(printf) uses the same format > > characters as printf and with the exact same meaning. I'm not sure > > that is necessarily true as VG_(printf) uses it's own formatter > > so I would have to check if they do match fully. > > It looks like VG_(printf) is a superset of printf - the %t format > is extra and there are extra flags (command and open parenthesis). Is there another way to catch wrong format strings? Andr=E9 |
|
From: Julian S. <js...@ac...> - 2005-08-07 17:54:12
|
> > > > and everybody, more or less, has at least a Pentium-III or equivalent > > > > CPU anyway. > > > > > > that's quite a statement. it may be even true - in the western world > > > and possibly even globally in the professional sw devel world. > > > > Fair enough. Let's wait to see if this causes many complaints in > > practice. > > In my experience, if it comes up during the beta, it will *definitely* come > up in practice. I think Ossi's case is convincing -- requiring SSE means we exclude a potentially large set of under-represented users, which is obviously bad. I'll fix this later this evening. Not sure what you mean by beta though. This isn't a beta; 3.0.0 went live last Weds. J |
|
From: Avery P. <ape...@ni...> - 2005-08-07 17:43:28
|
On Sat, Aug 06, 2005 at 11:05:34AM +0100, Julian Seward wrote: > > > Correct. SSE1 is now a minimum requirement. Supporting non-SSE > > > variants is too much hassle > > > > uhm, what is the problem? > > It means everywhere where the host machine's sse state is messed > with, we now have to have a conditional branch around that code. > To be fair, this is fewer places with 3.0 than with 2.4.X. > It is certainly possible, just extra clutter and more code paths/ > variants to verify. You could do the trick that the openssl people do: modern versions of libc can load a different .so file depending on your processor attributes. So you could have one valgrind library that manipulates SSE state, and another that doesn't, and load the right one depending on the processor type. No runtime conditionals necessary. > > > and everybody, more or less, has at least a Pentium-III or equivalent > > > CPU anyway. > > > > that's quite a statement. it may be even true - in the western world and > > possibly even globally in the professional sw devel world. > > Fair enough. Let's wait to see if this causes many complaints in practice. In my experience, if it comes up during the beta, it will *definitely* come up in practice. Have fun, Avery |
|
From: Tom H. <to...@co...> - 2005-08-07 16:24:00
|
In message <470...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <200...@on...>
> André Wöbbeking <Woe...@on...> wrote:
>
> > now with 64 bit support shouldn't you check the format strings (see
> > attached patch, I'm sure there're more places) to avoid i.e.
> >
> > symtab.c: In function 'read_symtab':
> > symtab.c:1043: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int'
> > symtab.c:1076: warning: format '%p' expects type 'void *', but argument 2 has type 'Addr'
> > symtab.c:1076: warning: format '%d' expects type 'int', but argument 3 has type 'Elf64_Xword'
> > symtab.c: In function 'read_lib_symbols':
> > symtab.c:1443: warning: format '%d' expects type 'int', but argument 2 has type 'Elf64_Off'
> > symtab.c:1443: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int'
> >
> > Otherwise tools could break, if their output is parsed (i.e. callgrind).
>
> Your patch is only correct if VG_(printf) uses the same format
> characters as printf and with the exact same meaning. I'm not sure
> that is necessarily true as VG_(printf) uses it's own formatter
> so I would have to check if they do match fully.
It looks like VG_(printf) is a superset of printf - the %t format
is extra and there are extra flags (command and open parenthesis).
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-07 16:20:17
|
In message <200...@on...>
André Wöbbeking <Woe...@on...> wrote:
> now with 64 bit support shouldn't you check the format strings (see
> attached patch, I'm sure there're more places) to avoid i.e.
>
> symtab.c: In function 'read_symtab':
> symtab.c:1043: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int'
> symtab.c:1076: warning: format '%p' expects type 'void *', but argument 2 has type 'Addr'
> symtab.c:1076: warning: format '%d' expects type 'int', but argument 3 has type 'Elf64_Xword'
> symtab.c: In function 'read_lib_symbols':
> symtab.c:1443: warning: format '%d' expects type 'int', but argument 2 has type 'Elf64_Off'
> symtab.c:1443: warning: format '%d' expects type 'int', but argument 4 has type 'long unsigned int'
>
> Otherwise tools could break, if their output is parsed (i.e. callgrind).
Your patch is only correct if VG_(printf) uses the same format
characters as printf and with the exact same meaning. I'm not sure
that is necessarily true as VG_(printf) uses it's own formatter
so I would have to check if they do match fully.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <Woe...@on...> - 2005-08-07 16:11:54
|
Hi, now with 64 bit support shouldn't you check the format strings (see=20 attached patch, I'm sure there're more places) to avoid i.e. symtab.c: In function 'read_symtab': symtab.c:1043: warning: format '%d' expects type 'int', but argument 3 has = type 'long unsigned int' symtab.c:1076: warning: format '%p' expects type 'void *', but argument 2 h= as type 'Addr' symtab.c:1076: warning: format '%d' expects type 'int', but argument 3 has = type 'Elf64_Xword' symtab.c: In function 'read_lib_symbols': symtab.c:1443: warning: format '%d' expects type 'int', but argument 2 has = type 'Elf64_Off' symtab.c:1443: warning: format '%d' expects type 'int', but argument 4 has = type 'long unsigned int' Otherwise tools could break, if their output is parsed (i.e. callgrind). Cheers, Andr=E9 |
|
From: Christian P. <tr...@ge...> - 2005-08-07 14:55:42
|
On Sunday 07 August 2005 11:56, Julian Seward wrote: > > 1. Is it normal for a PIE build to be slower? > > At the moment ... yes. > > > 2. Is it normal for a PIE build to allocate a huge amount of virtual > > memory (270G) even when running on tiny programs? (I don't really mind, > > but the Linux administrators made me swear that I would ask you, so > > please just say yes :) > > > :-) > > I'm starting to think about rewriting the low level address space > manager, so that all this PIE nonsense goes away once and for all > (a rewrite that worked correctly would fix both these problems). Oh yes, pleeeease :-D This is gonna fix *my* problem I still seem to have as well ;) Cya, Christian Parpart. =2D-=20 16:54:48 up 137 days, 6:02, 0 users, load average: 2.52, 2.91, 3.17 |
|
From: Julian S. <js...@ac...> - 2005-08-07 09:18:20
|
> 1. Is it normal for a PIE build to be slower? At the moment ... yes. > 2. Is it normal for a PIE build to allocate a huge amount of virtual > memory (270G) even when running on tiny programs? (I don't really mind, > but the Linux administrators made me swear that I would ask you, so > please just say yes :) :-) I'm starting to think about rewriting the low level address space manager, so that all this PIE nonsense goes away once and for all (a rewrite that worked correctly would fix both these problems). J |
|
From: Yeshurun, M. <mei...@in...> - 2005-08-07 09:13:15
|
The problem was solved simply by sending Valgrind's output to log files instead of standard output. (I'm using a PIE build of Valgrind 3.0 on a 64 bit platform.) Perhaps Valgrind and the child process were fighting over the same file descriptor. Thanks, Meir=20 -----Original Message----- From: Nicholas Nethercote [mailto:nj...@cs...]=20 Sent: Tuesday, August 02, 2005 4:54 PM To: Yeshurun, Meir Cc: val...@li... Subject: Re: [Valgrind-users] Effect of libc_freeres() on exit status of child process when running under Valgrind On Tue, 2 Aug 2005, Yeshurun, Meir wrote: > My program has a child process that produces the common invalid free > error because of libc_freeres(). Are you using --libc-freeres=3Dyes? > Can this cause the child process to return a failure exit status (even > if it returns a success exit status when the program is not run under > Valgrind)? Valgrind does not itself change the exit code of a program, so this is=20 unlikely. N |
|
From: Yeshurun, M. <mei...@in...> - 2005-08-07 09:07:34
|
Hi, I've been using a PIE build of Valgrind 3.0 on a 64 bit platform. So far it's working great, and the extra virtual memory is a life saver. I have just two small questions: 1. Is it normal for a PIE build to be slower? 2. Is it normal for a PIE build to allocate a huge amount of virtual memory (270G) even when running on tiny programs? (I don't really mind, but the Linux administrators made me swear that I would ask you, so please just say yes :) Thanks, Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Nicholas Nethercote Sent: Friday, August 05, 2005 6:58 PM To: Valgrind Users Subject: [Valgrind-users] Clarification about --enable-pie/--disable-pie Hi, In Valgrind 2.4.0, we built Valgrind as a position-independent executable=20 (PIE) if the toolchain supported it. This turned out to cause quite a few=20 problems -- people having random, inexplicable crashes. So for 3.0.0 we turned it off by default because it was causing too many problems. As a result of all this, it unfortunately seems like=20 --enable-pie/--disable-pie has taken on a mythical status... as though we=20 deliberately shipped a crippled Valgrind and you have to find the special=20 configure option to get it to work, bwaha! So I'm trying to clear up the confusion. Here's a summary: - 3.0.0 does not use PIE by default. This is much more stable. Do not use --enable-pie unless you have to. - Any why would you have to? Because a PIE build can give your program more address space when running under Valgrind, particularly on AMD64. - However, as we have seen, using PIE is a bit flaky and has caused problems on many systems. In short: don't use --enable-pie when configuring Valgrind unless you=20 know you need the extra address space it allows. And if you do use it,=20 don't be shocked if Valgrind crashes. We'd like to fix these problems, but we don't understand them yet. Any=20 information people can shed on them would be great, but as usual, saying "I built with PIE and Valgrind crashes!! What's wrong??" isn't very=20 helpful. The more relevant information you can provide, the better. N ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Tom H. <to...@co...> - 2005-08-07 08:42:38
|
In message <942...@ha...>
"Yeshurun, Meir" <mei...@in...> wrote:
> In line 272 of coregrind/stage1.c
>
> info.exe_base = VG_ROUNDDN(info.exe_end - 0x02000000, 0x10000000);
>
> change the '2' to '4' (i.e., multiply 0x02000000 by 2)
>
> and then make, make install again
That will only work if it is a PIE build. He is using 2.4.0 though
so it may well be as that was the default then.
If it isn't a PIE build then KICKSTART_BASE will been to be lowered.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Yeshurun, M. <mei...@in...> - 2005-08-07 08:34:14
|
Try this: In line 272 of coregrind/stage1.c info.exe_base =3D VG_ROUNDDN(info.exe_end - 0x02000000, 0x10000000); change the '2' to '4' (i.e., multiply 0x02000000 by 2) and then make, make install again -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of prashantha a.s Sent: Sunday, August 07, 2005 10:53 AM To: val...@li... Subject: [Valgrind-users] Technical support required - problem Hi All, I am prashantha.AS working for siemens from past few year, I am faceing some problem while using valgrind on MontaVista linux. Could any one can help me to trace out this problem.=20 Please find the attachment, to see the error Regards Prashantha.AS __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 |
|
From: Prashantha, A. <Pra...@si...> - 2005-08-07 08:19:46
|
PT02MzE0PT0gTWVtY2hlY2ssIGEgbWVtb3J5IGVycm9yIGRldGVjdG9yIGZvciB4ODYtbGludXgu DQo9PTYzMTQ9PSBDb3B5cmlnaHQgKEMpIDIwMDItMjAwNSwgYW5kIEdOVSBHUEwnZCwgYnkgSnVs aWFuIFNld2FyZCBldCBhbC4NCj09NjMxND09IFVzaW5nIHZhbGdyaW5kLTIuNC4wLCBhIHByb2dy YW0gc3VwZXJ2aXNpb24gZnJhbWV3b3JrIGZvciB4ODYtbGludXguDQo9PTYzMTQ9PSBDb3B5cmln aHQgKEMpIDIwMDAtMjAwNSwgYW5kIEdOVSBHUEwnZCwgYnkgSnVsaWFuIFNld2FyZCBldCBhbC4N Cj09NjMxND09DQo9PTYzMTQ9PSBNeSBQSUQgPSA2MzE0LCBwYXJlbnQgUElEID0gMzI1NzkuICBQ cm9nIGFuZCBhcmdzIGFyZToNCj09NjMxND09ICAgIC4vT3BtY0RhdGFDb2xsZWN0b3INCj09NjMx ND09DQo9PTYzMTQ9PSBWYWxncmluZCBsaWJyYXJ5IGRpcmVjdG9yeTogL3Vzci9sb2NhbC9saWIv dmFsZ3JpbmQNCj09NjMxND09IENvbW1hbmQgbGluZQ0KPT02MzE0PT0gICAgLi9PcG1jRGF0YUNv bGxlY3Rvcg0KPT02MzE0PT0gU3RhcnR1cCwgd2l0aCBmbGFnczoNCj09NjMxND09ICAgIC12DQo9 PTYzMTQ9PSAgICAtLWxvZy1maWxlPWNoazENCj09NjMxND09ICAgIC0tc2hvdy1yZWFjaGFibGU9 eWVzDQo9PTYzMTQ9PSAgICAtLWxlYWstY2hlY2s9ZnVsbA0KPT02MzE0PT0gQ29udGVudHMgb2Yg L3Byb2MvdmVyc2lvbjoNCj09NjMxND09ICAgTGludXggdmVyc2lvbiAyLjQuMjBfbXZsY2dlMzEt c2l0X29tbSAobWVpZXJAbHMtZWZldSkgKGdjYyB2ZXJzaW9uIDMuMy4xIChNb250YVZpc3RhIDMu My4xLTMuMC4xMC4wMzAwNTMyIDIwMDMtMTItMg0KNCkpICMxIFNNUCBNb24gRmViIDI4IDEyOjQw OjIwIENFVCAyMDA1DQo9PTYzMTQ9PSBSZWFkaW5nIHN5bXMgZnJvbSAvaG9tZS9ydHA5OS9PcG1j RGF0YUNvbGxlY3RvciAoMHg4MDQ4MDAwKQ0KPT02MzE0PT0gUmVhZGluZyBzeW1zIGZyb20gL2xp Yi9sZC0yLjMuMi5zbyAoMHgxQjhFNDAwMCkNCj09NjMxND09IFJlYWRpbmcgc3ltcyBmcm9tIC91 c3IvbG9jYWwvbGliL3ZhbGdyaW5kL3N0YWdlMiAoMHhCMDAwMDAwMCkNCj09NjMxND09IFJlYWRp bmcgc3ltcyBmcm9tIC9saWIvbGQtMi4zLjIuc28gKDB4QjEwMDAwMDApDQo9PTYzMTQ9PSBSZWFk aW5nIHN5bXMgZnJvbSAvbGliL2xpYmRsLTIuMy4yLnNvICgweEIxMDFEMDAwKQ0KPT02MzE0PT0g UmVhZGluZyBzeW1zIGZyb20gL2xpYi9saWJjLTIuMy4yLnNvICgweEIxMDIwMDAwKQ0KPT02MzE0 PT0gUmVhZGluZyBzeW1zIGZyb20gL3Vzci9sb2NhbC9saWIvdmFsZ3JpbmQvdmdza2luX21lbWNo ZWNrLnNvICgweEIxMjU4MDAwKQ0KPT02MzE0PT0gUmVhZGluZyBzdXBwcmVzc2lvbnMgZmlsZTog L3Vzci9sb2NhbC9saWIvdmFsZ3JpbmQvZGVmYXVsdC5zdXBwDQo9PTYzMTQ9PQ0KPT02MzE0PT0g UmVhZGluZyBzeW1zIGZyb20gL3Vzci9sb2NhbC9saWIvdmFsZ3JpbmQvdmdfaW5qZWN0LnNvICgw eDFCOEZDMDAwKQ0KPT02MzE0PT0gUmVhZGluZyBzeW1zIGZyb20gL3Vzci9sb2NhbC9saWIvdmFs Z3JpbmQvdmdwcmVsb2FkX21lbWNoZWNrLnNvICgweDFCOEZGMDAwKQ0KPT02MzE0PT0gUmVhZGlu ZyBzeW1zIGZyb20gL29wdC9TTUFXL1NNQVdydHAvbGliL2xpYlJ0cExkZC5zbyAoMHgxQjkwNjAw MCkNCj09NjMxND09IFJlYWRpbmcgc3ltcyBmcm9tIC9vcHQvU01BVy9TTUFXcnRwL2xpYi9saWJS dHBFdmVudC5zbyAoMHgxQjkwQTAwMCkNCj09NjMxND09IFJlYWRpbmcgc3ltcyBmcm9tIC9vcHQv U01BVy9TTUFXcnRwL2xpYi9saWJSdHBUcmMuc28gKDB4MUI5QjgwMDApDQo9PTYzMTQ9PSBSZWFk aW5nIHN5bXMgZnJvbSAvb3B0L1NNQVcvU01BV3J0cC9saWIvbGliUnRwRGJpU29saWQuc28gKDB4 MUI5RDMwMDApDQo9PTYzMTQ9PSBSZWFkaW5nIHN5bXMgZnJvbSAvb3B0L1NNQVcvU01BV3J0cC9s aWIvbGliUnRwQ29tLnNvICgweDFCOUVCMDAwKQ0KPT02MzE0PT0gUmVhZGluZyBzeW1zIGZyb20g L29wdC9TTUFXL1NNQVdydHAvbGliL2xpYlJ0cENvbW1vbi5zbyAoMHgxQkE3MTAwMCkNCj09NjMx ND09IFJlYWRpbmcgc3ltcyBmcm9tIC9vcHQvU01BVy9TTUFXcnRwL2xpYi9saWJSdHBVdGlsLnNv ICgweDFCQTc2MDAwKQ0KPT02MzE0PT0gUmVhZGluZyBzeW1zIGZyb20gL29wdC9TTUFXL1NNQVdy dHAvbGliL2xpYlJ0cENmZy5zbyAoMHgxQkE4MTAwMCkNCj09NjMxND09IFJlYWRpbmcgc3ltcyBm cm9tIC9vcHQvU01BVy9TTUFXcnRwL2xpYi9saWJSdHBTbm0uc28gKDB4MUJBOTEwMDApDQo9PTYz MTQ9PSBSZWFkaW5nIHN5bXMgZnJvbSAvdXNyL3Byb2plY3QvbGliL2xpYkdzeXMuc28gKDB4MUJB OTYwMDApDQo9PTYzMTQ9PSBSZWFkaW5nIHN5bXMgZnJvbSAvdXNyL3Byb2plY3QvbGliL2xpYmFu dGxyLnNvLjIuNy4yICgweDFCQUEwMDAwKQ0KPT02MzE0PT0gICAgb2JqZWN0IGRvZXNuJ3QgaGF2 ZSBhIHN5bWJvbCB0YWJsZQ0KPT02MzE0PT0gICAgb2JqZWN0IGRvZXNuJ3QgaGF2ZSBhbnkgZGVi dWcgaW5mbw0KPT02MzE0PT0gUmVhZGluZyBzeW1zIGZyb20gL3Vzci9wcm9qZWN0L2xpYi9saWJj bWFwaS5zby4yLjIuMC4wNTA2MDgyMSAoMHgxQkFENDAwMCkNClZHXyhnZXRfbWVtb3J5X2Zyb21f bW1hcCk6IG5ld1N1cGVyYmxvY2sncyByZXF1ZXN0IGZvciA2MTQ4MDk2IGJ5dGVzIGZhaWxlZC4N ClZHXyhnZXRfbWVtb3J5X2Zyb21fbW1hcCk6IDQxMDE1MDg3IGJ5dGVzIGFscmVhZHkgYWxsb2Nh dGVkLg0KDQpTb3JyeS4gIFlvdSBjb3VsZCB0cnkgdXNpbmcgYSB0b29sIHRoYXQgdXNlcyBsZXNz IG1lbW9yeTsNCmVnLiBhZGRyY2hlY2sgaW5zdGVhZCBvZiBtZW1jaGVjay4NCg== |
|
From: prashantha a.s <pra...@ya...> - 2005-08-07 07:52:56
|
Hi All, I am prashantha.AS working for siemens from past few year, I am faceing some problem while using valgrind on MontaVista linux. Could any one can help me to trace out this problem. Please find the attachment, to see the error Regards Prashantha.AS __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Stephen T. <st...@to...> - 2005-08-06 19:47:36
|
On Sat, 2005-08-06 at 16:20 +0200, Maurice van der Pot wrote: > On Sat, Aug 06, 2005 at 11:05:34AM +0100, Julian Seward wrote: > > > > and everybody, more or less, has at least a Pentium-III or equivale= nt > > > > CPU anyway. > > > > > > that's quite a statement. it may be even true - in the western world = and > > > possibly even globally in the professional sw devel world. > >=20 > > Fair enough. Let's wait to see if this causes many complaints in pract= ice. >=20 > // received bug report from user with Athlon Thunderbird > complaints++; Who will be keeping track of the actual number of complaints and why? Given maurice's code, humor noted, there is a race condition for multiple threads. Stephen |
|
From: Maurice v. d. P. <gri...@ge...> - 2005-08-06 14:20:29
|
On Sat, Aug 06, 2005 at 11:05:34AM +0100, Julian Seward wrote: > > > and everybody, more or less, has at least a Pentium-III or equivalent > > > CPU anyway. > > > > that's quite a statement. it may be even true - in the western world and > > possibly even globally in the professional sw devel world. >=20 > Fair enough. Let's wait to see if this causes many complaints in practic= e. // received bug report from user with Athlon Thunderbird complaints++; Maurice. --=20 Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
From: Julian S. <js...@ac...> - 2005-08-06 12:17:40
|
> ok, but note that this group is underrepresented here, Noted. J |
|
From: Oswald B. <os...@kd...> - 2005-08-06 12:12:47
|
On Sat, Aug 06, 2005 at 11:05:34AM +0100, Julian Seward wrote: > > > and everybody, more or less, has at least a Pentium-III or > > > equivalent CPU anyway. > > > > that's quite a statement. it may be even true - in the western world > > and possibly even globally in the professional sw devel world. > > Fair enough. Let's wait to see if this causes many complaints in > practice. > ok, but note that this group is underrepresented here, because many of them have very limited internet access or get their software offline even. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Julian S. <js...@ac...> - 2005-08-06 10:02:32
|
> > Correct. SSE1 is now a minimum requirement. Supporting non-SSE > > variants is too much hassle > > uhm, what is the problem? It means everywhere where the host machine's sse state is messed with, we now have to have a conditional branch around that code. To be fair, this is fewer places with 3.0 than with 2.4.X. It is certainly possible, just extra clutter and more code paths/ variants to verify. > > and everybody, more or less, has at least a Pentium-III or equivalent > > CPU anyway. > > that's quite a statement. it may be even true - in the western world and > possibly even globally in the professional sw devel world. Fair enough. Let's wait to see if this causes many complaints in practice. J |
|
From: Oswald B. <os...@kd...> - 2005-08-06 09:47:49
|
On Sat, Aug 06, 2005 at 10:01:51AM +0100, Julian Seward wrote: > Correct. SSE1 is now a minimum requirement. Supporting non-SSE > variants is too much hassle > uhm, what is the problem? > and everybody, more or less, has at least a Pentium-III or equivalent > CPU anyway. > that's quite a statement. it may be even true - in the western world and possibly even globally in the professional sw devel world. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Julian S. <js...@ac...> - 2005-08-06 08:59:00
|
Correct. SSE1 is now a minimum requirement. Supporting non-SSE variants is too much hassle and everybody, more or less, has at least a Pentium-III or equivalent CPU anyway. J On Saturday 06 August 2005 03:54, John Reiser wrote: > valgrind-3.0.0 crashes with SIGILL [illegal instruction] > at startup on AMD Athlon ["plain"]. Apparently valgrind-3.0.0 > assumes SSE x86 hardware ["ldmxcsr" instruction introduced with SSE]. > So if "cat /proc/cpuinfo | grep flags" does not show "sse", > then valgrind-3.0.0 will not work your CPU. > > http://bugs.kde.org/show_bug.cgi?id=110274 |