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
(4) |
3
(10) |
|
4
(1) |
5
(2) |
6
(10) |
7
(16) |
8
(7) |
9
(3) |
10
|
|
11
(11) |
12
(16) |
13
(14) |
14
(9) |
15
(13) |
16
(10) |
17
(2) |
|
18
|
19
(14) |
20
(1) |
21
(1) |
22
(11) |
23
(7) |
24
(8) |
|
25
(11) |
26
(10) |
27
(3) |
28
(8) |
29
(24) |
30
(10) |
|
|
From: Brian C. <cr...@fi...> - 2005-09-11 21:02:59
|
It's likely that on the first iteration of this while loop, the value of
*s1 isn't set to something valid. Maybe you need to initialize it
before going into the loop. (or don't use the assignment as the loop
conditional -- it can lead to some interesting readability issues anyway.
-- Brian
Dennis Lubert wrote:
> At 11:35 11.09.2005, tim wrote:
>
>> hi all,
>>
>> i've got a question concerning the error message:
>> Conditional jump or move depends on uninitialised value(s)
>>
>> it occurs on structures like this:
>>
>> while (s2 = *s1)
>> {
>> s1 = something(s2);
>> }
>>
>> since the code is working, i'm pretty clueless, why i get this error.
>> is it somehow possible to suppress this error message?
>
>
> Just because the code *seems* to be working does not mean its correct.
> You can either check by valgrind client requests, or by simply
> outputting the values if they are really defined. To help us helping
> you on this error, you need to provide us with a little more context
> on your code, a small testcase would be fine.
>
> greets
>
> Dennis
>
>
> Carpe quod tibi datum est
>
>
> -------------------------------------------------------
> 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: Nicholas N. <nj...@cs...> - 2005-09-11 20:45:58
|
On Wed, 7 Sep 2005, Julian Seward wrote: >> I am wondering if there is a way to use memcheck or addrcheck, and >> just check for memory leaks, without checking for access errors? > > No, there isn't. You get the full functionality or nothing. That > said, if you just want to check for memory leaks you can probably > get away with something less heavyweight than Valgrind. I'm sure the > Gnome folks used to have a standalone leak detector of some kind, > but I can't remember any of the details. There are a zillion basic leak checkers out there... mpatrol's manual has a section listing many of them. I believe they generally don't do as well as Memcheck/Addrcheck, because the addressability tracking done helps improve Memcheck/Addrcheck's accuracy. N |
|
From: Robert W. <rj...@du...> - 2005-09-11 18:22:45
|
> I'm interested both in whether this is fundamentally possible, and an=20 > idea of what things would need to be done to actually implement it. I don't think this is possible. Valgrind creates a lot of state that wouldn't be around if it started half-way through the program (e.g. memory validity information.) Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Dennis L. <pla...@in...> - 2005-09-11 11:29:44
|
At 11:35 11.09.2005, tim wrote:
>hi all,
>
>i've got a question concerning the error message:
>Conditional jump or move depends on uninitialised value(s)
>
>it occurs on structures like this:
>
>while (s2 = *s1)
>{
> s1 = something(s2);
>}
>
>since the code is working, i'm pretty clueless, why i get this error.
>is it somehow possible to suppress this error message?
Just because the code *seems* to be working does not mean its correct. You
can either check by valgrind client requests, or by simply outputting the
values if they are really defined. To help us helping you on this error,
you need to provide us with a little more context on your code, a small
testcase would be fine.
greets
Dennis
Carpe quod tibi datum est
|
|
From: Tom H. <to...@co...> - 2005-09-11 10:17:49
|
In message <loo...@po...>
tim <tim...@gm...> wrote:
> i've got a question concerning the error message:
> Conditional jump or move depends on uninitialised value(s)
>
> it occurs on structures like this:
>
> while (s2 = *s1)
> {
> s1 = something(s2);
> }
>
> since the code is working, i'm pretty clueless, why i get this error.
> is it somehow possible to suppress this error message?
Well you don't want to suppress it, at least not until you understand
the cause properly.
The fairly obvious explanation is that at some point wither s2 or *s1
is not defined and hence the implicit equality test against zero in that
while results in an undefined result.
Time to start sticking in VALGRIND_CHECK_DEFINED calls to see which
of those variables it the problem I would say.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: tim <tim...@gm...> - 2005-09-11 09:41:35
|
hi all,
i've got a question concerning the error message:
Conditional jump or move depends on uninitialised value(s)
it occurs on structures like this:
while (s2 = *s1)
{
s1 = something(s2);
}
since the code is working, i'm pretty clueless, why i get this error.
is it somehow possible to suppress this error message?
thanks in advance ... tim
|
|
From: Mike <pd...@ya...> - 2005-09-09 23:00:51
|
I'm using Timesys Linux. Sorry if I am being an idiot... bash-2.05# valgrind ls -l ==966== Memcheck, a memory error detector. ==966== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==966== Using LibVEX rev 1367, a library for dynamic binary translation. ==966== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==966== Using valgrind-3.0.1, a dynamic binary instrumentation framework. ==966== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==966== For more details, rerun with: -v ==966== valgrind: dwarf.c:411 (read_dwarf2_lineblock): Assertion 'noLargerThan > 0' failed. ==966== at 0xB0016EF3: ??? (m_libcassert.c:169) ==966== by 0xB0016EF2: vgPlain_assert_fail (m_libcassert.c:169) ==966== by 0xB002F496: read_dwarf2_lineblock (dwarf.c:523) ==966== by 0xB002FBD6: vgModuleLocal_read_debuginfo_dwarf2 (dwarf.c:953) ==966== by 0xB002BCEF: read_lib_symbols (symtab.c:1626) ==966== by 0xB002BE5C: vgPlain_read_seg_symbols (symtab.c:1680) ==966== by 0xB0040DCB: vgPlain_map_file_segment (aspacemgr.c:816) ==966== by 0xB0040F5C: vgPlain_map_fd_segment (aspacemgr.c:862) ==966== by 0xB004252A: vgModuleLocal_mmap_segment (syswrap-generic.c:148) ==966== by 0xB005A63F: vgSysWrap_x86_linux_old_mmap_before (syswrap-x86-linux.c:1538) ==966== by 0xB005BF46: vgPlain_client_syscall (syswrap-main.c:622) ==966== by 0xB003E148: handle_syscall (scheduler.c:589) ==966== by 0xB003E431: vgPlain_scheduler (scheduler.c:688) ==966== by 0xB005CA65: vgModuleLocal_thread_wrapper (syswrap-linux.c:80) ==966== by 0xB0057C20: run_a_thread_NORETURN (syswrap-x86-linux.c:150) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==966== at 0x1B8F3EFD: mmap (in /lib/ld-2.2.5.so) ==966== by 0x1B8E9C67: _dl_map_object (dl-load.c:1814) ==966== by 0x1B8ED5F7: openaux (dl-deps.c:67) ==966== by 0x1B8EE8A5: _dl_catch_error (dl-error.c:152) ==966== by 0x1B8ED8EB: _dl_map_object_deps (dl-deps.c:232) ==966== by 0x1B8E5D57: dl_main (rtld.c:811) ==966== by 0x1B8F0C61: _dl_sysdep_start (../sysdeps/generic/dl-sysdep.c:208) ==966== by 0x1B8E58CB: _dl_start_final (rtld.c:249) ==966== by 0x1B8E56CE: _dl_start (rtld.c:201) ==966== by 0x1B8E5375: (within /lib/ld-2.2.5.so) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: www.valgrind.org |
|
From: Tom H. <to...@co...> - 2005-09-09 14:22:41
|
In message <Pin...@ma...>
David Conley <dc...@fr...> wrote:
> I've just built v3.0.1 on x86_64 linux machine and whenever I attempt to
> run my program I get the following message
>
> broadwayfc64:~/game/game/> valgrind --tool=memcheck -v --num-callers=20
> --error-limit=no --log-file=valgrind game_debug.linux -guiedit
> valgrind: Can only handle 32-bit executables
> valgrind: do_exec(./game_debug.linux) failed: Exec format error
>
> Any ideas why this is?
Because you're built and/or installed a 32 bit build of valgrind.
Check that you are really running the build you think you are and
if that is correct then check the output from when you configured
valgrind to see what architecture it built for.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: David C. (FRD) <dc...@fr...> - 2005-09-09 14:15:26
|
I've just built v3.0.1 on x86_64 linux machine and whenever I attempt to run my program I get the following message broadwayfc64:~/game/game/> valgrind --tool=memcheck -v --num-callers=20 --error-limit=no --log-file=valgrind game_debug.linux -guiedit valgrind: Can only handle 32-bit executables valgrind: do_exec(./game_debug.linux) failed: Exec format error Any ideas why this is? Dave |
|
From: James N. <jne...@ec...> - 2005-09-08 18:56:59
|
How difficult would it be to get Valgrind to be able to attach to a process that is already running? It seems to me that the only stumbling block would be that you have to load valgrind into the middle of the process's address space, since you don't get to set up the address space ahead of time. To clarify, my motivation is that when I detect an abnormal event in a running program (through other means), I would like to be able to have valgrind take over (with a tool that I'm developing), but I don't want to pay the performance cost of running valgrind 100% of the time. So, for example, it would be acceptable to start the program in a special way (perhaps reserving a piece of address space for valgrind to later be loaded into), as long as I can run the program natively initially, and be able to switch to Valgrind in mid-execution. I'm interested both in whether this is fundamentally possible, and an idea of what things would need to be done to actually implement it. Thanks! -Jim |
|
From: Yeshurun, M. <mei...@in...> - 2005-09-08 17:59:27
|
Perhaps the stack trace for the directly lost blocks is different so
they are listed separately, i.e., in a different "loss record".
Regards,
Meir
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of qd
Sent: Thursday, September 08, 2005 6:26 PM
To: Bob Rossi
Cc: val...@li...
Subject: Re: [Valgrind-users] what does "indirectly lost" mean?
Thanks Bob, my valgrind record is like this:
=3D=3D30386=3D=3D 243 bytes in 12 blocks are indirectly lost
in loss record 59 of 109
I can understand a record like this:
=3D=3D30386=3D=3D 386 (143 direct, 243 indirect) bytes in 2
blocks are definitely lost in loss record 57 of 109
which shows both direct and indirect leaks.
What I don't understand is how come I got an
"indirectly lost" without a corresponding "directly
lost".
-Quan
--- Bob Rossi <bo...@br...> wrote:
> On Wed, Sep 07, 2005 at 08:35:33PM -0700, qd wrote:
> > if I have a struct like this:
> >=20
> > struct mystruct{
> > char *a;
> > char *b;
> > };
> >=20
> > and valgrind says that "b" is indirectly lost,
> what
> > does it mean? Am I leaking only "b" or am I
> leaking
> > the whole struct?
> >=20
> > If only "b" is leaking, shouldn't it be a
> "directly
> > lost"?
> > If the whole struct is leaking, I'm expecting
> another
> > valgrind record saying that "mystruct" is leaking
> > which I didn't see in my case.
> >=20
> > Can someone clarify under what circumstances I'll
> get
> > a "indirectly lost" record?
> > Thanks!
>=20
> Please see this,
>=20
>
http://sourceforge.net/mailarchive/forum.php?thread_id=3D7922894&forum_id=
=3D
32038
>=20
> Bob Rossi
>=20
=09
=09
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
-------------------------------------------------------
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: qd <qd...@ya...> - 2005-09-08 15:26:31
|
Thanks Bob, my valgrind record is like this:
==30386== 243 bytes in 12 blocks are indirectly lost
in loss record 59 of 109
I can understand a record like this:
==30386== 386 (143 direct, 243 indirect) bytes in 2
blocks are definitely lost in loss record 57 of 109
which shows both direct and indirect leaks.
What I don't understand is how come I got an
"indirectly lost" without a corresponding "directly
lost".
-Quan
--- Bob Rossi <bo...@br...> wrote:
> On Wed, Sep 07, 2005 at 08:35:33PM -0700, qd wrote:
> > if I have a struct like this:
> >
> > struct mystruct{
> > char *a;
> > char *b;
> > };
> >
> > and valgrind says that "b" is indirectly lost,
> what
> > does it mean? Am I leaking only "b" or am I
> leaking
> > the whole struct?
> >
> > If only "b" is leaking, shouldn't it be a
> "directly
> > lost"?
> > If the whole struct is leaking, I'm expecting
> another
> > valgrind record saying that "mystruct" is leaking
> > which I didn't see in my case.
> >
> > Can someone clarify under what circumstances I'll
> get
> > a "indirectly lost" record?
> > Thanks!
>
> Please see this,
>
>
http://sourceforge.net/mailarchive/forum.php?thread_id=7922894&forum_id=32038
>
> Bob Rossi
>
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
|
|
From: Olly B. <ol...@su...> - 2005-09-08 14:15:55
|
On 2005-08-23, Nicholas Nethercote <nj...@cs...> wrote: > On Thu, 18 Aug 2005, Aghiles Kheffache wrote: > >> I was wondering about the feasability of a project in Valgrind/Vex: tracking >> FPU operations that have a precision problems (such as adding a very small >> floating point number to a very large one). > > The idea has been floated briefly before but I'm not aware of anyone who > has attempted it. I suspect you mean: http://article.gmane.org/gmane.comp.debugging.valgrind/501 > It would be very interesting to see if this could be made to work. Me too. I've not had time to do anything further with the idea, and nobody has contacted me about it either. Cheers, Olly |
|
From: Jose R. <jr...@cr...> - 2005-09-08 13:56:08
|
Dear all, =20 I would like to install valgrind 3.0.1 on a RedHat Enterprise Linux WS 3 = for AMD 64 (dual processor), kernel version 2.4.21-9.ELsmp, gcc 3.4.3 =20 The problem is that the application can only be built in 32 bit mode, = since the libraries with which I=92m linking the code are only available in 32 = bit mode. =20 =20 I know that to debug 32 bit applications in a 64 bit platform I must = built valgrind in 32 but mode. Therefore my first approach was to set CFLAGS = to compile valgrind in 32 mode: =20 ./configure CFLAGS=3D-m32 CPPFLAGS=3D-m32 CCASFLAGS=3D-m32 -prefix=3D/home/jreis/valgrind/ =20 When I ran make I got the following error: =20 make[4]: Entering directory `/home/jreis/valgrind-3.0.0/coregrind/m_aspacemgr' if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../.. -I../../coregrind/amd64 -I../../coregrind/linux -I../../coregrind/amd64-linux -I../../include -I/home/jreis/valgrind-3.0.0/VEX/pub -DVGA_amd64=3D1 -DVGO_linux=3D1 -DVGP_amd64_linux=3D1 -m32 -m64 -fomit-frame-pointer -mpreferred-stack-boundary=3D2 -Wmissing-prototypes -Winline -Wall = -Wshadow -O -g -Wno-long-long -MT read_procselfmaps.o -MD -MP -MF ".deps/read_procselfmaps.Tpo" -c -o read_procselfmaps.o = read_procselfmaps.c; \ then mv -f ".deps/read_procselfmaps.Tpo" ".deps/read_procselfmaps.Po"; = else rm -f ".deps/read_procselfmaps.Tpo"; exit 1; fi read_procselfmaps.c:1: error: -mpreferred-stack-boundary=3D2 is not = between 4 and 12 =20 =20 Since this approach was not working, I tested the suggestion which was = sent to this mailing list by Julian Seward on 2005-08-03 17:19: =93If you want to run 32-bit x86 executables under Valgrind on an AMD64, you will need to build Valgrind on an x86 machine and copy it to the AMD64 machine =94 =20 I built the valgrind on my 32-bit machine, running Suse 9.3 and = gcc-3.4.3, using the following commands: ./configure CFLAGS=3D-m32 CPPFLAGS=3D-m32 CCASFLAGS=3D-m32 -prefix=3D/home/jreis/valgrind/ make =20 Then I copy it to the 64 bit machine, but when I ran =91make install=92 = I got the following error: =20 gcc -m32 -mpreferred-stack-boundary=3D2 -Wmissing-prototypes -Winline = -Wall -Wshadow -O -g -Wno-long-long -o stage2 -Wl,--export-dynamic -g -Wl,--whole-archive m_replacemalloc/libreplacemalloc_core.a -Wl,--no-whole-archive -Wl,-defsym,kickstart_base=3D0xb0000000 -Wl,-T,stage2.lds m_cpuid.o m_debugger.o m_debuglog.o m_errormgr.o m_execontext.o m_hashtable.o m_libcbase.o m_libcassert.o m_libcfile.o m_libcmman.o m_libcprint.o m_libcproc.o m_libcsignal.o m_machine.o = m_main.o m_mallocfree.o m_options.o m_profile.o m_pthreadmodel.o m_redir.o m_signals.o m_skiplist.o m_stacks.o m_stacktrace.o m_syscall.o m_threadmodel.o m_threadstate.o m_tooliface.o m_trampoline.o = m_translate.o m_transtab.o m_ume.o m_debuginfo/libdebuginfo.a m_demangle/libdemangle.a m_scheduler/libscheduler.a m_dispatch/libdispatch.a m_aspacemgr/libaspacemgr.a m_sigframe/libsigframe.a = m_syswrap/libsyswrap.a /home/jreis/valgrind-3.0.0/VEX/libvex.a -ldl /usr/bin/ld:stage2.lds:129: syntax error collect2: ld returned 1 exit status =20 Do you have any idea of what is wrong? Do I need to set --build or = --host flags when I ran configure on my 32 bit machine? If so which value = should I use? =20 Regards =20 Jos=E9 Reis Project Engineer, Command & Control mailto:jr...@cr... =20 Critical Software SA Polo Tecnol=F3gico de Lisboa, lote 1 Estrada do Pa=E7o do Lumiar 1600-546 Lisboa Tel. +351 217101192 Fax. +351 217101103 <http://www.criticalsoftware.com/> http://www.criticalsoftware.com =20 |
|
From: Bob R. <bo...@br...> - 2005-09-08 10:49:36
|
On Wed, Sep 07, 2005 at 08:35:33PM -0700, qd wrote:
> if I have a struct like this:
>
> struct mystruct{
> char *a;
> char *b;
> };
>
> and valgrind says that "b" is indirectly lost, what
> does it mean? Am I leaking only "b" or am I leaking
> the whole struct?
>
> If only "b" is leaking, shouldn't it be a "directly
> lost"?
> If the whole struct is leaking, I'm expecting another
> valgrind record saying that "mystruct" is leaking
> which I didn't see in my case.
>
> Can someone clarify under what circumstances I'll get
> a "indirectly lost" record?
> Thanks!
Please see this,
http://sourceforge.net/mailarchive/forum.php?thread_id=7922894&forum_id=32038
Bob Rossi
|
|
From: qd <qd...@ya...> - 2005-09-08 03:35:41
|
if I have a struct like this:
struct mystruct{
char *a;
char *b;
};
and valgrind says that "b" is indirectly lost, what
does it mean? Am I leaking only "b" or am I leaking
the whole struct?
If only "b" is leaking, shouldn't it be a "directly
lost"?
If the whole struct is leaking, I'm expecting another
valgrind record saying that "mystruct" is leaking
which I didn't see in my case.
Can someone clarify under what circumstances I'll get
a "indirectly lost" record?
Thanks!
-Quan
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
|
From: Harold N. <hna...@gm...> - 2005-09-07 18:39:38
|
> xP is a request for SSE3 code ("Prescott"), no? We don't currently
> support SSE3, only SSE2. If you recompile for SSE2 (xW, "Willamette")
> then you should be OK.
Right. I didn't see the limitation documented, but I could have missed it.
Harold
|
|
From: Julian S. <js...@ac...> - 2005-09-07 17:54:51
|
> I am wondering if there is a way to use memcheck or addrcheck, and > just check for memory leaks, without checking for access errors? No, there isn't. You get the full functionality or nothing. That said, if you just want to check for memory leaks you can probably get away with something less heavyweight than Valgrind. I'm sure the Gnome folks used to have a standalone leak detector of some kind, but I can't remember any of the details. J |
|
From: <bil...@my...> - 2005-09-07 17:25:13
|
Tom Hughes wrote: >>flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca >>cmov pat pse36 mmx fxsr pni syscall mmxext 3dnowext 3dnow > > > No SSE flag there - mmxext is a subset of SSE1. > > What you've got looks like an early Athlon - only the later XP/MP > ones had the full SSE1 instruction set. You are right, it is one of the first series of Athlons. It's still running like a charm and is performing quite well with my TNT2. Quote from http://en.wikipedia.org/wiki/Streaming_SIMD_Extensions "AMD eventually added support for SSE instructions in its Athlon XP processor." On a sidenote: I can even run Q3, Nexuiz and similar games with a good framerate, but none of the newer features of course ;) Werner |
|
From: Julian S. <js...@ac...> - 2005-09-07 17:07:41
|
On Wednesday 07 September 2005 17:57, Tom Hughes wrote:
> In message <bd8...@ma...>
>
> Harold Naparst <hna...@gm...> wrote:
> > Programs that run fine when compiled with ICC -xP (version 9.0) on Linux
> > give the following message with Valgrind 3.0.1:
> >
> > Fatal Error : This program was not built to run on the processor in your
> > system.
xP is a request for SSE3 code ("Prescott"), no? We don't currently
support SSE3, only SSE2. If you recompile for SSE2 (xW, "Willamette")
then you should be OK.
J
|
|
From: Heather M. <my...@si...> - 2005-09-07 17:03:54
|
All, I am wondering if there is a way to use memcheck or addrcheck, and just check for memory leaks, without checking for access errors? Also, does this save any time? Thanks, Heather Myers -- Failure Is Not An Option. It's bundled with your software. -- Anonymous |
|
From: Tom H. <to...@co...> - 2005-09-07 16:57:36
|
In message <bd8...@ma...>
Harold Naparst <hna...@gm...> wrote:
> Programs that run fine when compiled with ICC -xP (version 9.0) on Linux
> give the following message with Valgrind 3.0.1:
>
> Fatal Error : This program was not built to run on the processor in your
> system.
>
> This error is usually indicative of the program's compile flags not matching
> the target processor.
> However, in this case, the program does run fine outside of Valgrind.
The emulated CPU provided by valgrind may report different features
to the real CPU however, and ICC compiled code tests the processor
features at startup I believe.
One obvious candidate would be SSE3 for example, which valgrind
doesn't support and won't advertise.
It would help to know what architecture you are targeting with icc.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Harold N. <hna...@gm...> - 2005-09-07 16:53:23
|
Programs that run fine when compiled with ICC -xP (version 9.0) on Linux=20 give the following message with Valgrind 3.0.1: Fatal Error : This program was not built to run on the processor in your=20 system. This error is usually indicative of the program's compile flags not matchin= g=20 the target processor. However, in this case, the program does run fine outside of Valgrind. Harold Naparst |
|
From: Brian C. <cr...@fi...> - 2005-09-07 16:26:29
|
Actually, my apologies.... I was running an old version of valgrind accidentally. *blush* -- Brian Brian Crowder wrote: > > My program, after a few hours of running, causes SVN valgrind to crash > in the following way: > > valgrind: vg_memory.c:229 (vgPlain_unmap_range): Assertion `rs == s' > failed. > ==8613== at 0xB002BFE0: vgPlain_skin_assert_fail (vg_mylibc.c:1137) > ==8613== by 0xB002BFDF: assert_fail (vg_mylibc.c:1133) > ==8613== by 0xB002C01D: vgPlain_core_assert_fail (vg_mylibc.c:1144) > ==8613== by 0xB0029669: vgPlain_unmap_range (vg_memory.c:229) > > sched status: > > Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 > ==8613== at 0x420E49D1: munmap (in /lib/i686/libc-2.2.5.so) > ==8613== by 0x4207531C: _IO_file_close_it@@GLIBC_2.1 (in > /lib/i686/libc-2.2.5.so) > ==8613== by 0x4206B5D0: _IO_fclose@@GLIBC_2.1 (in > /lib/i686/libc-2.2.5.so) > ==8613== by 0x809B94C: start_npc_prog (dmpl.c:4058) > > Thread 2: status = WaitSys, associated_mx = 0x0, associated_cv = 0x0 > ==8613== at 0x420B4CA1: nanosleep (in /lib/i686/libc-2.2.5.so) > ==8613== by 0x825E6C5: queued_thread_main (threads.c:28) > ==8613== by 0x1B93AB39: thread_wrapper (vg_libpthread.c:867) > ==8613== by 0xB000F0C3: (within /usr/local/lib/valgrind/stage2) > > > From my googling, this looks like an old bug (91028) which has > regressed, but I haven't dug into the code yet. Any thoughts? > > Thanks in advance, > Brian > > > ------------------------------------------------------- > 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: Brian C. <cr...@fi...> - 2005-09-07 16:17:16
|
My program, after a few hours of running, causes SVN valgrind to crash in the following way: valgrind: vg_memory.c:229 (vgPlain_unmap_range): Assertion `rs == s' failed. ==8613== at 0xB002BFE0: vgPlain_skin_assert_fail (vg_mylibc.c:1137) ==8613== by 0xB002BFDF: assert_fail (vg_mylibc.c:1133) ==8613== by 0xB002C01D: vgPlain_core_assert_fail (vg_mylibc.c:1144) ==8613== by 0xB0029669: vgPlain_unmap_range (vg_memory.c:229) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==8613== at 0x420E49D1: munmap (in /lib/i686/libc-2.2.5.so) ==8613== by 0x4207531C: _IO_file_close_it@@GLIBC_2.1 (in /lib/i686/libc-2.2.5.so) ==8613== by 0x4206B5D0: _IO_fclose@@GLIBC_2.1 (in /lib/i686/libc-2.2.5.so) ==8613== by 0x809B94C: start_npc_prog (dmpl.c:4058) Thread 2: status = WaitSys, associated_mx = 0x0, associated_cv = 0x0 ==8613== at 0x420B4CA1: nanosleep (in /lib/i686/libc-2.2.5.so) ==8613== by 0x825E6C5: queued_thread_main (threads.c:28) ==8613== by 0x1B93AB39: thread_wrapper (vg_libpthread.c:867) ==8613== by 0xB000F0C3: (within /usr/local/lib/valgrind/stage2) From my googling, this looks like an old bug (91028) which has regressed, but I haven't dug into the code yet. Any thoughts? Thanks in advance, Brian |