You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(3) |
2
(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: Tom H. <to...@co...> - 2005-09-07 16:07:29
|
In message <431...@my...>
Werner H=C3=B6hrer <bil...@my...> wrote:
> Julian Seward wrote:
>
> > Thanks for that. Unfortunately Tom meant on the KDE bugzilla,
> > (bugs.kde.org), which is where all Valgrind bugs "live".
> >
> > Anyway: I guess you are running this on a non-SSE capable CPU,
> > correct? [no problem -- just want to check.]
>
> I don't think so (Athlon K7 !=3D SSE ?):
Yup.
> 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.
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <bil...@my...> - 2005-09-07 15:43:01
|
Julian Seward wrote: >>Tom Hughes wrote: >> > Can you raise a bug for this on the bug tracker please? >> >>Ok, done that :) >>http://sourceforge.net/tracker/index.php?func=detail&aid=1283279&group_id=4 >>6268&atid=445586 > > > Werner > > Thanks for that. Unfortunately Tom meant on the KDE bugzilla, > (bugs.kde.org), which is where all Valgrind bugs "live". > > Anyway: I guess you are running this on a non-SSE capable CPU, > correct? [no problem -- just want to check.] I don't think so (Athlon K7 != SSE ?): # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 2 model name : AMD Athlon(tm) Processor stepping : 1 cpu MHz : 656.746 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr pni syscall mmxext 3dnowext 3dnow bogomips : 1294.33 > The assertion that failed merely guards a case for which the > code exists, but no test case has been found (until now): > > case Xin_MFence: > /* see comment in hdefs.h re this insn */ > if (0) vex_printf("EMIT FENCE\n"); > switch (i->Xin.MFence.subarch) { > case VexSubArchX86_sse0: > vassert(0); /* awaiting test case */ <--- HERE > /* lock addl $0,0(%esp) */ > *p++ = 0xF0; *p++ = 0x83; *p++ = 0x44; > *p++ = 0x24; *p++ = 0x00; *p++ = 0x00; > goto done; > > If you remove the line marked HERE, and rebuild everything, > does it work? It would be good if you could confirm that. Ah, thanks for the answer. I'm currently using the (unstable) debian package of valgrind, but if i find some time i'll try to compile with this change. I've seen this workaround a few times until now (searched again today), so i'm pretty sure this'll fix my problem though. Thanks for your effort, Werner PS: As a few of you have seen already i've added a bug report into the KDE Bugzilla now. |
|
From: John R.
|
> I'd like to know time spent in methods like sleep() etc. Basically I'd > like to profile whole run of program including time when the program is > actually not spending any CPU cycles. The --wallclock mode of tsprof does this. http://BitWagon.com/tsprof/tsprof.html -- |
|
From: Olly B. <ol...@su...> - 2005-09-07 13:21:11
|
On 2005-09-07, Oswald Buddenhagen <os...@kd...> wrote: > On Tue, Sep 06, 2005 at 11:48:46PM +0100, Julian Seward wrote: >> Thanks for that. Unfortunately Tom meant on the KDE bugzilla, >> (bugs.kde.org), which is where all Valgrind bugs "live". >> > ugh, the sf tracker is not disabled? shame on you. :) > hmm, either the sf frontend is too cryptic for me or one can't, indeed, > remove the tracker without asking the sf team (yes, i tried on one of my > own projects i have admin perms on ;). You can disable the SF trackers if you are a project admin (the UI isn't particularly obvious though). It's documented here: https://sourceforge.net/docman/display_doc.php?docid=14041&group_id=1#tracker Cheers, Olly |
|
From: Tom H. <to...@co...> - 2005-09-07 08:35:23
|
In message <431...@co...>
Kuba Ouhrabka <ku...@co...> wrote:
> I'd like to know time spent in methods like sleep() etc. Basically I'd
> like to profile whole run of program including time when the program
> is actually not spending any CPU cycles. Is there any switch or
> something to valgrind/callgrind? Do I need any other tool instead of
> valgrind?
Well by definition you can't do profiling of wall clock time using
valgrind as it seriously distorts the real time taken to run code
so all you can really get is CPU time estimates (derived from
instruction and/or cycle count data).
If you want to profile wall clock times you need something that is
non-invasive - at a high level that means running under times or if
you want to know about part of your program then building in code
to call times() at relevant points is the best bet.
To see how long is spent in system calls consider strace with
the -T option.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Kuba O. <ku...@co...> - 2005-09-07 08:23:37
|
Hi, I'd like to know time spent in methods like sleep() etc. Basically I'd like to profile whole run of program including time when the program is actually not spending any CPU cycles. Is there any switch or something to valgrind/callgrind? Do I need any other tool instead of valgrind? Thanks, Kuba |
|
From: Oswald B. <os...@kd...> - 2005-09-07 05:48:49
|
On Tue, Sep 06, 2005 at 11:48:46PM +0100, Julian Seward wrote: > Thanks for that. Unfortunately Tom meant on the KDE bugzilla, > (bugs.kde.org), which is where all Valgrind bugs "live". > ugh, the sf tracker is not disabled? shame on you. :) hmm, either the sf frontend is too cryptic for me or one can't, indeed, remove the tracker without asking the sf team (yes, i tried on one of my own projects i have admin perms on ;). -- 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-09-06 22:48:18
|
> Tom Hughes wrote: > > Can you raise a bug for this on the bug tracker please? > > Ok, done that :) > http://sourceforge.net/tracker/index.php?func=detail&aid=1283279&group_id=4 >6268&atid=445586 Werner Thanks for that. Unfortunately Tom meant on the KDE bugzilla, (bugs.kde.org), which is where all Valgrind bugs "live". Anyway: I guess you are running this on a non-SSE capable CPU, correct? [no problem -- just want to check.] The assertion that failed merely guards a case for which the code exists, but no test case has been found (until now): case Xin_MFence: /* see comment in hdefs.h re this insn */ if (0) vex_printf("EMIT FENCE\n"); switch (i->Xin.MFence.subarch) { case VexSubArchX86_sse0: vassert(0); /* awaiting test case */ <--- HERE /* lock addl $0,0(%esp) */ *p++ = 0xF0; *p++ = 0x83; *p++ = 0x44; *p++ = 0x24; *p++ = 0x00; *p++ = 0x00; goto done; If you remove the line marked HERE, and rebuild everything, does it work? It would be good if you could confirm that. J |
|
From: Bill S. <bil...@my...> - 2005-09-06 22:22:52
|
Tom Hughes wrote: > Can you raise a bug for this on the bug tracker please? Ok, done that :) http://sourceforge.net/tracker/index.php?func=detail&aid=1283279&group_id=46268&atid=445586 > Tom Thanks, Werner |
|
From: Fred S. <fr...@co...> - 2005-09-06 19:00:12
|
=0D =3D=3D12132=3D=3D Thread 4: =3D=3D12132=3D=3D Invalid read of size 2 =3D=3D12132=3D=3D at 0x2303D733: (within= /lib/libgcc_s-3.4.3-20050228.so.1) =3D=3D12132=3D=3D by 0x2303E0AC: (within= /lib/libgcc_s-3.4.3-20050228.so.1) =3D=3D12132=3D=3D by 0x2303E14E: _Unwind_ForcedUnwind (in /lib/libgcc_s-3.4.3-20050228.so.1) =3D=3D12132=3D=3D by 0x1C4FF2A9: _Unwind_ForcedUnwind (in /lib/tls/libpthread-2.3.4.so) =3D=3D12132=3D=3D by 0x1C4FCF80: __pthread_unwind (in /lib/tls/libpthread-2.3.4.so) =3D=3D12132=3D=3D by 0x1C4F73EA: sigcancel_handler (in /lib/tls/libpthread-2.3.4.so) =3D=3D12132=3D=3D by 0x1C4FE7BF: (within /lib/tls/libpthread-2.3.4.so) =3D=3D12132=3D=3D Address 0xB0022AE9 is not stack'd, malloc'd or= (recently) free'd =0D Valgrind 3.0.1, on RHEL WS 4.0. =0D Looks lilke a pthread bug to me, anybody see anything different here? =0D I'm getting this at the END of a run of my multi-threaded program. Don't THINK it's a bug of mine.... =0D Thanks! =0D Fred =0D Find out about Computrition's upcoming International Computrition= Symposium, and other exciting events by visiting our web site at= www.computrition.com This email and any files transmitted with it are confidential and intended= solely for the use of the individual or entity to which they are= addressed. If you have received this email in error, please notify the= system manager. Please note that any views or opinions presented in this= email are solely those of the author and do not necessarily represent= those of the company. Finally, the recipient should check this email and= any attachments for the presence of viruses. The company accepts no= liability for any damage caused by any virus transmitted by this email. |
|
From: Tom H. <to...@co...> - 2005-09-06 18:46:34
|
In message <431...@my...>
Bill Spam <bil...@my...> wrote:
> i'm having some troubles with Valgrind and the code of the recently
> started game OpenAnno [1].
>
> I already searched the FAQ and the mailing list for an answer to this,
> but i didn't find anything that seems to be related to my problem.
> If this is a common issue i apologize ahead.
> I attached the error below, if you need more info i will try to provide it.
Can you raise a bug for this on the bug tracker please?
Thanks,
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bill S. <bil...@my...> - 2005-09-06 18:37:59
|
Of course i forgot to add the info about Valgrid and my system: valgrind-3.0.1 debian (testing/unstable) kernel 2.6.11-1-k7 gcc (GCC) 4.0.2 20050821 (prerelease) (Debian 4.0.1-6) Werner |
|
From: Bill S. <bil...@my...> - 2005-09-06 18:33:11
|
Hi all, i'm having some troubles with Valgrind and the code of the recently started game OpenAnno [1]. I already searched the FAQ and the mailing list for an answer to this, but i didn't find anything that seems to be related to my problem. If this is a common issue i apologize ahead. I attached the error below, if you need more info i will try to provide it. Thanks for your help, Werner Höhrer [1] http://www.lanadminsystem.de/cgi-bin/Lanas.pl?OPENANNO This output is what i get when i run # valgrind -v --tool=none ./openanno (It really doesn't depend on the tool i use, the error is displayed anyway) BEGIN error------------------------------------- ... ... Skipped some parts that care related to other errors (i think). ... I can post them as well if needed. ... vex: priv/host-x86/hdefs.c:2315 (emit_X86Instr): Assertion `0' failed. vex storage: P 512, T total 411183672 (13013711), T curr 20960 (702) valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==7591== at 0xB0016A22: vgPlain_core_panic_at (m_libcassert.c:181) ==7591== by 0xB0016A21: panic (m_libcassert.c:177) ==7591== by 0xB0016A3F: vgPlain_core_panic_at (m_libcassert.c:182) ==7591== by 0xB0016A50: vgPlain_core_panic (m_libcassert.c:187) ==7591== by 0xB002394C: failure_exit (m_translate.c:360) ==7591== by 0xB00573FA: vex_assert_fail (vex_util.c:163) ==7591== by 0xB005B8F1: emit_X86Instr (hdefs.c:2315) ==7591== by 0xB0057039: LibVEX_Translate (vex_main.c:574) ==7591== by 0xB0023ED1: vgPlain_translate (m_translate.c:585) ==7591== by 0xB0038F2E: handle_tt_miss (scheduler.c:566) ==7591== by 0xB003925A: vgPlain_scheduler (scheduler.c:680) ==7591== by 0xB004F475: vgModuleLocal_thread_wrapper (syswrap-linux.c:80) ==7591== by 0xB004B9E2: run_a_thread_NORETURN (syswrap-x86-linux.c:150) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==7591== at 0x1B97EAF9: (within /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B97EDE7: SDL_HasMMX (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B94ECF5: SDL_CalculateBlitN (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B938CB4: SDL_CalculateBlit (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B952653: SDL_MapSurface (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B952E3C: SDL_LowerBlit (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B955113: SDL_Flip (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x804DFB3: clientstart (client.c:220) ==7591== by 0x804A004: main (openanno.c:57) Thread 2: status = VgTs_Runnable ==7591== at 0x1BC84F87: select (in /lib/tls/libc-2.3.5.so) ==7591== by 0x1B97E1A6: SDL_Delay (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B97E1F9: (within /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B97CDC6: SDL_RunThread (in /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B97D0FB: (within /usr/lib/libSDL-1.2.so.0.7.1) ==7591== by 0x1B9D9CCC: start_thread (in /lib/tls/libpthread-2.3.5.so) ==7591== by 0x1BC8CB0D: clone (in /lib/tls/libc-2.3.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 In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. END error------------------------------------- |
|
From: Yeshurun, M. <mei...@in...> - 2005-09-06 10:31:59
|
Multiply the subtracted value by 2, try running Valgrind again, and if it's not enough, try multiplying by 2 again, and so on. In general, you should use the smallest value that works. You should do the same for KICKSTART_BASE with the non-PIE build, i.e. multiply by 2 the value you're subtracting from it until it works. Use the highest value for KICKSTART_BASE that works. Regards, Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Christoph Bartoschek Sent: Tuesday, September 06, 2005 11:45 AM To: val...@li... Subject: Re: [Valgrind-users] newSuperblock's request for 1048576 bytes failed with valgrind 3.0.1 Am Dienstag, 6. September 2005 10:17 schrieb Yeshurun, Meir: > Hi, > > I once had this problem and Tom showed me how to solve it (hopefully it > will work in your case as well). > > When not using PIE, in the configure script, change the value of > KICKSTART_BASE to 0xA0000000 (i.e. just change the 'B' to 'A') for the > relevant platform, and configure,make,make install again. > > When you are using PIE, the way to do the same thing is to increase the > value subtraced from exe_end to compute exe_base in line 272 of > coregrind/stage1.c Thanks, what is a suggested value for subtracting from exe_end in the PIE=20 case? Christoph ------------------------------------------------------- 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: Christoph B. <bar...@or...> - 2005-09-06 08:44:32
|
Am Dienstag, 6. September 2005 10:17 schrieb Yeshurun, Meir: > Hi, > > I once had this problem and Tom showed me how to solve it (hopefully it > will work in your case as well). > > When not using PIE, in the configure script, change the value of > KICKSTART_BASE to 0xA0000000 (i.e. just change the 'B' to 'A') for the > relevant platform, and configure,make,make install again. > > When you are using PIE, the way to do the same thing is to increase the > value subtraced from exe_end to compute exe_base in line 272 of > coregrind/stage1.c Thanks, what is a suggested value for subtracting from exe_end in the PIE case? Christoph |
|
From: Yeshurun, M. <mei...@in...> - 2005-09-06 08:18:16
|
Hi,
I once had this problem and Tom showed me how to solve it (hopefully it
will work in your case as well).
When not using PIE, in the configure script, change the value of
KICKSTART_BASE to 0xA0000000 (i.e. just change the 'B' to 'A') for the
relevant platform, and configure,make,make install again.
When you are using PIE, the way to do the same thing is to increase the
value subtraced from exe_end to compute exe_base in line 272 of
coregrind/stage1.c
Good luck,
Meir=20
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of
Christoph Bartoschek
Sent: Tuesday, September 06, 2005 11:06 AM
To: val...@li...
Subject: [Valgrind-users] newSuperblock's request for 1048576 bytes
failed with valgrind 3.0.1
Hi,
I have another report about problems with memory. Is there anything one
could=20
try to get rid of this? Should I send you more debug information? This
error=20
comes when we use --enable-pie and when we do not use this option:
VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes
failed.
VG_(get_memory_from_mmap): 256366456 bytes already allocated.
Sorry. You could try using a tool that uses less memory;
eg. addrcheck instead of memcheck.
---- Debugging information follows --------
Valgrind's range is: 0xB0000000 .. 0xBFFFFFFF
<<< SHOW_SEGMENTS: VG_(get_memory_from_mmap) failure (56 segments, 13=20
segnames)
( 0) /usr/local/opt/i386-20050729/lib/valgrind/stage2
( 1) /lib/ld-2.3.4.so
( 2) /lib/libdl.so.2
( 3) /lib/tls/libc.so.6
( 4) /usr/local/opt/i386-20050729/lib/valgrind/vgtool_memcheck.so
( 5)
/lfs/user/peyer/vlsi/xr_050819.restrict/trunk/xrslocl2/bin/mem-dbg.32bit
/bonnRouteLocalN
( 6) /usr/local/opt/i386-20050729/lib/valgrind/vg_preload_core.so
( 7) /usr/local/opt/i386-20050729/lib/valgrind/vgpreload_memcheck.so
( 8) /var/run/nscd/passwd
( 9) /lib/tls/libpthread.so.0
(10) /usr/local/opt/i386-20050729/gcc/lib/libstdc++.so.6.0.3
(11) /lib/tls/libm.so.6
(12) /usr/local/opt/i386-20050729/gcc/lib/libgcc_s.so.1
0: 0x08048000-0x081A6000 1433600 pr=3D0x5 fl=3D0x020C d=3D0x023 =
i=3D275865
o=3D0 =20
(5)
1: 0x081A6000-0x082F2000 1359872 pr=3D0x7 fl=3D0x000C d=3D0x023 =
i=3D275865 =20
o=3D1433600 (5)
2: 0x082F2000-0x08809000 5337088 pr=3D0x7 fl=3D0x0004 d=3D0x000 i=3D0
o=3D0 =20
(-1)
3: 0x1B8E4000-0x1B8FA000 90112 pr=3D0x5 fl=3D0x020C d=3D0x803 =
i=3D2445991
o=3D0 =20
(1)
4: 0x1B8FA000-0x1B8FC000 8192 pr=3D0x7 fl=3D0x000C d=3D0x803 =
i=3D2445991
o=3D86016 =20
(1)
5: 0x1B8FC000-0x1B8FD000 4096 pr=3D0x3 fl=3D0x0004 d=3D0x000 i=3D0
o=3D0 =20
(-1)
6: 0x1B8FD000-0x1B8FE000 4096 pr=3D0x5 fl=3D0x020C d=3D0x025 =
i=3D400002
o=3D0 =20
(6)
7: 0x1B8FE000-0x1B8FF000 4096 pr=3D0x3 fl=3D0x000C d=3D0x025 =
i=3D400002
o=3D0 =20
(6)
8: 0x1B8FF000-0x1B904000 20480 pr=3D0x5 fl=3D0x020C d=3D0x025 =
i=3D400011
o=3D0 =20
(7)
9: 0x1B904000-0x1B905000 4096 pr=3D0x3 fl=3D0x000C d=3D0x025 =
i=3D400011
o=3D16384 =20
(7)
10: 0x1B905000-0x1B909000 16384 pr=3D0x3 fl=3D0x0004 d=3D0x000 i=3D0
o=3D0 =20
(-1)
11: 0x1B919000-0x1B927000 57344 pr=3D0x5 fl=3D0x020C d=3D0x803 =
i=3D2448457
o=3D0 =20
(9)
12: 0x1B927000-0x1B929000 8192 pr=3D0x3 fl=3D0x000C d=3D0x803 =
i=3D2448457
o=3D53248 =20
(9)
13: 0x1B929000-0x1B92B000 8192 pr=3D0x3 fl=3D0x0004 d=3D0x000 i=3D0
o=3D0 =20
(-1)
14: 0x1B92B000-0x1B9F1000 811008 pr=3D0x5 fl=3D0x020C d=3D0x025 =
i=3D482689
o=3D0 =20
(10)
15: 0x1B9F1000-0x1B9F6000 20480 pr=3D0x3 fl=3D0x000C d=3D0x025 =
i=3D482689
o=3D806912 =20
(10)
16: 0x1B9F6000-0x1B9FB000 20480 pr=3D0x3 fl=3D0x0004 d=3D0x000 i=3D0
o=3D0 =20
(-1)
17: 0x1B9FB000-0x1BA1C000 135168 pr=3D0x5 fl=3D0x020C d=3D0x803 =
i=3D2448456
o=3D0 =20
(11)
18: 0x1BA1C000-0x1BA1E000 8192 pr=3D0x3 fl=3D0x000C d=3D0x803 =
i=3D2448456
o=3D131072 =20
(11)
19: 0x1BA1E000-0x1BA26000 32768 pr=3D0x5 fl=3D0x020C d=3D0x025 =
i=3D482685
o=3D0 =20
(12)
20: 0x1BA26000-0x1BA27000 4096 pr=3D0x3 fl=3D0x000C d=3D0x025 =
i=3D482685
o=3D28672 =20
(12)
21: 0x1BA27000-0x1BA28000 4096 pr=3D0x3 fl=3D0x0004 d=3D0x000 i=3D0
o=3D0 =20
(-1)
22: 0x1BA28000-0x1BB3B000 1126400 pr=3D0x5 fl=3D0x020C d=3D0x803 =
i=3D2448455
o=3D0 =20
(3)
23: 0x1BB3B000-0x1BB3C000 4096 pr=3D0x1 fl=3D0x000C d=3D0x803 =
i=3D2448455=20
o=3D1126400 (3)
24: 0x1BB3C000-0x1BB3F000 12288 pr=3D0x3 fl=3D0x000C d=3D0x803 =
i=3D2448455=20
o=3D1130496 (3)
25: 0x1BB3F000-0x1BB41000 8192 pr=3D0x3 fl=3D0x0004 d=3D0x000 i=3D0
o=3D0 =20
(-1)
26: 0x1BB41000-0x1BB43000 8192 pr=3D0x5 fl=3D0x020C d=3D0x803 =
i=3D2448447
o=3D0 =20
(2)
27: 0x1BB43000-0x1BB45000 8192 pr=3D0x3 fl=3D0x000C d=3D0x803 =
i=3D2448447
o=3D4096 =20
(2)
28: 0x1BB45000-0x1BB46000 4096 pr=3D0x3 fl=3D0x0004 d=3D0x000 i=3D0
o=3D0 =20
(-1)
29: 0x1BB46000-0x1BD46000 2097152 pr=3D0x7 fl=3D0x0084 d=3D0x000 i=3D0
o=3D0 =20
(-1)
30: 0x1BD46000-0x1BD7B000 217088 pr=3D0x1 fl=3D0x000D d=3D0x803 =
i=3D2349199
o=3D0 =20
(8)
31: 0x1BD7B000-0x3E68F000 579944448 pr=3D0x7 fl=3D0x0084 d=3D0x000 =
i=3D0
o=3D0 =20
(-1)
32: 0x52BE2000-0x52C00000 122880 pr=3D0x7 fl=3D0x0034 d=3D0x000 i=3D0
o=3D0 =20
(-1)
33: 0x52C00000-0xB0000000 1564475392 pr=3D0x0 fl=3D0x0004 d=3D0x000 =
i=3D0
o=3D0 =20
(-1)
34: 0xB0000000-0xB0132000 1253376 pr=3D0x5 fl=3D0x020C d=3D0x025 =
i=3D400001
o=3D0 =20
(0)
35: 0xB0132000-0xB0133000 4096 pr=3D0x7 fl=3D0x000C d=3D0x025 =
i=3D400001 =20
o=3D1249280 (0)
36: 0xB0133000-0xB0A1F000 9355264 pr=3D0x7 fl=3D0x0004 d=3D0x000 i=3D0
o=3D0 =20
(-1)
37: 0xB0A1F000-0xB0B1F000 1048576 pr=3D0x7 fl=3D0x0104 d=3D0x000 i=3D0 =
=20
o=3D2097152 (-1)
38: 0xB0B1F000-0xB0B20000 4096 pr=3D0x0 fl=3D0x0104 d=3D0x000 i=3D0
o=3D0 =20
(-1)
39: 0xB0B20000-0xB0B30000 65536 pr=3D0x3 fl=3D0x0104 d=3D0x000 i=3D0
o=3D4096 =20
(-1)
40: 0xB0B30000-0xB0D73000 2371584 pr=3D0x7 fl=3D0x0104 d=3D0x000 i=3D0
o=3D0 =20
(-1)
41: 0xB0D7C000-0xB0FEC000 2555904 pr=3D0x7 fl=3D0x0104 d=3D0x000 i=3D0
o=3D0 =20
(-1)
42: 0xB1000000-0xB1016000 90112 pr=3D0x5 fl=3D0x000C d=3D0x803 =
i=3D2445991
o=3D0 =20
(1)
43: 0xB1016000-0xB1018000 8192 pr=3D0x7 fl=3D0x000C d=3D0x803 =
i=3D2445991
o=3D86016 =20
(1)
44: 0xB1018000-0xB1019000 4096 pr=3D0x7 fl=3D0x0004 d=3D0x000 i=3D0
o=3D0 =20
(-1)
45: 0xB102D000-0xB102F000 8192 pr=3D0x5 fl=3D0x000C d=3D0x803 =
i=3D2448447
o=3D0 =20
(2)
46: 0xB102F000-0xB1031000 8192 pr=3D0x7 fl=3D0x000C d=3D0x803 =
i=3D2448447
o=3D4096 =20
(2)
47: 0xB1031000-0xB1145000 1130496 pr=3D0x5 fl=3D0x000C d=3D0x803 =
i=3D2448455
o=3D0 =20
(3)
48: 0xB1145000-0xB1148000 12288 pr=3D0x7 fl=3D0x000C d=3D0x803 =
i=3D2448455=20
o=3D1130496 (3)
49: 0xB1148000-0xB124B000 1060864 pr=3D0x7 fl=3D0x0004 d=3D0x000 i=3D0
o=3D0 =20
(-1)
50: 0xB124B000-0xB1266000 110592 pr=3D0x5 fl=3D0x000C d=3D0x025 =
i=3D400010
o=3D0 =20
(4)
51: 0xB1266000-0xB1267000 4096 pr=3D0x7 fl=3D0x000C d=3D0x025 =
i=3D400010
o=3D110592 =20
(4)
52: 0xB1267000-0xB1304000 643072 pr=3D0x7 fl=3D0x0004 d=3D0x000 i=3D0
o=3D0 =20
(-1)
53: 0xB1304000-0xBFFCF000 248295424 pr=3D0x7 fl=3D0x0104 d=3D0x000 =
i=3D0
o=3D0 =20
(-1)
54: 0xBFFEA000-0xC0000000 90112 pr=3D0x7 fl=3D0x0004 d=3D0x000 i=3D0
o=3D0 =20
(-1)
55: 0xFFFFE000-0xFFFFF000 4096 pr=3D0x0 fl=3D0x0004 d=3D0x000 i=3D0
o=3D0 =20
(-1)
>>>
-------------------------------------------------------
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: Christoph B. <bar...@or...> - 2005-09-06 08:05:53
|
Hi, I have another report about problems with memory. Is there anything one could try to get rid of this? Should I send you more debug information? This error comes when we use --enable-pie and when we do not use this option: VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes failed. VG_(get_memory_from_mmap): 256366456 bytes already allocated. Sorry. You could try using a tool that uses less memory; eg. addrcheck instead of memcheck. ---- Debugging information follows -------- Valgrind's range is: 0xB0000000 .. 0xBFFFFFFF <<< SHOW_SEGMENTS: VG_(get_memory_from_mmap) failure (56 segments, 13 segnames) ( 0) /usr/local/opt/i386-20050729/lib/valgrind/stage2 ( 1) /lib/ld-2.3.4.so ( 2) /lib/libdl.so.2 ( 3) /lib/tls/libc.so.6 ( 4) /usr/local/opt/i386-20050729/lib/valgrind/vgtool_memcheck.so ( 5) /lfs/user/peyer/vlsi/xr_050819.restrict/trunk/xrslocl2/bin/mem-dbg.32bit/bonnRouteLocalN ( 6) /usr/local/opt/i386-20050729/lib/valgrind/vg_preload_core.so ( 7) /usr/local/opt/i386-20050729/lib/valgrind/vgpreload_memcheck.so ( 8) /var/run/nscd/passwd ( 9) /lib/tls/libpthread.so.0 (10) /usr/local/opt/i386-20050729/gcc/lib/libstdc++.so.6.0.3 (11) /lib/tls/libm.so.6 (12) /usr/local/opt/i386-20050729/gcc/lib/libgcc_s.so.1 0: 0x08048000-0x081A6000 1433600 pr=0x5 fl=0x020C d=0x023 i=275865 o=0 (5) 1: 0x081A6000-0x082F2000 1359872 pr=0x7 fl=0x000C d=0x023 i=275865 o=1433600 (5) 2: 0x082F2000-0x08809000 5337088 pr=0x7 fl=0x0004 d=0x000 i=0 o=0 (-1) 3: 0x1B8E4000-0x1B8FA000 90112 pr=0x5 fl=0x020C d=0x803 i=2445991 o=0 (1) 4: 0x1B8FA000-0x1B8FC000 8192 pr=0x7 fl=0x000C d=0x803 i=2445991 o=86016 (1) 5: 0x1B8FC000-0x1B8FD000 4096 pr=0x3 fl=0x0004 d=0x000 i=0 o=0 (-1) 6: 0x1B8FD000-0x1B8FE000 4096 pr=0x5 fl=0x020C d=0x025 i=400002 o=0 (6) 7: 0x1B8FE000-0x1B8FF000 4096 pr=0x3 fl=0x000C d=0x025 i=400002 o=0 (6) 8: 0x1B8FF000-0x1B904000 20480 pr=0x5 fl=0x020C d=0x025 i=400011 o=0 (7) 9: 0x1B904000-0x1B905000 4096 pr=0x3 fl=0x000C d=0x025 i=400011 o=16384 (7) 10: 0x1B905000-0x1B909000 16384 pr=0x3 fl=0x0004 d=0x000 i=0 o=0 (-1) 11: 0x1B919000-0x1B927000 57344 pr=0x5 fl=0x020C d=0x803 i=2448457 o=0 (9) 12: 0x1B927000-0x1B929000 8192 pr=0x3 fl=0x000C d=0x803 i=2448457 o=53248 (9) 13: 0x1B929000-0x1B92B000 8192 pr=0x3 fl=0x0004 d=0x000 i=0 o=0 (-1) 14: 0x1B92B000-0x1B9F1000 811008 pr=0x5 fl=0x020C d=0x025 i=482689 o=0 (10) 15: 0x1B9F1000-0x1B9F6000 20480 pr=0x3 fl=0x000C d=0x025 i=482689 o=806912 (10) 16: 0x1B9F6000-0x1B9FB000 20480 pr=0x3 fl=0x0004 d=0x000 i=0 o=0 (-1) 17: 0x1B9FB000-0x1BA1C000 135168 pr=0x5 fl=0x020C d=0x803 i=2448456 o=0 (11) 18: 0x1BA1C000-0x1BA1E000 8192 pr=0x3 fl=0x000C d=0x803 i=2448456 o=131072 (11) 19: 0x1BA1E000-0x1BA26000 32768 pr=0x5 fl=0x020C d=0x025 i=482685 o=0 (12) 20: 0x1BA26000-0x1BA27000 4096 pr=0x3 fl=0x000C d=0x025 i=482685 o=28672 (12) 21: 0x1BA27000-0x1BA28000 4096 pr=0x3 fl=0x0004 d=0x000 i=0 o=0 (-1) 22: 0x1BA28000-0x1BB3B000 1126400 pr=0x5 fl=0x020C d=0x803 i=2448455 o=0 (3) 23: 0x1BB3B000-0x1BB3C000 4096 pr=0x1 fl=0x000C d=0x803 i=2448455 o=1126400 (3) 24: 0x1BB3C000-0x1BB3F000 12288 pr=0x3 fl=0x000C d=0x803 i=2448455 o=1130496 (3) 25: 0x1BB3F000-0x1BB41000 8192 pr=0x3 fl=0x0004 d=0x000 i=0 o=0 (-1) 26: 0x1BB41000-0x1BB43000 8192 pr=0x5 fl=0x020C d=0x803 i=2448447 o=0 (2) 27: 0x1BB43000-0x1BB45000 8192 pr=0x3 fl=0x000C d=0x803 i=2448447 o=4096 (2) 28: 0x1BB45000-0x1BB46000 4096 pr=0x3 fl=0x0004 d=0x000 i=0 o=0 (-1) 29: 0x1BB46000-0x1BD46000 2097152 pr=0x7 fl=0x0084 d=0x000 i=0 o=0 (-1) 30: 0x1BD46000-0x1BD7B000 217088 pr=0x1 fl=0x000D d=0x803 i=2349199 o=0 (8) 31: 0x1BD7B000-0x3E68F000 579944448 pr=0x7 fl=0x0084 d=0x000 i=0 o=0 (-1) 32: 0x52BE2000-0x52C00000 122880 pr=0x7 fl=0x0034 d=0x000 i=0 o=0 (-1) 33: 0x52C00000-0xB0000000 1564475392 pr=0x0 fl=0x0004 d=0x000 i=0 o=0 (-1) 34: 0xB0000000-0xB0132000 1253376 pr=0x5 fl=0x020C d=0x025 i=400001 o=0 (0) 35: 0xB0132000-0xB0133000 4096 pr=0x7 fl=0x000C d=0x025 i=400001 o=1249280 (0) 36: 0xB0133000-0xB0A1F000 9355264 pr=0x7 fl=0x0004 d=0x000 i=0 o=0 (-1) 37: 0xB0A1F000-0xB0B1F000 1048576 pr=0x7 fl=0x0104 d=0x000 i=0 o=2097152 (-1) 38: 0xB0B1F000-0xB0B20000 4096 pr=0x0 fl=0x0104 d=0x000 i=0 o=0 (-1) 39: 0xB0B20000-0xB0B30000 65536 pr=0x3 fl=0x0104 d=0x000 i=0 o=4096 (-1) 40: 0xB0B30000-0xB0D73000 2371584 pr=0x7 fl=0x0104 d=0x000 i=0 o=0 (-1) 41: 0xB0D7C000-0xB0FEC000 2555904 pr=0x7 fl=0x0104 d=0x000 i=0 o=0 (-1) 42: 0xB1000000-0xB1016000 90112 pr=0x5 fl=0x000C d=0x803 i=2445991 o=0 (1) 43: 0xB1016000-0xB1018000 8192 pr=0x7 fl=0x000C d=0x803 i=2445991 o=86016 (1) 44: 0xB1018000-0xB1019000 4096 pr=0x7 fl=0x0004 d=0x000 i=0 o=0 (-1) 45: 0xB102D000-0xB102F000 8192 pr=0x5 fl=0x000C d=0x803 i=2448447 o=0 (2) 46: 0xB102F000-0xB1031000 8192 pr=0x7 fl=0x000C d=0x803 i=2448447 o=4096 (2) 47: 0xB1031000-0xB1145000 1130496 pr=0x5 fl=0x000C d=0x803 i=2448455 o=0 (3) 48: 0xB1145000-0xB1148000 12288 pr=0x7 fl=0x000C d=0x803 i=2448455 o=1130496 (3) 49: 0xB1148000-0xB124B000 1060864 pr=0x7 fl=0x0004 d=0x000 i=0 o=0 (-1) 50: 0xB124B000-0xB1266000 110592 pr=0x5 fl=0x000C d=0x025 i=400010 o=0 (4) 51: 0xB1266000-0xB1267000 4096 pr=0x7 fl=0x000C d=0x025 i=400010 o=110592 (4) 52: 0xB1267000-0xB1304000 643072 pr=0x7 fl=0x0004 d=0x000 i=0 o=0 (-1) 53: 0xB1304000-0xBFFCF000 248295424 pr=0x7 fl=0x0104 d=0x000 i=0 o=0 (-1) 54: 0xBFFEA000-0xC0000000 90112 pr=0x7 fl=0x0004 d=0x000 i=0 o=0 (-1) 55: 0xFFFFE000-0xFFFFF000 4096 pr=0x0 fl=0x0004 d=0x000 i=0 o=0 (-1) >>> |
|
From: Tom H. <to...@co...> - 2005-09-05 07:38:06
|
In message <200...@li...>
Jose Reis <jr...@cr...> wrote:
> 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=20
> ./configure CFLAGS=3D-m32 CPPFLAGS=3D-m32 CCASFLAGS=3D-m32
> -prefix=3D/home/jreis/valgrind/
That won't work as the configure script won't know you are building
for a 32 bit platform so won't select the right platform specific
code.
If you want to build a 32 bit version on a 64 bit machine you should
use the --host switch to configure (and use valgrind 3.0.1 as it is
broken in the 3.0.0 release).
>=20=20
> Since this approach was not working, I tested the suggestion which was se=
nt
> to this mailing list by Julian Seward on 2005-08-03 17:19:
> =C2=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
> =C2=94
That is the easiest way to do it.
> 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=20
> Then I copy it to the 64 bit machine, but when I ran =C2=91make install=
=C2=92 I got
> the following error:
You almost certainly need to do the make install on the 32 bit machine
and then copy the installed binaries over. I normally do it by building
a 32 bit RPM on a 32 bit machine and then installing it on a 64 bit machine.
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jose R. <jr...@cr...> - 2005-09-05 07:19:19
|
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: Mohan N. <moh...@th...> - 2005-09-04 06:54:41
|
LeCiCeAmP= rViUlXaVaMe viallebiopagtrnaliri traisbrexeneciaraamxumdia $1 $3= $3 21.33.= 75 http://www.showisnohit.com It seemed to the procurator that a rosy smell = exuded from the cypresses Procurator, that it will cause a very great scandal. |
|
From: Dirk M. <dm...@gm...> - 2005-09-03 19:51:47
|
On Thursday 01 September 2005 05:19, Yuri wrote: > KCachegrind asks me when I click on Assembler tab (3.4.2 -- last stable > version) > cachegrind in valgrind-3.0.1 doesn't have such options. (3.0.1 -- last > stable version) you have to install the callgrind tool from the kcachegrind.sf.net home page. And no, it doesn't work with valgrind 3.x yet. Dirk |
|
From: Neal N. <nno...@gm...> - 2005-09-03 16:20:24
|
On 9/2/05, Yeshurun, Meir <mei...@in...> wrote: > I once had a similar problem, and just repeating the entire installation > process (including downloading the tar...) solved it, so it's worth a > try. Weird. I skipped a few steps. I just did a make clean; make ; make install and it did fix the problem. I then did rm -rf valgrind-3.0.1 ; tar xvjf val*bz2 ; cd val*.0.1 ; ./configure ; make ; make install and that also worked. I did not remove the installed files for either of these runs. I did a make clean ; make ; make install again and it still works. So I can't reproduce the problem, so I'm not sure a bug report is worthwhile. Let me know if there are other things someone wants me to try to reproduce this problem. I'm happy, but I wonder if there's something strange going on that could be fixed. BTW, this is a gentoo box in case you missed it on the uname output. I'm happy. Thanks! n |
|
From: Yeshurun, M. <mei...@in...> - 2005-09-03 15:58:30
|
In case it wasn't clear, I wasn't complaining, but merely pointing this out in case you hadn't noticed, for the benefit of other users. That would not have been my next question. Regards, Meir=20 -----Original Message----- From: Nicholas Nethercote [mailto:nj...@cs...]=20 Sent: Saturday, September 03, 2005 5:41 PM To: Yeshurun, Meir Cc: Tom Hughes; val...@li... Subject: RE: [Valgrind-users] Copying undefined floating point values On Sat, 3 Sep 2005, Yeshurun, Meir wrote: > But I think you should erase these lines from the end of section 3.5.1 > in the user manual: > > "Memcheck is more simplistic about floating-point loads and stores. In > particular, V bits for data read as a result of floating-point loads are > checked at the load instruction. So if your program uses the > floating-point registers to do memory-to-memory copies, you will get > complaints about uninitialised values. Fortunately, I have not yet > encountered a program which (ab)uses the floating-point registers in > this way." Those lines and related ones have been updated in the 3.0.1 docs. The=20 website is still showing the 3.0.0 docs. In answer to your next question,=20 yes it would be nice to have the latest docs on the website but it's a=20 matter of someone finding the time to do it. Nick |
|
From: Nicholas N. <nj...@cs...> - 2005-09-03 14:41:07
|
On Sat, 3 Sep 2005, Yeshurun, Meir wrote: > But I think you should erase these lines from the end of section 3.5.1 > in the user manual: > > "Memcheck is more simplistic about floating-point loads and stores. In > particular, V bits for data read as a result of floating-point loads are > checked at the load instruction. So if your program uses the > floating-point registers to do memory-to-memory copies, you will get > complaints about uninitialised values. Fortunately, I have not yet > encountered a program which (ab)uses the floating-point registers in > this way." Those lines and related ones have been updated in the 3.0.1 docs. The website is still showing the 3.0.0 docs. In answer to your next question, yes it would be nice to have the latest docs on the website but it's a matter of someone finding the time to do it. Nick |
|
From: Yeshurun, M. <mei...@in...> - 2005-09-03 06:31:09
|
I once had a similar problem, and just repeating the entire installation process (including downloading the tar...) solved it, so it's worth a try. Regards, Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Neal Norwitz Sent: Saturday, September 03, 2005 8:05 AM To: val...@li... Subject: [Valgrind-users] segv on amd64 w/3.0.1 I was very happy to see that valgrind was released with amd64 support. I had gone away for a while and it was a nice surprise that 3.0 had come out. Unfortunately, I can't even run ls under valgrind without a segv. Any suggestions? Any other info you can use? gcc =3D=3D 3.3.4 Is it correct that the version is valgrind-3.0.0.SVN or should that be 3.0.1? I verified that the md5sum is the same as 3.0.1 on the web. glibc seems to be 2.3.4. Thanks, n -- $ ~/local/bin/valgrind ls =3D=3D3039=3D=3D Memcheck, a memory error detector. =3D=3D3039=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian = Seward et al. =3D=3D3039=3D=3D Using LibVEX rev 1117M, a library for dynamic binary translation. =3D=3D3039=3D=3D Copyright (C) 2004, and GNU GPL'd, by OpenWorks LLP. =3D=3D3039=3D=3D Using valgrind-3.0.0.SVN, a dynamic binary = instrumentation framework. =3D=3D3039=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian = Seward et al. Segmentation fault (core dumped) $ uname -a Linux janus 2.6.8-gentoo-r4 #4 SMP Thu Oct 7 17:40:27 EDT 2004 x86_64 AMD Opteron(tm) Processor 242 AuthenticAMD GNU/Linux $ md5sum ../valgrind-3.0.1.tar.bz2 c29efdb7d1a93440f5644a6769054681 ../valgrind-3.0.1.tar.bz2 ------------------------------------------------------- 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 |