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
(18) |
2
(6) |
|
3
(2) |
4
(2) |
5
(5) |
6
(12) |
7
(2) |
8
(1) |
9
(2) |
|
10
(6) |
11
(11) |
12
(12) |
13
(3) |
14
(3) |
15
(2) |
16
|
|
17
(2) |
18
(3) |
19
(43) |
20
(22) |
21
(10) |
22
(21) |
23
(5) |
|
24
|
25
(3) |
26
(12) |
27
(3) |
28
(14) |
29
(25) |
30
(5) |
|
31
(6) |
|
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2005-07-06 08:18:25
|
> did you think any more about automatic invalidation of translations? > As a short term hack, just checking for the signature of a trampoline > would be good enough for me, so if you can give me some pointers to which > bit of code I should be looking at, I will try to hack it up myself. I haven't yet solved the problem, but I did do an important piece of background infrastructure rejiggery (vex r1247, if you receive commit messages) which means that the rest of the fix only needs to be implemented once rather than differently for each supported architecture. Anyway, as a result of your mail I wrote this down on my short term ToDo list and hopefully it won't be too difficult now. I'll try and hack up something by the weekend. J |
|
From: Duncan S. <dun...@ma...> - 2005-07-06 07:28:21
|
Hi Julian, > So, what I'm thinking is to calculate a 32-bit CRC of the code > and store it in the translation; then rerun the crc for the > self-check. Except a CRC is expensive in terms of insns and > cache misses (it requires a table). Mark Adler (co-author > of gzip) had some other magic checksum scheme that gzip uses, which > doesn't require a table and is fast. Maybe use that instead. did you think any more about automatic invalidation of translations? As a short term hack, just checking for the signature of a trampoline would be good enough for me, so if you can give me some pointers to which bit of code I should be looking at, I will try to hack it up myself. All the best, Duncan. |
|
From: Igmar P. <mai...@jd...> - 2005-07-06 07:14:39
|
> Installation works fine, install works fine, however, valgrind immediately > Segmentation faults. > Using GDB, it seems to crash at the > jmp_with_stack( info.init_eip,(Addr)esp) > Line 301 at stage1.c Try compiling with --disable-pie Igmar |
|
From: Tom H. <to...@co...> - 2005-07-05 23:26:11
|
In message <200...@te...>
Rob Latham <ro...@te...> wrote:
> On Wed, Jun 29, 2005 at 07:30:53PM -0500, Nicholas Nethercote wrote:
> > It would be useful to have some more people using it to help iron out
> > remaining bugs. Thanks.
>
> Not sure if you consider this a bug or not, but I get quite a few
> messages about
> "WARNING: unhandled syscall: 18"
> (that's __NR_pwrite64)
>
> I haven't had much time to implement and contribute the wrapper for
> pwrite64...
Give it a go now as I've just committed a fix for this.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Rob L. <ro...@te...> - 2005-07-05 20:19:43
|
On Wed, Jun 29, 2005 at 07:30:53PM -0500, Nicholas Nethercote wrote: > It would be useful to have some more people using it to help iron out > remaining bugs. Thanks. Not sure if you consider this a bug or not, but I get quite a few messages about "WARNING: unhandled syscall: 18" (that's __NR_pwrite64) I haven't had much time to implement and contribute the wrapper for pwrite64... ==rob -- Rob Latham Chicago, IL USA |
|
From: Ahmet B.
|
Hello, I am trying to install valgrind on my system Linux SuSE 8.0 Kernel 2.4.18-64GB-SMP (6) Using gcc version 3.4.0 Installation works fine, install works fine, however, valgrind immediately Segmentation faults. Using GDB, it seems to crash at the jmp_with_stack( info.init_eip,(Addr)esp) Line 301 at stage1.c There seems to be a compile switch or something that I am missing. Any ideas Thank you Ahmet Buharali Waltham, MA |
|
From: Lalit S. <St...@jo...> - 2005-07-05 18:14:33
|
Hello, soldiery, the Elizabeth emptied her larboard guns into the fort asCaptain = Blood looked up to consider the questioner before replying.speeding to = the door.moved to raise his voice above its usual languid level.Spain = that was common to men of every other nation from the BahamasOh, I = understand, laughed Blood. But, I ask myself, do you?and after an = instant's pause, a score of hands sprang to executeprudence may avert. = You do not know on what a volcano you areAntilles, drawn by the scent of = blood, descended in a cloud upon him.accomplished, mildly dissolute, = entirely elegant envoy of my Lordscarcely yourself we had dared hope to = expect. You find yourselfof seamanship. Hagthorpe, although he had = been a fighting officer,glance. I wonder, now, he said presently, if = the mischief isThis hill was vividly green as is an English hill in = April, and themen. Thus you behold him not merely famous, but really = formidable.was become a pirate in his turn. The Supreme Council of = Castile |
|
From: <bla...@gm...> - 2005-07-05 10:01:14
|
My apologies for the previous mail, i realized it was not so clear. I'll explain me better: The goals of the EfficiencyTest project is to build a Efficiency Test framework for C++ using valgrind as backend. The project would allow to keep historical track of the execution times of pieces of code organized alla CppUnit (http://cppunit.sourceforge.net/). Currently I implemented some python scripts to extract the execution times of each test from the callgrind output. Now i am about to import the extracted data into an historical database. The information will be accessible thru a web based interface. I Submited the project in sourforge, however it isn't still accessible. I've created a tarball here: http://mtg182.upf.es/~rafa In this direction I submit all the project new versions Any comments will be nice. |
|
From: Dirk M. <dm...@gm...> - 2005-07-04 20:12:45
|
On Monday 04 July 2005 21:32, Ben Branch wrote: > /usr/bin/ld: cannot find -lc > collect2: ld returned 1 exit status install glibc-dev (or glibc-devel?) Dirk |
|
From: Ben B. <bb...@wi...> - 2005-07-04 19:33:02
|
Hi all, I'm upgrading my computer, from RedHat 8.0 and Valgrind 2.2.0 to, now, Mandrake 10.1 and valgrind 2.4.0. However, valgrind encounters a compile error: make[2]: Entering directory `/home/blb/downloads/valgrind-2.4.0/coregrind' gcc -Winline -Wall -Wshadow -O -g -mpreferred-stack-boundary=2 -DELFSZ=32 -Wno-long-long -o valgrind -static -g ume.o stage1.o jmp_with_stack.o /usr/bin/ld: cannot find -lc collect2: ld returned 1 exit status Has anyone seen this before? I've done only the standard stuff: downloading the source, ./configure, make. Best Regards, Thanks in advance, Ben P.S. I'm not on the list, so please reply to my email address as well. Thanks. |
|
From: Nicholas N. <nj...@cs...> - 2005-07-03 16:09:50
|
On Sun, 3 Jul 2005, Yeshurun, Meir wrote: > When do you estimate the version of Valgrind with support for > AMD64/Linux will be ready? soon > Where can I obtain the version that is still under development? http://www.valgrind.org/devel/cvs_svn.html N |
|
From: Yeshurun, M. <mei...@in...> - 2005-07-03 11:52:31
|
Hello everyone, =20 When do you estimate the version of Valgrind with support for AMD64/Linux will be ready? =20 Where can I obtain the version that is still under development? =20 Thanks, =20 Meir |
|
From: Paul P. <ppl...@gm...> - 2005-07-02 23:39:51
|
Greetings, Today's SVN checkout fails to build on=20 Red Hat Enterprise Linux AS release 3 (Taroon Update 2) x86_64 with gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-39), binutils-2.14.90.0.4-35 $ gcc -pie -m64 ... m_syswrap/libsyswrap.a /home/paul/valgrind-3.0-svn/vex/libvex.a -ldl /usr/bin/ld: /home/paul/valgrind-3.0-svn/vex/libvex.a(irdefs.o): relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC /home/paul/valgrind-3.0-svn/vex/libvex.a: could not read symbols: Bad value collect2: ld returned 1 exit status Removing '-pie' solves that, but the resulting valgrind crashes at startup. Adding '-fPIC' to CFLAGS in vex/Makefile also solves this problem and produ= ces a working VG. Every program on this system produces several of these: =3D=3D15027=3D=3D Warning: zero-sized CIE/FDE but not at section end in DWA= RF2 CFI reading Finally, Insure++-instrumented binaries trigger: valgrind: syswrap-amd64-linux.c:718 (vgSysWrap_amd64_linux_sys_arch_prctl_before): Assertion 'ARG1 =3D=3D VKI_ARCH_SET_FS' failed. On FC2-i686 the same test triggers: valgrind: syswrap-main.c:812 (vgPlain_post_syscall): Assertion 'eq_SyscallStatus( &sci->status, &test_status )' failed. The same binary runs fine on FC2-i686 under VG-2.4. This may be a case of 2 memory debugers fighting each other. Regards, |
|
From: Nicholas N. <nj...@cs...> - 2005-07-02 19:18:41
|
On Thu, 9 Jun 2005, Scott Long wrote: > So is there any comment on my idea, here? Let each register track the last > memory location it was loaded from, and report that location if the > uninitialized register is used. > > If there is something fundamental that makes that idea unfeasible I'd be very > interested to hear what it is. As far as I can tell, it's a good solution > which would avoid false positives and would probably be trivial to implement. I've given this some more thought. It's not trivial, for two reasons: - Every register now has to be shadowed by two extra values, one holding the V bits for Memcheck's validity checking, and the other holding the address. And every operation has to be shadowed by an extra operation that propagates the addresses to the result. The extra shadow operation would not be trivial -- eg. if you add two values A and B, and only one B is undefined, you'd need to propagate the address shadowing B to the result. If A and B were both defined or both undefined, you could propagate either. So, every register value now requires two shadow values, and every operations requires two shadow operations. This would require a non-trivial amount of effort to code up, and would have some runtime cost. - Converting the address to something more useful is not easy in general. It is easy when the address is within a heap block -- we can use the existing machinery to say "address X is 100 bytes into a 200 byte heap block allocated at Y". But if the address is on the stack or a static value, just saying "address X on the stack/in static memory" is not very helpful. Valgrind does have some support for identifying variables, but it only works with stabs debugging information. It's also possible that most undefined values are loaded from heap blocks, in which case bad messages about stack and static values aren't very important. [I was also wondering if it would be better to record the address of the instruction that does the loading, rather than the address from which the value was loaded. That way the messages would say "undefined value X used on line Y, and it was loaded from memory on line Z.] So it's not that straightforward. But it's certainly possible, and it would be very interesting to see how difficult it is, what the performance effect is, and if the resulting messages are genuinely helpful. (Perhaps I should scream "no! it will never work, fool!" in order to motivate someone into implementing it to prove me wrong :) ---- Having written all that... When diagnosing undefined value errors, you don't really want to know the address that the value was loaded from. Sometimes that will tell you, eg. if you malloc some memory, forget to initialise it, then load it and use it straight-away in a dangerous way -- the address mentioned by the error message will be that of the heap block that was the root cause of the problem. But if you copy that value first to the stack, then load it and use it dangerously, the address mentioned by the error message would be the stack address, which is not the root cause of the problem. Every undefined value was caused to be undefined by one or more events of undefined value creation. Eg. undefined value A came into being as part of a heap block allocated by malloc(). If A is added to a defined value B, the result would be an undefined value C. C's why-am-I-undefined event is still the same as A's, however. In the case where you have Z = X + Y and both X and Y are undefined, you can arbitrarily choose X's event or Y's event to become Z's event. (If the programmer fixed one and reran Memcheck, the other undefined event would then rear its head, if you see what I mean.) So rather than passing around extra memory addresses, it would be better to pass around "tokens" that record the event that caused the undefined value to come into existence. What are these events? Well, allocating a heap block with malloc() is an obvious one. Shrinking the stack passed some previously defined values is another one. You would shadow all undefined values with one of these tokens, and you'd propagate them in the (hopefully) obvious ways. One key idea here, which Scott pointed out, is that rather than having to record the full history of each undefined value, we only need to record one single undefined-value-causing event, even if the undefined value can be traced back to more than one undefined-value event. That's enough to give a better error message. The problem with this "token" idea is that I'm assuming every value can be shadowed with a token, including values in memory. If a token was the size of a pointer, this would blow out Memcheck's memory requirements too much. Scott's second key idea is that you can approximate this by recording the extra "token" only for registers. So tokens have possibly incomplete histories, since the passing of values through memory breaks that history. But perhaps undefined values don't pass in and out of memory very much, or perhaps the truncated history recorded from the most recent load is enough in a lot of cases. A third key idea is that this extra "token" only needs to be recorded for values which are undefined. So there's some potential for compression of representation there. Anyway, I've probably lost everyone by now, but I've come to appreciate some of the subtleties of this problem more now. Thanks, Scott :) N |
|
From: <Woe...@on...> - 2005-07-02 16:14:35
|
On Saturday 02 July 2005 17:06, Nicholas Nethercote wrote: > > That looks more like a problem with your system libraries than a > problem with Valgrind. =20 You're right, but I thought there would be anyone else running Debian on=20 AMD64. > Do you have access to another machine you can try it on? Yes, at work. AMD64 with SuSE 9.3. But it would be nice if valgrind runs=20 on Debian too :-) Cheers, Andr=E9 |
|
From: Nicholas N. <nj...@cs...> - 2005-07-02 15:06:49
|
On Sat, 2 Jul 2005, Andr=E9 W=F6bbeking wrote: > I want to test it but I can't compile valgrind: > > /usr/bin/ld: __libc_errno: TLS definition in /usr/lib/gcc/x86_64-linux/4.= 0.1/../../../../lib64/libc.a(errno.o) section .tbss mismatches non-TLS refe= rence in /usr/lib/gcc/x86_64-linux/4.0.1/../../../../lib64/libc.a(check_fds= =2Eo) > /usr/lib/gcc/x86_64-linux/4.0.1/../../../../lib64/libc.a: could not read = symbols: Bad value > collect2: ld returned 1 exit status > > gcc -v: > > gcc version 4.0.1 20050522 (prerelease) (Debian 4.0.0-9) > > ld -v: > > GNU ld version 2.16 Debian GNU/Linux > > glibc-2.3.5-1 (after 2.3.2 failed) > > Is there a way to dynamic link valgrind or do you've other tips? That looks more like a problem with your system libraries than a problem=20 with Valgrind. Do you have access to another machine you can try it on? N |
|
From: <Woe...@on...> - 2005-07-02 13:11:45
|
On Thursday 30 June 2005 02:30, Nicholas Nethercote wrote: > Hi, > > It would be useful to have some more people using it to help iron out > remaining bugs. Thanks. I want to test it but I can't compile valgrind: /usr/bin/ld: __libc_errno: TLS definition in /usr/lib/gcc/x86_64-linux/4.0.= 1/../../../../lib64/libc.a(errno.o) section .tbss mismatches non-TLS refere= nce in /usr/lib/gcc/x86_64-linux/4.0.1/../../../../lib64/libc.a(check_fds.o) /usr/lib/gcc/x86_64-linux/4.0.1/../../../../lib64/libc.a: could not read sy= mbols: Bad value collect2: ld returned 1 exit status gcc -v: gcc version 4.0.1 20050522 (prerelease) (Debian 4.0.0-9) ld -v: GNU ld version 2.16 Debian GNU/Linux glibc-2.3.5-1 (after 2.3.2 failed) Is there a way to dynamic link valgrind or do you've other tips? Cheers, Andr=E9 |
|
From: <bla...@gm...> - 2005-07-02 12:15:32
|
Hi, I'm making a project written in Python which test functions in C++, return the efficiency cost values parsing the callgirind's output file and follow the efficiency progress using a data base (The Data Base Is not finished) I've submit the code in www.sourceforge.net. the ID is 1231463, my nick is rbaquero and the summary name is Efficiency Testing If anyone is interested in this project, I'll aknowledge your advisements Thank you P.D: If anyone wants to chat with me, my Messenger contact is: bla...@ho... |
|
From: Nicholas N. <nj...@cs...> - 2005-07-01 21:11:18
|
On Fri, 1 Jul 2005, Robert Walsh wrote: > What is the CFI reader anyway? I can't find a reference to the term > "cfi" anywhere in libdwarf. Is it supposed to be a CFA, perhaps? It's short for "Call Frame Instructions". I believe the info helps with stack tracing -- Julian had to implement CFI reading support to get good stack traces on AMD64. N |
|
From: Robert W. <rj...@du...> - 2005-07-01 21:05:06
|
> > DWARF2 CFI reader: unhandled CFI instruction 0:50
> > DWARF2 CFI reader: unhandled CFI instruction 0:50
>
> This would be easy enough to fix if only I had a clue what CFI
> instruction #50 (0x32) is. Neither the DWARF3 spec nor the gdb-6.3
> sources ("the ultimate reference" :-) mention it. I suspect
> it's some GNUish extension.
>
> Could you email me the executable itself (closeall, I mean) and
> I'll prod it with readelf and see what happens.
What is the CFI reader anyway? I can't find a reference to the term
"cfi" anywhere in libdwarf. Is it supposed to be a CFA, perhaps?
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-01 20:54:35
|
On Thu, 30 Jun 2005, Martin Lubich wrote: > I came across a problem where it seems that running a multithreaded > application under valgrinds control does not correctly handle the > pthread cleanup handlers which you establish by using > pthread_cleanup_push and pthread_cleanup_pop. Could you create a Bugzilla bug report for this issue, including all the information you've given so far? That will ensure this isn't forgotten. Thanks. N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-01 20:51:56
|
On Fri, 1 Jul 2005, Adnan Khaleel wrote: > I've downloaded the 3.0 source and it does not appear to have the same problem, the java virtual machine loaded and is running quite > nicely at the moment. Thanks for the suggestion. > > This actually brings me to another question - what is the best way to debug the tool code? I mean > how do I bring it up inside a debugger, Kdbg (and gdb as well I'm assuming) seems to lose track as valgrind loads > and I just can't manage to set a breakpoint inside the tool code. How do you guys do it? Are printfs the only > route? See README_DEVELOPERS. But printfs get used a lot (at least by me). N |
|
From: Adnan K. <Adn...@ne...> - 2005-07-01 20:50:40
|
I've downloaded the 3.0 source and it does not appear to have the same = problem, the java virtual machine loaded and is running quite nicely at the moment. Thanks for the suggestion. This actually brings me to another question - what is the best way to = debug the tool code? I mean how do I bring it up inside a debugger, Kdbg (and gdb as well I'm = assuming) seems to lose track as valgrind loads and I just can't manage to set a breakpoint inside the tool code. How do = you guys do it? Are printfs the only route? Thanks again, Adnan -----Original Message----- From: Nicholas Nethercote [mailto:nj...@cs...] Sent: Friday, July 01, 2005 11:44 AM To: Adnan Khaleel Cc: Josef Weidendorfer; val...@li... Subject: RE: [Valgrind-users] Valgrind and Java On Fri, 1 Jul 2005, Adnan Khaleel wrote: > I noticed the extremely large heap size as well but that particular=20 > machine has 4G so it really shouldn't have been a problem. It's not the physical memory that's the issue, it's the address space.=20 When using Memcheck there's not enough address space available to = allocate=20 a single 1.8GB heap. And we see it doesn't fail when you reduce the = heap=20 size. > I've reduced the heap size to 300M with tool=3Dnone and it still = fails.=20 > However it doesn't have the number -2 in sigaction. It is probably still happening, but tool=3Dnone doesn't report it. > INV 2 FAILED: seg 0xB101C000-0xB101F000 crosses boundaries of mapping = 0xB101C000-0xB101E000 > INV 1 FAILED: seg -0xB101C000 does not end at mapping = 0xB101F000-0xB101C000 end The problem here is that Valgrind's idea of the memory mappings have got = out of sync with those maintained by the kernel (as seen in=20 /proc/self/maps). I haven't seen this before. It would be worth = checking=20 out the code from the 3.0 repository at valgrind.org and trying that,=20 because the segment tracking code is different to that in 2.4.0. N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-01 16:43:43
|
On Fri, 1 Jul 2005, Adnan Khaleel wrote: > I noticed the extremely large heap size as well but that particular > machine has 4G so it really shouldn't have been a problem. It's not the physical memory that's the issue, it's the address space. When using Memcheck there's not enough address space available to allocate a single 1.8GB heap. And we see it doesn't fail when you reduce the heap size. > I've reduced the heap size to 300M with tool=none and it still fails. > However it doesn't have the number -2 in sigaction. It is probably still happening, but tool=none doesn't report it. > INV 2 FAILED: seg 0xB101C000-0xB101F000 crosses boundaries of mapping 0xB101C000-0xB101E000 > INV 1 FAILED: seg -0xB101C000 does not end at mapping 0xB101F000-0xB101C000 end The problem here is that Valgrind's idea of the memory mappings have got out of sync with those maintained by the kernel (as seen in /proc/self/maps). I haven't seen this before. It would be worth checking out the code from the 3.0 repository at valgrind.org and trying that, because the segment tracking code is different to that in 2.4.0. N |
|
From: Adnan K. <Adn...@ne...> - 2005-07-01 16:31:23
|
I noticed the extremely large heap size as well but that particular = machine has 4G so it really shouldn't have been a problem. I've reduced the heap size to 300M with tool=3Dnone = and it still fails. However it doesn't have the number -2 in sigaction. Here is the error text [hwteam2:SPECjbb2000]$ valgrind --tool=3Dnone --trace-children=3Dyes = java -Xms300m -Xmx300m -Xcompactexplicitgc spec.jbb.JBBmain -propfile = SPECjbb.props =3D=3D10907=3D=3D Nulgrind, a binary JIT-compiler for x86-linux. =3D=3D10907=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas = Nethercote. =3D=3D10907=3D=3D Using valgrind-2.4.0, a program supervision framework = for x86-linux. =3D=3D10907=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian = Seward et al. =3D=3D10907=3D=3D For more details, rerun with: -v =3D=3D10907=3D=3D =3D=3D10907=3D=3D Nulgrind, a binary JIT-compiler for x86-linux. =3D=3D10907=3D=3D Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas = Nethercote. =3D=3D10907=3D=3D Using valgrind-2.4.0, a program supervision framework = for x86-linux. =3D=3D10907=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian = Seward et al. =3D=3D10907=3D=3D For more details, rerun with: -v =3D=3D10907=3D=3D INV 2 FAILED: seg 0xB101C000-0xB101F000 crosses boundaries of mapping = 0xB101C000-0xB101E000 INV 1 FAILED: seg -0xB101C000 does not end at mapping = 0xB101F000-0xB101C000 end vvvvv SEGMENT MAPS NOT OK vvvvv seg: 0x8048000-0x804F000 (r-x) 4318 mapping 0x8048000-0x804F000 r-x = /.automount/engfiler/vol/HomeDir1/DesignVerification/adnan.khaleel/tmp/IB= MJava2-142/jre/bin/java seg: 0x804F000-0x8050000 (rw-) 118 mapping 0x804F000-0x8050000 rw- = /.automount/engfiler/vol/HomeDir1/DesignVerification/adnan.khaleel/tmp/IB= MJava2-142/jre/bin/java seg: 0x8050000-0x8051000 (rw-) 108 mapping 0x8050000-0x8051000 rw- seg: 0x8051000-0x8052000 (rwx) 809 mapping 0x8051000-0x8055000 rwx = !!! seg: 0x8052000-0x8055000 (rwx) 809 mapping 0x8051000-0x8055000 rwx = !!! seg: 0x3A965000-0x3A97A000 (r-x) 4318 mapping 0x3A965000-0x3A97A000 r-x = /lib/ld-2.2.4.so seg: 0x3A97A000-0x3A97B000 (rw-) 118 mapping 0x3A97A000-0x3A97B000 rw- = /lib/ld-2.2.4.so seg: 0x3A97C000-0x3A97D000 (rw-) 9 mapping 0x3A97C000-0x3A97D000 rw- seg: 0x3A97E000-0x3A97F000 (r-x) 4219 mapping 0x3A97E000-0x3A97F000 r-x = = /.automount/engfiler/vol/HomeDir1/DesignVerification/adnan.khaleel/Progra= mFiles/lib/valgrind/vg_inject.so seg: 0x3A97F000-0x3A980000 (rw-) 19 mapping 0x3A97F000-0x3A980000 rw- = = /.automount/engfiler/vol/HomeDir1/DesignVerification/adnan.khaleel/Progra= mFiles/lib/valgrind/vg_inject.so seg: 0x3A995000-0x3A9A4000 (r-x) 4219 mapping 0x3A995000-0x3A9A4000 r-x = /lib/libpthread-0.9.so seg: 0x3A9A4000-0x3A9AC000 (rw-) 19 mapping 0x3A9A4000-0x3A9AC000 rw- = /lib/libpthread-0.9.so seg: 0x3A9AD000-0x3A9C0000 (r-x) 4219 mapping 0x3A9AD000-0x3A9C0000 r-x = /lib/libnsl-2.2.4.so seg: 0x3A9C0000-0x3A9C2000 (rw-) 19 mapping 0x3A9C0000-0x3A9C2000 rw- = /lib/libnsl-2.2.4.so seg: 0x3A9C2000-0x3A9C4000 (rw-) 9 mapping 0x3A9C2000-0x3A9C4000 rw- seg: 0x3A9C5000-0x3A9C6000 (rw-) 9 mapping 0x3A9C5000-0x3A9C6000 rw- seg: 0x3A9C7000-0x3A9C9000 (r-x) 4219 mapping 0x3A9C7000-0x3A9C9000 r-x = /lib/libdl-2.2.4.so seg: 0x3A9C9000-0x3A9CB000 (rw-) 19 mapping 0x3A9C9000-0x3A9CB000 rw- = /lib/libdl-2.2.4.so seg: 0x3A9CC000-0x3AAF8000 (r-x) 4219 mapping 0x3A9CC000-0x3AAF8000 r-x = /lib/libc-2.2.4.so seg: 0x3AAF8000-0x3AAFE000 (rw-) 19 mapping 0x3AAF8000-0x3AAFE000 rw- = /lib/libc-2.2.4.so seg: 0x3AAFE000-0x3AB02000 (rw-) 9 mapping 0x3AAFE000-0x3AB02000 rw- seg: 0x3AB03000-0x3ACFD000 (r-x) 4219 mapping 0x3AB03000-0x3ACFD000 r-x = = /.automount/engfiler/vol/HomeDir1/DesignVerification/adnan.khaleel/tmp/IB= MJava2-142/jre/bin/classic/libjvm.so seg: 0x3ACFD000-0x3AD08000 (rw-) 19 mapping 0x3ACFD000-0x3AD08000 rw- = = /.automount/engfiler/vol/HomeDir1/DesignVerification/adnan.khaleel/tmp/IB= MJava2-142/jre/bin/classic/libjvm.so seg: 0x3AD08000-0x3AD1F000 (rw-) 9 mapping 0x3AD08000-0x3AD1F000 rw- seg: 0x3AD20000-0x3AD41000 (r-x) 4219 mapping 0x3AD20000-0x3AD41000 r-x = /lib/libm-2.2.4.so seg: 0x3AD41000-0x3AD42000 (rw-) 19 mapping 0x3AD41000-0x3AD42000 rw- = /lib/libm-2.2.4.so seg: 0x40000000-0x40001000 (rw-) 108 mapping 0x40000000-0x40001000 rw- seg: 0x40002000-0x40003000 (rw-) 108 mapping 0x40002000-0x40003000 rw- seg: 0xAFEF6000-0xAFEFA000 (rwx) 69 mapping 0xAFEF6000-0xAFEFF000 rwx = !!! seg: 0xAFEFA000-0xAFEFB000 (rwx) 69 mapping 0xAFEF6000-0xAFEFF000 rwx = !!! seg: 0xAFEFB000-0xAFEFC000 (rwx) 69 mapping 0xAFEF6000-0xAFEFF000 rwx = !!! seg: 0xAFEFC000-0xAFEFD000 (rwx) 69 mapping 0xAFEF6000-0xAFEFF000 rwx = !!! seg: 0xAFEFD000-0xAFEFF000 (rwx) 60 mapping 0xAFEF6000-0xAFEFF000 rwx = !!! seg: 0xAFEFF000-0xAFF00000 (r-x) 0 mapping 0xAFEFF000-0xAFF00000 r-x seg: 0xAFF00000-0xB0000000 (---) 2108 mapping 0xAFF00000-0xB0000000 --- seg: 0xB0000000-0xB009B000 (r-x) 2318 mapping 0xB0000000-0xB009B000 r-x = = /.automount/engfiler/vol/HomeDir1/DesignVerification/adnan.khaleel/Progra= mFiles/lib/valgrind/stage2 seg: 0xB009B000-0xB009D000 (rw-) 2118 mapping 0xB009B000-0xB009D000 rw- = = /.automount/engfiler/vol/HomeDir1/DesignVerification/adnan.khaleel/Progra= mFiles/lib/valgrind/stage2 seg: 0xB009D000-0xB01EB000 (rw-) 2108 mapping 0xB009D000-0xB01EB000 rw- seg: 0xB01EC000-0xB02EC000 (rwx) 2108 mapping 0xB01EC000-0xB02EC000 rwx seg: 0xB02ED000-0xB02EE000 (---) 2009 mapping 0xB02ED000-0xB02EE000 --- seg: 0xB02EE000-0xB02FE000 (rw-) 2009 mapping 0xB02EE000-0xB02FE000 rw- seg: 0xB02FF000-0xB0307000 (rwx) 2009 mapping 0xB02FF000-0xB0307000 rwx seg: 0xB0360000-0xB0460000 (rwx) 2009 mapping 0xB0360000-0xB0460000 rwx seg: 0xB0492000-0xB0592000 (rwx) 2009 mapping 0xB0492000-0xB0592000 rwx seg: 0xB0593000-0xB0693000 (rwx) 2009 mapping 0xB0593000-0xB0693000 rwx seg: 0xB0694000-0xB08DE000 (rwx) 2009 mapping 0xB0694000-0xB08DE000 rwx seg: 0xB0969000-0xB0A69000 (rwx) 2009 mapping 0xB0969000-0xB0A69000 rwx seg: 0xB0A6A000-0xB0B6A000 (rwx) 2009 mapping 0xB0A6A000-0xB0B6A000 rwx seg: 0xB0C0E000-0xB0D0E000 (rwx) 2009 mapping 0xB0C0E000-0xB0D0E000 rwx seg: 0xB0D0F000-0xB0E0F000 (rwx) 2009 mapping 0xB0D0F000-0xB0E0F000 rwx seg: 0xB0E10000-0xB0F10000 (rwx) 2009 mapping 0xB0E10000-0xB0F10000 rwx seg: 0xB1000000-0xB1015000 (r-x) 2318 mapping 0xB1000000-0xB1015000 r-x = /lib/ld-2.2.4.so seg: 0xB1015000-0xB1016000 (rw-) 2118 mapping 0xB1015000-0xB1016000 rw- = /lib/ld-2.2.4.so seg: 0xB1016000-0xB101A000 (rw-) 2108 mapping 0xB1016000-0xB101A000 rw- seg: 0xB101A000-0xB101B000 (r-x) 2318 mapping 0xB101A000-0xB101B000 r-x = = /.automount/engfiler/vol/HomeDir1/DesignVerification/adnan.khaleel/Progra= mFiles/lib/valgrind/vgskin_none.so seg: 0xB101B000-0xB101C000 (rw-) 2118 mapping 0xB101B000-0xB101C000 rw- = = /.automount/engfiler/vol/HomeDir1/DesignVerification/adnan.khaleel/Progra= mFiles/lib/valgrind/vgskin_none.so seg: 0xB101C000-0xB101F000 (rw-) 2408 mapping 0xB101C000-0xB101E000 rw- = !!! INV 2 FAILED: seg 0xB101C000-0xB101F000 crosses boundaries of mapping = 0xB101C000-0xB101E000 INV 1 FAILED: seg -0xB101C000 does not end at mapping = 0xB101F000-0xB101C000 end seg: 0xB102A000-0xB102C000 (r-x) 2318 mapping 0xB102A000-0xB102C000 r-x = /lib/libdl-2.2.4.so seg: 0xB102C000-0xB102E000 (rw-) 2118 mapping 0xB102C000-0xB102E000 rw- = /lib/libdl-2.2.4.so seg: 0xB102E000-0xB115A000 (r-x) 2318 mapping 0xB102E000-0xB115A000 r-x = /lib/libc-2.2.4.so seg: 0xB115A000-0xB1160000 (rw-) 2118 mapping 0xB115A000-0xB1160000 rw- = /lib/libc-2.2.4.so seg: 0xB1160000-0xB1164000 (rw-) 2108 mapping 0xB1160000-0xB1164000 rw- seg: 0xB1200000-0xB1208000 (rw-) 2108 mapping 0xB1200000-0xB1208000 rw- seg: 0xB1208000-0xB1300000 (---) 2108 mapping 0xB1208000-0xB1300000 --- seg: 0xB1301000-0xB1401000 (rwx) 2009 mapping 0xB1301000-0xB1401000 rwx seg: 0xB1402000-0xB1502000 (rwx) 2009 mapping 0xB1402000-0xB1502000 rwx seg: 0xB1503000-0xB1603000 (rwx) 2009 mapping 0xB1503000-0xB1603000 rwx seg: 0xB1604000-0xB177C000 (rwx) 2009 mapping 0xB1604000-0xB177C000 rwx seg: 0xB177D000-0xB187D000 (rwx) 2009 mapping 0xB177D000-0xB187D000 rwx seg: 0xB187E000-0xB1BC1000 (rwx) 2009 mapping 0xB187E000-0xB1BC1000 rwx seg: 0xB1BC2000-0xB1CC2000 (rwx) 2009 mapping 0xB1BC2000-0xB1CC2000 rwx seg: 0xB213C000-0xB223C000 (rwx) 2009 mapping 0xB213C000-0xB223C000 rwx seg: 0xB223D000-0xB233D000 (rwx) 2009 mapping 0xB223D000-0xB233D000 rwx seg: 0xB233E000-0xB243E000 (rwx) 2009 mapping 0xB233E000-0xB243E000 rwx seg: 0xB243F000-0xB253F000 (rwx) 2009 mapping 0xB243F000-0xB253F000 rwx seg: 0xB2540000-0xB2640000 (rwx) 2009 mapping 0xB2540000-0xB2640000 rwx seg: 0xB2641000-0xB2741000 (rwx) 2009 mapping 0xB2641000-0xB2741000 rwx seg: 0xB2742000-0xB28BA000 (rwx) 2009 mapping 0xB2742000-0xB28BA000 rwx seg: 0xB28BB000-0xB29BB000 (rwx) 2009 mapping 0xB28BB000-0xB29BB000 rwx seg: 0xB29BC000-0xB2ABC000 (rwx) 2009 mapping 0xB29BC000-0xB2ABC000 rwx seg: 0xB2ABD000-0xB2BBD000 (rwx) 2009 mapping 0xB2ABD000-0xB2BBD000 rwx seg: 0xB2BBE000-0xB2CBE000 (rwx) 2009 mapping 0xB2BBE000-0xB2CBE000 rwx seg: 0xB2CBF000-0xB2DBF000 (rwx) 2009 mapping 0xB2CBF000-0xB2DBF000 rwx seg: 0xBFFFB000-0xC0000000 (rwx) 2108 mapping 0xBFFFB000-0xC0000000 rwx ^^^^^ SEGMENT MAPS NOT OK ^^^^^ valgrind: vg_main.c:2240 (vgPlain_sanity_check_general): Assertion = `vgPlain_sanity_check_memory()' failed. =3D=3D10907=3D=3D at 0xB003124E: (within = /.automount/engfiler/vol/HomeDir1/DesignVerification/adnan.khaleel/Progra= mFiles/lib/valgrind/stage2) =3D=3D10907=3D=3D by 0xB003124D: assert_fail (vg_mylibc.c:1166) =3D=3D10907=3D=3D by 0xB003128D: vgPlain_core_assert_fail = (vg_mylibc.c:1177) =3D=3D10907=3D=3D by 0xB002B258: vgPlain_sanity_check_general = (vg_main.c:2240) =3D=3D10907=3D=3D by 0xB0017294: vgPlain_scheduler = (vg_scheduler.c:694) =3D=3D10907=3D=3D by 0xB0077161: vgArch_thread_wrapper (core_os.c:69) sched status: running_tid=3D1 Thread 1: status =3D VgTs_Runnable =3D=3D10907=3D=3D at 0x3AA4D9AC: strcat = (../sysdeps/generic/strcat.c:36) =3D=3D10907=3D=3D by 0x3ABC70F1: makePath = (/userlvl/cxia32142/src/jvm/pfm/ci/javai_md.c:282) =3D=3D10907=3D=3D by 0x3ABC731A: GetPropertiesMD = (/userlvl/cxia32142/src/jvm/pfm/ci/javai_md.c:365) =3D=3D10907=3D=3D by 0x3ABC152F: ciCreateJVM = (/userlvl/cxia32142/src/jvm/sov/ci/ci.c:2504) =3D=3D10907=3D=3D by 0x3ABCEABB: JNI_CreateJavaVM = (/userlvl/cxia32142/src/jvm/sov/ci/jni.c:5890) =3D=3D10907=3D=3D by 0x804A818: InitializeJVM (in = /.automount/engfiler/vol/HomeDir1/DesignVerification/adnan.khaleel/tmp/IB= MJava2-142/jre/bin/java) =3D=3D10907=3D=3D by 0x80495A1: main (in = /.automount/engfiler/vol/HomeDir1/DesignVerification/adnan.khaleel/tmp/IB= MJava2-142/jre/bin/java) 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: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. -----Original Message----- From: Nicholas Nethercote [mailto:nj...@cs...] Sent: Thursday, June 30, 2005 11:20 PM To: Adnan Khaleel Cc: Josef Weidendorfer; val...@li... Subject: RE: [Valgrind-users] Valgrind and Java On Thu, 30 Jun 2005, Adnan Khaleel wrote: > I tried the --trace-children=3Dyes and I get the following errors - = I've included the error I get with Valgrind and with callgrind. > Is this a plug-in error? > =3D=3D14065=3D=3D Warning: bad signal number -2 in sigaction() > [ Unable to allocate an initial java heap of 1835008000 bytes. ] > [ **Out of memory, aborting** ] > [ ] > [ *** panic: JVMST016: Cannot allocate memory for initial java heap ] Does the JVM really want a 1.8GB heap? That's pretty big. Does it work = if you run with --tool=3Dnone or --tool=3Daddrcheck? Those tools use = less=20 memory than Memcheck. The -2 signal number in sigaction() is also pretty strange. N |