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
|
|
2
(3) |
3
(14) |
4
(33) |
5
(1) |
6
(11) |
7
(4) |
8
(3) |
|
9
|
10
(13) |
11
(23) |
12
(4) |
13
(4) |
14
(7) |
15
(1) |
|
16
|
17
(29) |
18
(24) |
19
(5) |
20
(8) |
21
(8) |
22
(3) |
|
23
|
24
(1) |
25
(9) |
26
(4) |
27
(8) |
28
(7) |
29
(5) |
|
30
(6) |
31
(3) |
|
|
|
|
|
|
From: Barry C. <che...@ya...> - 2005-10-11 09:57:19
|
--- Tom Hughes <to...@co...> wrote:
> In message
>
<200...@we...>
> Barry Clarkson <che...@ya...>
> wrote:
>
> > stat("/develop/home/clarksob/socktest",
> 0xffffa8c0) =
> > -1 EOVERFLOW (Value too large for defined data
> type)
> > write(1016, "--", 2--) = 2
> > getpid() = 9989
> > write(1016, "9989-- ", 79989-- ) = 7
> > write(1016, "Can\'t stat .so/.exe (to
> determin"...,
> > 45Can't stat .so/.exe (to determine its size)?!) =
> 45
> > write(1016, "\n", 1
> >
> > File: `socktest'
> > Size: 8920 Blocks: 18 IO
> Block:
> > 1024 regular file
> > Device: ff0c788h/267437960d Inode: 7639
> > Links: 1
> > Access: (0755/-rwxr-xr-x) Uid: (11120/clarksob)
> > Gid: ( 409/ bil)
> > Access: 2005-10-11 10:08:59.876385000 +0100
> > Modify: 2005-10-11 09:15:25.731221000 +0100
> > Change: 2005-10-11 09:15:25.731256000 +0100
>
> Although I can't actually find the code path in the
> kernel that
> would cause this I think the problem is the device
> number - that
> is a device number of 199:65416 which can't be
> encoded using the
> old device encoding that only supports major and
> minor devices
> up to 255.
>
Thanks for the input. I realised that the executable
resides on EMC storage. When I moved it to a local
internal disk the device number was much smaller and
valgrind worked!
> Older versions of the stat call only return such
> numbers and there
> are various places in the kernel that return
> EOVERFLOW if the device
> won't fit using the old encoding.
>
> It's possible that making valgrind use stat64 on 32
> bit systems
> might work around this but the first thing you need
> to do is to
> try a current version of valgrind really.
>
The same problem occurs with version 3.0.1 - but not
if you move the exe to a local disk.
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://www.compton.nu/
>
>
>
-------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content,
> downloads, discussions,
> and more.
> http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
>
https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
|
|
From: Tom H. <to...@co...> - 2005-10-11 09:42:53
|
In message <200...@we...>
Barry Clarkson <che...@ya...> wrote:
> stat("/develop/home/clarksob/socktest", 0xffffa8c0) =
> -1 EOVERFLOW (Value too large for defined data type)
> write(1016, "--", 2--) = 2
> getpid() = 9989
> write(1016, "9989-- ", 79989-- ) = 7
> write(1016, "Can\'t stat .so/.exe (to determin"...,
> 45Can't stat .so/.exe (to determine its size)?!) = 45
> write(1016, "\n", 1
>
> File: `socktest'
> Size: 8920 Blocks: 18 IO Block:
> 1024 regular file
> Device: ff0c788h/267437960d Inode: 7639
> Links: 1
> Access: (0755/-rwxr-xr-x) Uid: (11120/clarksob)
> Gid: ( 409/ bil)
> Access: 2005-10-11 10:08:59.876385000 +0100
> Modify: 2005-10-11 09:15:25.731221000 +0100
> Change: 2005-10-11 09:15:25.731256000 +0100
Although I can't actually find the code path in the kernel that
would cause this I think the problem is the device number - that
is a device number of 199:65416 which can't be encoded using the
old device encoding that only supports major and minor devices
up to 255.
Older versions of the stat call only return such numbers and there
are various places in the kernel that return EOVERFLOW if the device
won't fit using the old encoding.
It's possible that making valgrind use stat64 on 32 bit systems
might work around this but the first thing you need to do is to
try a current version of valgrind really.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Barry C. <che...@ya...> - 2005-10-11 09:12:20
|
stat("/develop/home/clarksob/socktest", 0xffffa8c0) =
-1 EOVERFLOW (Value too large for defined data type)
write(1016, "--", 2--) = 2
getpid() = 9989
write(1016, "9989-- ", 79989-- ) = 7
write(1016, "Can\'t stat .so/.exe (to determin"...,
45Can't stat .so/.exe (to determine its size)?!) = 45
write(1016, "\n", 1
File: `socktest'
Size: 8920 Blocks: 18 IO Block:
1024 regular file
Device: ff0c788h/267437960d Inode: 7639
Links: 1
Access: (0755/-rwxr-xr-x) Uid: (11120/clarksob)
Gid: ( 409/ bil)
Access: 2005-10-11 10:08:59.876385000 +0100
Modify: 2005-10-11 09:15:25.731221000 +0100
Change: 2005-10-11 09:15:25.731256000 +0100
--- Igmar Palsenberg <mai...@jd...> wrote:
>
> > We are trying to use valgrind on a new machine and
> > when valgrind runs it can't stat the exe even
> though
> > it runs the program successfully. Any help would
> be
> > greatly appreciated.
>
> What does stat /develop/home/clarksob/socktest say ?
>
>
>
> Igmar
>
>
>
-------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content,
> downloads, discussions,
> and more.
> http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
>
https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
|
|
From: Tom H. <to...@co...> - 2005-10-11 09:04:49
|
In message <200...@we...>
Barry Clarkson <che...@ya...> wrote:
> We are trying to use valgrind on a new machine and
> when valgrind runs it can't stat the exe even though
> it runs the program successfully. Any help would be
> greatly appreciated.
Well can you ls -l the file in question?
My suspicion is that you have search (x) permission on the
directory in question but not read (r) permission so you can
find the file and read it but you can't read it's directory
information.
Otherwise try stracing valgrind and looking for stat calls
on that file and see what the error is.
> valgrind-2.2.0
That's rather old - is there a reason for not using a more
recent version?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Igmar P. <mai...@jd...> - 2005-10-11 08:58:46
|
> We are trying to use valgrind on a new machine and > when valgrind runs it can't stat the exe even though > it runs the program successfully. Any help would be > greatly appreciated. What does stat /develop/home/clarksob/socktest say ? Igmar |
|
From: Barry C. <che...@ya...> - 2005-10-11 08:17:59
|
We are trying to use valgrind on a new machine and when valgrind runs it can't stat the exe even though it runs the program successfully. Any help would be greatly appreciated. Cheers, Barry Linux harpo 2.6.9-11.ELsmp #1 SMP Fri May 20 18:25:30 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux /usr/bin/valgrind: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, statically linked, not stripped valgrind-2.2.0 $ cc -m32 -g -o socktest socktest.c $ valgrind --tool=memcheck -v socktest ==4836== Memcheck, a memory error detector for x86-linux. ==4836== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==4836== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==4836== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==4836== Valgrind library directory: /usr/lib/valgrind ==4836== Command line ==4836== socktest ==4836== Startup, with flags: ==4836== --tool=memcheck ==4836== -v ==4836== Contents of /proc/version: ==4836== Linux version 2.6.9-11.ELsmp (bhc...@cr...) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22)) #1 SMP Fri May 20 18:25:30 EDT 2005 ==4836== Reading syms from /develop/home/clarksob/socktest (0x8048000) ==4836== Can't stat .so/.exe (to determine its size)?! ==4836== Reading syms from /develop/home/clarksob/socktest (0x8049000) ==4836== Can't stat .so/.exe (to determine its size)?! ==4836== Reading syms from /lib/ld-2.3.4.so (0x1B8E4000) ==4836== object doesn't have any debug info ==4836== Reading syms from /usr/lib/valgrind/stage2 (0xB0000000) ==4836== Reading syms from /lib/ld-2.3.4.so (0xB1000000) ==4836== object doesn't have any debug info ==4836== Reading syms from /usr/lib/valgrind/vgskin_memcheck.so (0xF7C7D000) ==4836== Reading syms from /lib/tls/libc-2.3.4.so (0xF7EA6000) ==4836== object doesn't have any debug info ==4836== Reading syms from /lib/libdl-2.3.4.so (0xF7FD0000) ==4836== object doesn't have any debug info ==4836== Reading suppressions file: /usr/lib/valgrind/default.supp ==4836== REDIRECT soname:libc.so.6(__GI___errno_location) to soname:libpthread.so.0(__errno_location) ==4836== REDIRECT soname:libc.so.6(__errno_location) to soname:libpthread.so.0(__errno_location) ==4836== REDIRECT soname:libc.so.6(__GI___h_errno_location) to soname:libpthread.so.0(__h_errno_location) ==4836== REDIRECT soname:libc.so.6(__h_errno_location) to soname:libpthread.so.0(__h_errno_location) ==4836== REDIRECT soname:libc.so.6(__GI___res_state) to soname:libpthread.so.0(__res_state) ==4836== REDIRECT soname:libc.so.6(__res_state) to soname:libpthread.so.0(__res_state) ==4836== REDIRECT soname:libc.so.6(stpcpy) to *vgpreload_memcheck.so*(stpcpy) ==4836== REDIRECT soname:libc.so.6(strnlen) to *vgpreload_memcheck.so*(strnlen) ==4836== REDIRECT soname:ld-linux.so.2(stpcpy) to *vgpreload_memcheck.so*(stpcpy) ==4836== REDIRECT soname:ld-linux.so.2(strchr) to *vgpreload_memcheck.so*(strchr) ==4836== ==4836== Reading syms from /usr/lib/valgrind/vg_inject.so (0x1B8FC000) ==4836== Reading syms from /usr/lib/valgrind/vgpreload_memcheck.so (0x1B901000) ==4836== TRANSLATE: 0x1B8F5EE0 redirected to 0x1B904100 ==4836== Reading syms from /lib/tls/libc-2.3.4.so (0x181000) ==4836== object doesn't have any debug info ==4836== TRANSLATE: 0x1B8E47A0 redirected to 0x52BFF040 Socket created ==4836== Syscall param socketcall.bind(my_addr.) contains uninitialised or unaddressable byte(s) ==4836== at 0x248AB7: bind (in /lib/tls/libc-2.3.4.so) ==4836== by 0x195E22: __libc_start_main (in /lib/tls/libc-2.3.4.so) ==4836== by 0x80484C0: (within /develop/home/clarksob/socktest) ==4836== Address 0x52BFBAA1 is on thread 1's stack Bound to local socket with address ==4836== ==4836== Syscall param socketcall.connect(serv_addr.) contains uninitialised or unaddressable byte(s) ==4836== at 0x248B01: __connect_internal (in /lib/tls/libc-2.3.4.so) ==4836== by 0x195E22: __libc_start_main (in /lib/tls/libc-2.3.4.so) ==4836== by 0x80484C0: (within /develop/home/clarksob/socktest) ==4836== Address 0x52BFBA71 is on thread 1's stack Error: Connect to address failed ==4836== TRANSLATE: 0x1EB090 redirected to 0x1B9046F4 Error: (101, Network is unreachable) ==4836== TRANSLATE: 0x1E2DB0 redirected to 0x1B904E24 ==4836== ==4836== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 12 from 1) ==4836== ==4836== 1 errors in context 1 of 2: ==4836== Syscall param socketcall.connect(serv_addr.) contains uninitialised or unaddressable byte(s) ==4836== at 0x248B01: __connect_internal (in /lib/tls/libc-2.3.4.so) ==4836== by 0x195E22: __libc_start_main (in /lib/tls/libc-2.3.4.so) ==4836== by 0x80484C0: (within /develop/home/clarksob/socktest) ==4836== Address 0x52BFBA71 is on thread 1's stack ==4836== ==4836== 1 errors in context 2 of 2: ==4836== Syscall param socketcall.connect(serv_addr.) contains uninitialised or unaddressable byte(s) ==4836== at 0x248AB7: bind (in /lib/tls/libc-2.3.4.so) ==4836== by 0x195E22: __libc_start_main (in /lib/tls/libc-2.3.4.so) ==4836== by 0x80484C0: (within /develop/home/clarksob/socktest) ==4836== Address 0x52BFBAA1 is on thread 1's stack --4836-- --4836-- supp: 12 dl_relocate_object/dl_main ==4836== ==4836== IN SUMMARY: 2 errors from 2 contexts (suppressed: 12 from 1) ==4836== ==4836== malloc/free: in use at exit: 0 bytes in 0 blocks. ==4836== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==4836== --4836-- TT/TC: 0 tc sectors discarded. --4836-- 2283 tt_fast misses. --4836-- translate: new 2149 (38255 -> 504466; ratio 131:10) --4836-- discard 2 (59 -> 840; ratio 142:10). --4836-- chainings: 1296 chainings, 3 unchainings. --4836-- dispatch: 0 jumps (bb entries); of them 4805 (480500%) unchained. --4836-- 46/2348 major/minor sched events. --4836-- reg-alloc: 499 t-req-spill, 94125+4108 orig+spill uis, --4836-- 11904 total-reg-rank --4836-- sanity: 25 cheap, 1 expensive checks. --4836-- ccalls: 8090 C calls, 54% saves+restores avoided (25832 bytes) --4836-- 10776 args, avg 0.87 setup instrs each (2756 bytes) --4836-- 0% clear the stack (24147 bytes) --4836-- 3638 retvals, 29% of reg-reg movs avoided (2096 bytes) ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com |
|
From: Nicholas N. <nj...@cs...> - 2005-10-11 02:01:09
|
On Mon, 10 Oct 2005, Manish Marathe wrote: > Ya, thanks for that, and now when I did like: > > valgrind --tool=memcheck --trace-children=yes make check > > I got something like: > ==26684== [...] > ==26684== Invalid read of size 1 > ==26684== at 0x8055270: (within /usr/bin/make)<-------------------------------------- still says within /usr/bin/make > ==26684== by 0x1B925E32: __libc_start_main (in /lib/tls/libc-2.3.3.so) > ==26684== by 0x80498F0: (within /usr/bin/make) > ==26684== Address 0x52C00000 is not stack'd, malloc'd or (recently) free'd > > Now here it actually enters the directory where pgsql was checked out > but still says "within /usr/bin/make". Does it always name the parent > process or is this something else. I expect make is calling itself recursively. If postgresql has errors they should be reported as being in postgresql. If you run with -v you can look for "Command line" in the output to see the names of the processes being run. Nick |
|
From: Madhu M K. <mm...@ya...> - 2005-10-11 00:35:50
|
Hmm: On Mon, 2005-10-10 at 15:03, Nicholas Nethercote wrote: > Not reading the FAQ... > > www.valgrind.org/docs/FAQ/ question 5.1. > 5.1 returns a 404. Is it just me or do all of the non inlined FAQ entries return 404s? Cheerio, M -- Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Nicholas N. <nj...@cs...> - 2005-10-10 22:03:47
|
On Mon, 10 Oct 2005, Manish Marathe wrote: > I built the Postgresql database and actually ran the tests for postgres > under Valgrind. I am using Fedora Core 3 > > I am executing the tests like > > valgrind --tool=memcheck make check > > "check" is the test target they use to run tests. The output which I > got, I think Valgrind was monitoring "make" and not postgresql server > against which the tests were ran. > > Am I doing something wrong? Not reading the FAQ... www.valgrind.org/docs/FAQ/ question 5.1. Nick |
|
From: Manish M. <mma...@sp...> - 2005-10-10 21:57:58
|
Hello, I built the Postgresql database and actually ran the tests for postgres under Valgrind. I am using Fedora Core 3 I am executing the tests like valgrind --tool=memcheck make check "check" is the test target they use to run tests. The output which I got, I think Valgrind was monitoring "make" and not postgresql server against which the tests were ran. Am I doing something wrong? thanks -Manish |
|
From: Nicholas N. <nj...@cs...> - 2005-10-10 20:39:18
|
On Mon, 10 Oct 2005, Christopher Tate wrote: > There are some instructions that are not supported in the 3.x stable > release yet. You might try the current Subversion head sources; the VEX > instruction set support has been expanded since 3.0.1 was shipped. The SVN sources also give a more informative error message about this. Nick |
|
From: Nicholas N. <nj...@cs...> - 2005-10-10 20:38:27
|
On Mon, 10 Oct 2005, Vedire Srikanth-FSV003 wrote: > I followed the suggestion and got the latest version from the repository. > > As with 2.4.1-ppc, I had to edit configure script since line number 3863 > "kernel=`uname -r`" comes back with Solaris 2.8 and that doesn't match > either 2.6 or 2.4 . > > Then I tried to make. This is the error I get: > ------------------------ begin of log ----------------------- > ... > m_libcfile.c: In function `vgPlain_pread': > m_libcfile.c:215: parse error before `res' > m_libcfile.c:216: `res' undeclared (first use in this function) > m_libcfile.c:216: (Each undeclared identifier is reported only once > m_libcfile.c:216: for each function it appears in.) > m_libcfile.c:217: warning: control reaches end of non-void function > make[3]: *** [m_libcfile.o] Error 1 > make[3]: Leaving directory `/home/fsv003/NewValgrind/valgrind/coregrind' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/home/fsv003/NewValgrind/valgrind/coregrind' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/fsv003/NewValgrind/valgrind' > make: *** [all] Error 2 > > ------------------------------- end of log ------------------------- > > I'm using gcc version 2.95.3 release. Anyone have a clue why this is > failing? Valgrind's code has lots of declarations that aren't at the start of a block. GCC 2.95 can't handle these (GCC 3.0 and later can). It's on our todo list to fix this so that Valgrind will compile with GCC 2.95. Nick |
|
From: Christopher T. <Chr...@pa...> - 2005-10-10 20:22:40
|
There are some instructions that are not supported in the 3.x stable = release yet. You might try the current Subversion head sources; the VEX = instruction set support has been expanded since 3.0.1 was shipped. -- christopher tate -----Original Message----- From: val...@li... [mailto:val...@li...]On Behalf Of Carlos Munoz Sent: Monday, October 10, 2005 12:47 PM To: val...@li... Subject: [Valgrind-users] vex x86->IR: unhandled instruction bytes: 0xEF 0xC9 0xC3 0x90 I get the following error when running valgrind (v3.0.1) on my executable: (1) vex x86->IR: unhandled instruction bytes: 0xEF 0xC9 0xC3 0x90 (1) =3D=3D14174=3D=3D (1) =3D=3D14174=3D=3D Process terminating with default action of signal = 4 (SIGILL): dumping core (1) =3D=3D14174=3D=3D Illegal opcode at address 0x80ADC94 (1) =3D=3D14174=3D=3D at 0x80ADC94: outl(unsigned, unsigned short) = (io.h:96) Is there a work around for this error ? Should I open a bug ? The system running valgrind is: $ uname -a Linux sleuth9 2.4.20-31.9_S9BaseOS #1 SMP Fri Sep 9 13:44:43 PDT 2005 i686 i686 i386 GNU/Linux Thanks is advance for your help. Carlos Munoz ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, = discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Robert W. <rj...@du...> - 2005-10-10 19:54:35
|
> (1) vex x86->IR: unhandled instruction bytes: 0xEF 0xC9 0xC3 0x90 > (1) =3D=3D14174=3D=3D > (1) =3D=3D14174=3D=3D Process terminating with default action of signal 4 > (SIGILL): dumping core > (1) =3D=3D14174=3D=3D Illegal opcode at address 0x80ADC94 > (1) =3D=3D14174=3D=3D at 0x80ADC94: outl(unsigned, unsigned short) (io= .h:96) >=20 > Is there a work around for this error ? Should I open a bug ? Probably no workaround (unless you can persuade whatever compiler you're using not to use this.) Filing a bug is recommended. OxEF is "out %eax,(%dx)", btw. Regards, Robert, --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Carlos M. <cm...@de...> - 2005-10-10 19:45:59
|
I get the following error when running valgrind (v3.0.1) on my executable: (1) vex x86->IR: unhandled instruction bytes: 0xEF 0xC9 0xC3 0x90 (1) ==14174== (1) ==14174== Process terminating with default action of signal 4 (SIGILL): dumping core (1) ==14174== Illegal opcode at address 0x80ADC94 (1) ==14174== at 0x80ADC94: outl(unsigned, unsigned short) (io.h:96) Is there a work around for this error ? Should I open a bug ? The system running valgrind is: $ uname -a Linux sleuth9 2.4.20-31.9_S9BaseOS #1 SMP Fri Sep 9 13:44:43 PDT 2005 i686 i686 i386 GNU/Linux Thanks is advance for your help. Carlos Munoz |
|
From: Vedire Srikanth-F. <Sri...@mo...> - 2005-10-10 19:43:51
|
Hi, I followed the suggestion and got the latest version from the repository. As with 2.4.1-ppc, I had to edit configure script since line number 3863 "kernel=`uname -r`" comes back with Solaris 2.8 and that doesn't match either 2.6 or 2.4 . Then I tried to make. This is the error I get: ------------------------ begin of log ----------------------- make all-recursive make[1]: Entering directory `/home/fsv003/NewValgrind/valgrind' Making all in include make[2]: Entering directory `/home/fsv003/NewValgrind/valgrind/include' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/fsv003/NewValgrind/valgrind/include' Making all in coregrind make[2]: Entering directory `/home/fsv003/NewValgrind/valgrind/coregrind' make all-am make[3]: Entering directory `/home/fsv003/NewValgrind/valgrind/coregrind' source='m_clientstate.c' object='m_clientstate.o' libtool=no \ depfile='.deps/m_clientstate.Po' tmpdepfile='.deps/m_clientstate.TPo' \ depmode=gcc /bin/bash ../depcomp \ powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/ppc32 -I../coregrind/linux -I../coregrind/ppc32-linux -I../include -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -DVG_LIBDIR="\"/home/fsv003/vg/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c `test -f 'm_clientstate.c' || echo './'`m_clientstate.c source='m_debugger.c' object='m_debugger.o' libtool=no \ depfile='.deps/m_debugger.Po' tmpdepfile='.deps/m_debugger.TPo' \ depmode=gcc /bin/bash ../depcomp \ powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/ppc32 -I../coregrind/linux -I../coregrind/ppc32-linux -I../include -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -DVG_LIBDIR="\"/home/fsv003/vg/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c `test -f 'm_debugger.c' || echo './'`m_debugger.c source='m_debuglog.c' object='m_debuglog.o' libtool=no \ depfile='.deps/m_debuglog.Po' tmpdepfile='.deps/m_debuglog.TPo' \ depmode=gcc /bin/bash ../depcomp \ powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/ppc32 -I../coregrind/linux -I../coregrind/ppc32-linux -I../include -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -DVG_LIBDIR="\"/home/fsv003/vg/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c `test -f 'm_debuglog.c' || echo './'`m_debuglog.c source='m_errormgr.c' object='m_errormgr.o' libtool=no \ depfile='.deps/m_errormgr.Po' tmpdepfile='.deps/m_errormgr.TPo' \ depmode=gcc /bin/bash ../depcomp \ powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/ppc32 -I../coregrind/linux -I../coregrind/ppc32-linux -I../include -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -DVG_LIBDIR="\"/home/fsv003/vg/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c `test -f 'm_errormgr.c' || echo './'`m_errormgr.c source='m_execontext.c' object='m_execontext.o' libtool=no \ depfile='.deps/m_execontext.Po' tmpdepfile='.deps/m_execontext.TPo' \ depmode=gcc /bin/bash ../depcomp \ powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/ppc32 -I../coregrind/linux -I../coregrind/ppc32-linux -I../include -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -DVG_LIBDIR="\"/home/fsv003/vg/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c `test -f 'm_execontext.c' || echo './'`m_execontext.c source='m_hashtable.c' object='m_hashtable.o' libtool=no \ depfile='.deps/m_hashtable.Po' tmpdepfile='.deps/m_hashtable.TPo' \ depmode=gcc /bin/bash ../depcomp \ powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/ppc32 -I../coregrind/linux -I../coregrind/ppc32-linux -I../include -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -DVG_LIBDIR="\"/home/fsv003/vg/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c `test -f 'm_hashtable.c' || echo './'`m_hashtable.c source='m_libcbase.c' object='m_libcbase.o' libtool=no \ depfile='.deps/m_libcbase.Po' tmpdepfile='.deps/m_libcbase.TPo' \ depmode=gcc /bin/bash ../depcomp \ powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/ppc32 -I../coregrind/linux -I../coregrind/ppc32-linux -I../include -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -DVG_LIBDIR="\"/home/fsv003/vg/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c `test -f 'm_libcbase.c' || echo './'`m_libcbase.c source='m_libcassert.c' object='m_libcassert.o' libtool=no \ depfile='.deps/m_libcassert.Po' tmpdepfile='.deps/m_libcassert.TPo' \ depmode=gcc /bin/bash ../depcomp \ powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/ppc32 -I../coregrind/linux -I../coregrind/ppc32-linux -I../include -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -DVG_LIBDIR="\"/home/fsv003/vg/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c `test -f 'm_libcassert.c' || echo './'`m_libcassert.c source='m_libcfile.c' object='m_libcfile.o' libtool=no \ depfile='.deps/m_libcfile.Po' tmpdepfile='.deps/m_libcfile.TPo' \ depmode=gcc /bin/bash ../depcomp \ powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/ppc32 -I../coregrind/linux -I../coregrind/ppc32-linux -I../include -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -DVG_LIBDIR="\"/home/fsv003/vg/lib/valgrind"\" -DKICKSTART_BASE=@KICKSTART_BASE@ -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c `test -f 'm_libcfile.c' || echo './'`m_libcfile.c m_libcfile.c: In function `vgPlain_pread': m_libcfile.c:215: parse error before `res' m_libcfile.c:216: `res' undeclared (first use in this function) m_libcfile.c:216: (Each undeclared identifier is reported only once m_libcfile.c:216: for each function it appears in.) m_libcfile.c:217: warning: control reaches end of non-void function make[3]: *** [m_libcfile.o] Error 1 make[3]: Leaving directory `/home/fsv003/NewValgrind/valgrind/coregrind' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/fsv003/NewValgrind/valgrind/coregrind' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/fsv003/NewValgrind/valgrind' make: *** [all] Error 2 ------------------------------- end of log ------------------------- I'm using gcc version 2.95.3 release. Anyone have a clue why this is failing? Thanks in advance, Srikanth PS: Svn didn't like going through the company firewall so I had to download at home (windows) and extract here on unix. So I had to do that dos2unix conversion which shouldn't be a cause of the problem I'm seeing. But you never know. -----Original Message----- From: Nicholas Nethercote [mailto:nj...@cs...] Sent: Tuesday, September 27, 2005 9:18 AM To: Vedire Srikanth-FSV003 Cc: val...@li... Subject: Re: [Valgrind-users] Help with cross compile on PPC On Mon, 26 Sep 2005, Vedire Srikanth-FSV003 wrote: > I'm trying to get Valgrind 2.4.1-ppc going. You might have more luck with the PPC support in the current CVS repository; the problematic code is no longer in there. Nick |
|
From: Josef W. <Jos...@gm...> - 2005-10-10 17:16:14
|
On Monday 10 October 2005 18:25, Dennis Lubert wrote: > Hi, > > anyone knows if callgrind is actively maintained It is actively maintained, > and "fits" to the valgrind > svn version somewhere ? but only against stable Valgrind releases. > Since valgrind svn does work better than current > release here, Im using this, but callgrind (0.10.0) does not work with it, > it has problems because of vgPlain_client_argv beeing removed... Obviously there are some changes in the tool interface, but I did not investigate yet. Patches welcome ;-) An issue for external tools is that they are statically linked now. To check that this is working (VG needs to install a library to link against), I should probably have a look. Josef |
|
From: Dennis L. <pla...@in...> - 2005-10-10 16:24:12
|
Hi, anyone knows if callgrind is actively maintained and "fits" to the valgrind svn version somewhere ? Since valgrind svn does work better than current release here, Im using this, but callgrind (0.10.0) does not work with it, it has problems because of vgPlain_client_argv beeing removed... greets Dennis Carpe quod tibi datum est |
|
From: Josef W. <Jos...@gm...> - 2005-10-10 14:00:36
|
On Monday 10 October 2005 15:36, Jacek Poplawski wrote: > I know that it is possible in kcachegrind with file/add but I want to do > it automagically, without clicking 100 times :) > > How can I do it? I can't find command line option to sum profiles... Is > there any other documentation than > http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindDocs? Documentation is a weak point with KCachegrind ;-( I plan to add a small text mode program to merge/filter profiles. In the meantime: If you run "kcachegrind <prefix>", it will load all files with <prefix>[.part[-thread]] together. This is meant for automatic sum of multiple dumps of one run, but you can use it to load all dumps in a directory with kcachegrind callgrind.out Hope this helps. Josef |
|
From: Jacek P. <ja...@s3...> - 2005-10-10 13:37:28
|
Thank you for callgrind! This is first profiler which really works with our multithreaded application :) In our testing framework application is restarted many times (about 100), I can generate many callgrind profiles, but what I want is one profile which is sum of all small profiles. I know that it is possible in kcachegrind with file/add but I want to do it automagically, without clicking 100 times :) How can I do it? I can't find command line option to sum profiles... Is there any other documentation than http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindDocs? And one more time - thanks for awesome development tool! The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: com...@s3.... Thank You. |
|
From: Christoph B. <bar...@or...> - 2005-10-10 07:51:04
|
Am Dienstag, 4. Oktober 2005 22:47 schrieb Julian Seward: > The usual way to get sigbus on an x86 machine is to have a file > mapping where the mapping is longer than the file, and access > memory in that overhang area at the end. > > I wonder if this is somehow related to the shm bugs that Tom > just fixed today. Can you svn up and see if the behaviour > has changed? Yes, the latest version does not have this problem anymore. Christoph |
|
From: Josef W. <Jos...@gm...> - 2005-10-08 23:15:54
|
On Saturday 08 October 2005 20:55, Harold Naparst wrote: > ... > and the function work() isn't even listed. That is strange. Can you send me the callgrind.out file? > How do I know what percentage of > work was done by the lines in work() if it isn't listed? Even if debug info for work() would be missing, the function should be listed. Seems to be a bug. > Could it be my compilation options were too aggressive, and the compiler > inlined the function work()? If the function would have been inlined, you would not see the call, as there is no call: the code of work would be part of function main. I.e. you should see the lines of work() in the source annotation of function main. Josef |
|
From: Harold N. <ha...@al...> - 2005-10-08 18:55:51
|
Congratulations on callgrind. A very nice piece of work.
Really useful and attractive presentation.
One question. It seems to me that if you have source such as this:
main(){
work()
a =3D b + c;
}
work(){
c =3D d*e;
d =3D e * e;
}
Callgrind gives a profile that looks like this:
main()
75% work();
25% a =3D b+c;
}
and the function work() isn't even listed. How do I know what percentage of
work was done by the lines in work() if it isn't listed?
The numbers are only approximate, of course, but that seems to be the
situation. The stats for the call to work() are given,
but not the individual lines in work().
Could it be my compilation options were too aggressive, and the compiler
inlined the function work()?
|
|
From: Dada E. <edi...@gi...> - 2005-10-08 01:23:09
|
Hello Do you E UPTO ur Meddicatio want to SAV 70% on yo ns? But It's easy - Get More Detailed info ALVXVC bieitralianaiagial naum $xra $is $ 218 (180 p.) 134 (30 p.)169 (30 p.) Many Other , Good luck |
|
From: Josef W. <Jos...@gm...> - 2005-10-07 16:29:37
|
On Friday 07 October 2005 19:18, Alan Grimes wrote: > Can you please explain what the issue behind this error message is? > OpenGL applications are natural subjects for code profiling... > > ###################### > atg@leenooks ~/test $ callgrind ppracer > ==27090== Callgrind-0.9.12, a call-graph generating cache profiler for > x86-linux > ==27090== Using valgrind-2.4.1, a program supervision framework for > x86-linux. > ... > ppracer: error while loading shared libraries: libGL.so.1: cannot enable > executa > ble stack as shared object requires: Invalid argument Hmm... this is not callgrind-specific. I'm not really sure where this comes from. Forwarding to valgrind-users... Does this happen with VG3, too? > Here's another: > > ############################ > atg@leenooks ~/Croquet0.3 $ valgrind squeak > ==16925== Memcheck, a memory error detector. > ==16925== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. > ==16925== Using LibVEX rev 1367, a library for dynamic binary translation. > ==16925== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. > ==16925== Using valgrind-3.0.1, a dynamic binary instrumentation framework. > ==16925== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. > ==16925== For more details, rerun with: -v > ==16925== > could not find display driver vm-display-X11; either: > - check that /usr/local/lib/squeak/3.7-7/vm-display-X11.so exists, or > - use the '-plugins <path>' option to tell me where it is, or > - remove DISPLAY from your environment. Seems like the execution environment is slightly different when run in Valgrind? No idea, sorry. Josef |