You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(3) |
|
2
(4) |
3
(5) |
4
(8) |
5
(4) |
6
(2) |
7
(4) |
8
(3) |
|
9
(1) |
10
(6) |
11
|
12
(2) |
13
|
14
|
15
|
|
16
|
17
(6) |
18
(7) |
19
(1) |
20
(14) |
21
(2) |
22
(9) |
|
23
(1) |
24
(8) |
25
(6) |
26
(12) |
27
(24) |
28
(24) |
29
(2) |
|
30
(13) |
31
(4) |
|
|
|
|
|
|
From: Ashley P. <api...@co...> - 2008-03-26 12:44:21
|
On Tue, 2008-03-25 at 22:52 -0700, Greg Czajkowski wrote: > Hi all, > > Has anyone tried to create their own custom valgrind-listener? The > attached python script was the first attempt at having valgrind attach > to it. I wrote one a year or so ago in perl and it worked fine. > But the valgrind fails to connect. > ==11618== valgrind: failed to connect to logging server 'X.X.X.X:1500' > -3. > ==11618== Log messages will sent to stderr instead. The most common problem is binding to 127.0.0.1 instead of * when binding to the socket are you running on a single host, what does telnet X.X.X.X 1500 tell you? Ashley, |
|
From: David M. <dm...@gm...> - 2008-03-26 08:56:16
|
Hi everyone, Hope you are doing well, and thank you for your work on Valgrind. I have been using it happily for some months now as an invaluable aid to my research. I have a question I hope has not already been answered and which I haven't found the answer so far via searching the archives, if I missed something please let me know. Part of my work requires inspecting the arguments to library function calls such as memcpy, malloc, realloc, etc. to see if they meet certain criteria. The Valgrind function interception mechanism works well for this and other dynamically loaded functions for looking at the concrete values of these arguments. Indeed memcheck already uses it to look at the high bit of arguments to malloc/realloc and complains if it is set. The problem is that I *also* would like to know the name of the VEX IR basic block and IR registers or temporary variables which hold these arguments during execution at the post-instrumentation phase (i.e. the phase at which the VEX BB is passed to the tool). That is, if the guest calls malloc, I'd like to know during instrumentation that the current BB passed to my tool is malloc, that guest register X corresponds to argument 1, etc. (I am happy to explain in detail why I'd like this, but it's basically because I'm converting VEX IR on the fly into constraints which I attempt to solve for generating new inputs, and I want constraints that talk about function arguments.) The approach I have thought of so far is this: 1) Collect a table of the EIPs for the entry points to each function of interest (e.g. using the debug symbol parsing module), plus the calling convention used for each function 2) At instrumentation time, check each EIP in the basic block to see if the EIP is in the table 3) If so, hard-code instrumentation according to the calling convention, e.g. have constraints that talk about IR register X for the first argument I've been looking through the Callgrind sources for better understanding of 1) and 3), which is helpful but doesn't seem to be focused on the arguments as much. Has anyone else done this already or could suggest a better approach? Thanks, -David Molnar |
|
From: Greg C. <gre...@ya...> - 2008-03-26 05:52:46
|
Hi all,
Has anyone tried to create their own custom valgrind-listener? The attached python script was the first attempt at having valgrind attach to it.
But the valgrind fails to connect.
==11618== valgrind: failed to connect to logging server 'X.X.X.X:1500' -3.
==11618== Log messages will sent to stderr instead.
I modified the valgrind code to show that -3 is a failure in my_connect.
The regular valgrind-listener works fine.
Does anybody have any suggestions or tips?
FYI:
Primary build target: AMD64_LINUX
Secondary build target: X86_LINUX
Thanks in advance.
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping |
|
From: Solomon, B. <be...@ug...> - 2008-03-25 21:11:35
|
This is the change I made for 64 bits and VALGRIND_CHECK_MEM_IS_ADDRESSABLE/DEFINED Again I am not sure if this is to standard: - It changes the type of the macro to char * so presumably might cause client code to need change. - I reused the OrigFn type so there wasn't the need to create a new typedef for a pointer sized int type even though this case isn't a function pointer so it is a bit of a cheat. I just wasn't sure whether it was worth adding a new typedef and if so what naming scheme to use. Bernie |
|
From: Benjamin R. <ben...@nc...> - 2008-03-25 20:20:18
|
Hi,
I have noticed that, when I link my code statically, valgrind complains
about every exception that is caught. In the example code below, the
error is:
==32195== Conditional jump or move depends on uninitialised value(s)
==32195== at 0x44B8A4: __cxa_begin_catch (in
/home/bredelings/Devel/Sampler/Runs/test)
==32195== by 0x400361: main (in
/home/bredelings/Devel/Sampler/Runs/test)
If I link my code dynamically, this does not happen.
Question: Is it safe to ignore this warning?
------------------------------------------------------------
Kernel: AMD64 Linux 2.6.24 (Debian unstable)
GLibc: 2.7
GCC: 4.1, 4.2 and 4.3
4.0 does not have this problem.
compilation command:
% gcc test.C -o test -static
execution command:
% ./test 1 2 3 4 5
--------------Example code (test.C) ----------------
#include <iostream>
int main(int argc, char* argv[])
{
std::cout<<"argc = "<<argc<<"\n";
try {
if (argc > 3) {
throw int(2);
}
}
catch (int i) {
std::cout<<"caught exception = "<<i<<"\n";
}
exit(0);
}
---------------------Example code---------------------
thanks!
-BenRI
|
|
From: Solomon, B. <be...@ug...> - 2008-03-25 20:19:28
|
Yes a command line option is a possibility. Another is for mempool alloc to check that the memory used is marked noaccess initially and free to check that it is not noaccess which feels as if it should cover basically the same sort of problems as check_mempool_sane does rather slowly (and indeed it seems to have checks on itself in that it verifies the sort it does sorts!). But I don't know if that would cause issues with other peoples use of mempools. Bernie -----Original Message----- From: Bart Van Assche [mailto:bar...@gm...] Sent: Tuesday, March 25, 2008 12:26 AM To: Solomon, Bernard Cc: val...@li...; Julian Seward Subject: Re: [Valgrind-users] Couple of questions On Tue, Mar 25, 2008 at 12:42 AM, Solomon, Bernard <be...@ug...> wrote: > I am not quite sure where I am supposed to post patches. > This is the one removing the excessive checks though of > course other options are possible (check every so often, > have a command line switch etc.) > > I was using 3.3 but SVN seems the same. > > The 64 bit change I'll send separately if this is the > right place to send it. The check_mempool_sane() calls might be very useful to people who are debugging their added memory allocation client requests. Maybe it's better to modify the check_mempool_sane() function itself and to keep the check_mempool_sane() calls. E.g. a command line option could be added to Valgrind that lets the user specify whether or not to let checking happen when check_mempool_sane() is called. Bart. |
|
From: Oswald, M. <mic...@si...> - 2008-03-25 09:56:19
|
> > Assuming that's right, I don't see how it's ever going to work -- Valgrind > > provides an environment that is similar to native, but not identical, and > > any program that relies so much on things such as memory layout is a > > hopeless case for Valgrind, IMO. > I agree; and so (in contradition to my previous comments) I don't think > there's much point in you making a test case. (sorry) > GNU emacs has some similar kind of weirdness, resulting in it being > one of the few programs that won't run on Valgrind (at least with > a default build of emacs). It complains that it has run out of > memory as soon as it starts up, and quits. Ok, I was afraid of that. So I'll keep banging my head against the keyboard and hope that the responsible people will allow us to replace this trash somwhere in the near future. Many thanks to all, anyway! Michael |
|
From: Bart V. A. <bar...@gm...> - 2008-03-25 07:26:18
|
On Tue, Mar 25, 2008 at 12:42 AM, Solomon, Bernard <be...@ug...> wrote: > I am not quite sure where I am supposed to post patches. > This is the one removing the excessive checks though of > course other options are possible (check every so often, > have a command line switch etc.) > > I was using 3.3 but SVN seems the same. > > The 64 bit change I'll send separately if this is the > right place to send it. The check_mempool_sane() calls might be very useful to people who are debugging their added memory allocation client requests. Maybe it's better to modify the check_mempool_sane() function itself and to keep the check_mempool_sane() calls. E.g. a command line option could be added to Valgrind that lets the user specify whether or not to let checking happen when check_mempool_sane() is called. Bart. |
|
From: Julian S. <js...@ac...> - 2008-03-25 00:04:03
|
> >> Backtrace was generated from '/usr/bin/rhythmbox' > > > > I don't understand your report. You say that Rhythmbox crashes when > > running on Helgrind, but I don't see any evidence of that in the file > > Indeed, that's what I don't understand either: there's no trace of this > crash in the hellgrind log. Well, anyway, maybe you should forget about bug-buddy, and chase the lock order problems. It maybe that Valgrind is confusing bug-buddy; Valgrind does some strange things with signals. One other comment is that you really should use Helgrind and Memcheck together. See point (6) of http://www.valgrind.org/docs/manual/hg-manual.html#hg-manual.effective-use J |
|
From: Solomon, B. <be...@ug...> - 2008-03-24 23:42:21
|
I am not quite sure where I am supposed to post patches. This is the one removing the excessive checks though of course other options are possible (check every so often, have a command line switch etc.) I was using 3.3 but SVN seems the same. The 64 bit change I'll send separately if this is the right place to send it. Bernie -----Original Message----- From: Julian Seward [mailto:js...@ac...] Sent: Monday, March 17, 2008 6:25 PM To: val...@li... Cc: Solomon, Bernard Subject: Re: [Valgrind-users] Couple of questions > We have custom allocators so I used the mempool > interface as that matches our internals nicely - but I found the > check_mempool_sane > calls made things excessively slow so commented them out of alloc and > free which works > fine for me. These checks seemed overly paranoid for a well tested > allocator > to me and was wondering why they are there all the time (at least after > my > integration of the custom allocator is tested and working for us). I don't know. > The second issue is the user requests like VALGRIND_CHECK_MEM_IS_DEFINED > are documented to return the address of the first bad byte - yet > internally > they use a unsigned int type is which does not seem correct on 64 bit > machines > I would have expected that to be unsigned long or perhaps void *. That sounds like a straightforward 32-vs-64-bit bug. Can you fix both of these in a way that seems right to you, and send along a patch? Also, what version of V was this? J |
|
From: Frederik H. <fh...@te...> - 2008-03-24 23:10:48
|
On Mon, 24 Mar 2008 23:50:44 +0100, Julian Seward wrote: > Hi, > >> Backtrace was generated from '/usr/bin/rhythmbox' > > I don't understand your report. You say that Rhythmbox crashes when > running on Helgrind, but I don't see any evidence of that in the file Indeed, that's what I don't understand either: there's no trace of this crash in the hellgrind log. Yet, while Rhythmbox was running in hellgrind, GNOME's bug-buddy popped up, stating that it had caught a crash in Rhythmbox, and it printed the above broken stacktrace. -- Frederik Himpe |
|
From: Julian S. <js...@ac...> - 2008-03-24 22:54:49
|
Hi, > Backtrace was generated from '/usr/bin/rhythmbox' I don't understand your report. You say that Rhythmbox crashes when running on Helgrind, but I don't see any evidence of that in the file > Valgrind log: http://artipc10.vub.ac.be/rhythmbox.log It is clear that there's some problem with lock ordering in your app, and that is likely to result in deadlocks and other strange behaviour. I strongly suggest that you fix the problems Helgrind reports in the order they are reported. So first, try to find the root cause of the first error, starting .. ==6452== Thread #1: lock order "0x13D51268 before 0xE7D7D68" violated See http://www.valgrind.org/docs/manual/hg-manual.html#hg-manual.lock-orders for some background on lock order problems and why they are likely to result in deadlocks. J |
|
From: Frederik H. <fh...@te...> - 2008-03-24 22:15:01
|
I'm trying to help debugging a mutex deadlock in the Rhythmbox application (http://bugzilla.gnome.org/show_bug.cgi?id=512226). I though it would be interesting to run Rhythmbox under valgrind/helgrind, and see if that would give any clue. Now the problem is that while running under valgrind/helgrind, Rhythmbox crashes already during startup, with a very broken and strange stack trace caught by bug-buddy: Backtrace was generated from '/usr/bin/rhythmbox' [?1034hUsing host libthread_db library "/lib64/libthread_db.so.1". 0x0000000038010c73 in _start () at rtld.c:788 in rtld.c #0 0x0000000038010c73 in _start () at rtld.c:788 #1 0x000000003800bc70 in ?? () #2 0x0000000000000100 in ?? () #3 0x0000000402005058 in ?? () #4 0x010000000000041e in ?? () #5 0x0000000000000048 in ?? () #6 0x00000004023e4360 in ?? () #7 0x00000004023e4318 in ?? () #8 0x0000000038c83140 in ?? () #9 0x00000004023e43a8 in ?? () #10 0x0000000038020be7 in dl_open_worker (a=0x4020011a8) at dl-open.c:216 #11 0x0000000409a7bc60 in ?? () #12 0xffffffffffffffff in ?? () #13 0x00000000380207c3 in _dl_open (file=0x40298de88 "`¼§\t\004", mode=160543792, caller_dlopen=0x40298de80, nsid=512, argc=43572880, argv=) at dl-open.c:590 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Valgrind log: http://artipc10.vub.ac.be/rhythmbox.log Does anybody have a clue about what could be wrong, either with this crash, either with the original problem I was trying to debug? What things could I try further to debug this? valgrind-3.3.0-3mdv2008.1 glibc-2.7-11mnb1 gcc-4.2.3-6mnb1 2.6.24.3 x86_64, Mandriva Linux 2008.1 Cooker -- Frederik Himpe |
|
From: Julian S. <js...@ac...> - 2008-03-24 11:57:34
|
On Monday 24 March 2008 11:48, Bart Van Assche wrote:
> On Sat, Mar 22, 2008 at 12:06 AM, Jason Evans <ja...@ca...> wrote:
> > Firefox recently started embedding a custom memory allocator (jemalloc),
> > but Firefox developers still want to be able to use valgrind, so I added
> > the necessary VALGRIND_{MALLOC,FREE}LIKE_BLOCK() macro calls to make
> > this work (sans redzones).
>
> Hello Jason,
>
> Is jemalloc always loaded as a shared library in Firefox (and not
> linked statically) ? In that case there is an alternative to inserting
> client requests in the Firefox source code, namely applying the
> attached patch to the Valgrind source code. This patch makes Valgrind
> recognize libjemalloc's memory allocation functions.
Does jemalloc have semantics beyond standard malloc/free?
I had the impression that it allows multiple independent allocation
pools.
J
|
|
From: Bart V. A. <bar...@gm...> - 2008-03-24 10:48:22
|
On Sat, Mar 22, 2008 at 12:06 AM, Jason Evans <ja...@ca...> wrote:
> Firefox recently started embedding a custom memory allocator (jemalloc),
> but Firefox developers still want to be able to use valgrind, so I added
> the necessary VALGRIND_{MALLOC,FREE}LIKE_BLOCK() macro calls to make
> this work (sans redzones).
Hello Jason,
Is jemalloc always loaded as a shared library in Firefox (and not
linked statically) ? In that case there is an alternative to inserting
client requests in the Firefox source code, namely applying the
attached patch to the Valgrind source code. This patch makes Valgrind
recognize libjemalloc's memory allocation functions.
Bart.
|
|
From: Ouyang J. <soy...@gm...> - 2008-03-24 03:12:35
|
Hi, just a test here. |
|
From: Ouyang J. <soy...@gm...> - 2008-03-24 03:03:32
|
Hi, I saw "There is experimental support for AIX 5.3, both 32-bit and 64-bit processes." in valgrind-3.3.0/NEWS. So I tried to compile Valgrind on AIX. After change on LDFLAGS, everything went well. But when I executed valgrind, I got: "./valgrind: can't stat /usr/local/lib/valgrind/ppc64-aix5/memcheck". There are lots of stuffs in /usr/local/lib/valgrind: bash-3.00# pwd /usr/local/lib/valgrind bash-3.00# ls aix5libc.supp glibc-2.5.supp ppc64-aix5 cachegrind-ppc32-aix5 glibc-2.6.supp vgpreload_core-ppc32-aix5.so cachegrind-ppc64-aix5 glibc-2.7.supp vgpreload_core-ppc64-aix5.so callgrind-ppc32-aix5 glibc-2.X-drd.supp vgpreload_exp-drd-ppc32-aix5.so callgrind-ppc64-aix5 helgrind-ppc32-aix5 vgpreload_exp-drd-ppc64-aix5.so default.supp helgrind-ppc64-aix5 vgpreload_exp-omega-ppc32-aix5.so exp-drd-ppc32-aix5 lackey-ppc32-aix5 vgpreload_exp-omega-ppc64-aix5.so exp-drd-ppc64-aix5 lackey-ppc64-aix5 vgpreload_helgrind-ppc32-aix5.so exp-omega-ppc32-aix5 massif-ppc32-aix5 vgpreload_helgrind-ppc64-aix5.so exp-omega-ppc64-aix5 massif-ppc64-aix5 vgpreload_massif-ppc32-aix5.so glibc-2.2-LinuxThreads-helgrind.supp memcheck-ppc32-aix5 vgpreload_massif-ppc64-aix5.so glibc-2.2.supp memcheck-ppc64-aix5 vgpreload_memcheck-ppc32-aix5.so glibc-2.3.supp none-ppc32-aix5 vgpreload_memcheck-ppc64-aix5.so glibc-2.34567-NPTL-helgrind.supp none-ppc64-aix5 xfree-3.supp glibc-2.4.supp ppc32-aix5 xfree-4.supp bash-3.00# oslevel 5.3.0.0 bash-3.00# find ppc64-aix5/ ppc64-aix5/ ppc64-aix5/libcoregrind.a ppc64-aix5/libvex.a Compared to valgrind in linux, there should be memcheck, helgrind, callgrind... in ppc64-aix5? I tried to make a soft link to memcheck-ppc64-aix5/memcheck-ppc64-aix5, it core dumped. What should I do to make it work? Thanks in advance! |
|
From: Martijn V. <ma...@be...> - 2008-03-23 22:40:39
|
Hello all, I made a very simple first version of a program to visualize the output of the massif tool. Since I don't have too much free time on my hands I had some doubts about releasing it now, since I'm not sure if I'll have the time to do something with any comments I'll (hopefully) get. I decided to put it up somewhere anyway so that somebody won't need to do any work which has already been done ;-) You can check it out here http://www.aaltjegron.nl/msplot/ Please let me know what you think about it. preferably via this list or on the email address msplot(at)aaltjegron.nl, since this will filter your mail to the right box and I'll have a larger chance of finding it between all the spam. sincerely, martijn versteegh |
|
From: Julian S. <js...@ac...> - 2008-03-22 22:29:52
|
> vex x86->IR: unhandled instruction bytes: 0xFF 0x58 0xEB 0x5 > > I think it is a valid opcode, but could you please confirm? I think that can only be "CALLF Ep" or "JMPF Ep" (far call, far jump). J |
|
From: Nicolas <ni...@gm...> - 2008-03-22 22:05:21
|
Hello, I got the following error from Valgrind: vex x86->IR: unhandled instruction bytes: 0xFF 0x58 0xEB 0x5 ==7452== valgrind: Unrecognised instruction at address 0x8BCB558. ==7452== Your program just tried to execute an instruction that Valgrind ==7452== did not recognise. There are two possible reasons for this. ==7452== 1. Your program has a bug and erroneously jumped to a non-code ==7452== location. If you are running Memcheck and you just saw a ==7452== warning about a bad jump, it's probably your program's fault. ==7452== 2. The instruction is legitimate but Valgrind doesn't handle it, ==7452== i.e. it's Valgrind's fault. If you think this is the case or ==7452== you are not sure, please let us know and we'll try to fix it. I think it is a valid opcode, but could you please confirm? Regards, Nicolas |
|
From: Jason E. <ja...@ca...> - 2008-03-22 16:56:27
|
Bart Van Assche wrote: > Will the Valgrind client requests be included in the official Firefox > source code distribution ? Firefox is an interesting application to > test Valgrind tools, and having these client requests in the official > source distribution would help us (the Valgrind developers). Yes, I think the valgrind client request code will be included in the Firefox source, but it will be necessary to build a custom Firefox binary with the --with-valgrind configure option specified, since the calls will not be enabled by default. The feature addition is being tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=424040 Jason |
|
From: Bart V. A. <bar...@gm...> - 2008-03-22 16:23:48
|
On Sat, Mar 22, 2008 at 4:47 PM, Jason Evans <ja...@ca...> wrote: > Christoph Bartoschek wrote: > > Do you have the traceback with debug information and the code that produces > > the erorr? You could check right after allocation from the system that the > > whole range is accessible with valgrinds macros. > > Thank you for your suggestion; it helped me find my mistake. Valgrind > did have the whole range marked as accessible, and writes/reads worked > fine to begin with. The problem was that in another place I was calling > MALLOC_FREELIKE_BLOCK(ptr, size), but the second argument is redzone > size, not allocation size. This deallocated object was close enough to > the large object for the erroneous redzone to overlap. Whoops. Hello Jason, Will the Valgrind client requests be included in the official Firefox source code distribution ? Firefox is an interesting application to test Valgrind tools, and having these client requests in the official source distribution would help us (the Valgrind developers). Bart. |
|
From: Jason E. <ja...@ca...> - 2008-03-22 15:47:17
|
Christoph Bartoschek wrote: > Do you have the traceback with debug information and the code that produces > the erorr? You could check right after allocation from the system that the > whole range is accessible with valgrinds macros. Thank you for your suggestion; it helped me find my mistake. Valgrind did have the whole range marked as accessible, and writes/reads worked fine to begin with. The problem was that in another place I was calling MALLOC_FREELIKE_BLOCK(ptr, size), but the second argument is redzone size, not allocation size. This deallocated object was close enough to the large object for the erroneous redzone to overlap. Whoops. Thank you everyone for your help. Jason |
|
From: Christoph B. <bar...@or...> - 2008-03-22 10:10:30
|
Am Samstag, 22. März 2008 schrieb Jason Evans: > I tried increasing the alignment of internal allocations in order to > avoid this problem. If this large object is 64 or 128 bytes past the > beginning of a page boundary, the problem persists. If it is any power > of two in [256..4096] past a page boundary, the problem goes away. > > Does anyone familiar with valgrind's internals have some idea of what > the problem is? My guess is that objects of this size are usually more > strictly aligned, and that I'm hitting an edge case that other > allocators happen to avoid. Do you have the traceback with debug information and the code that produces the erorr? You could check right after allocation from the system that the whole range is accessible with valgrinds macros. Christoph |
|
From: Julian S. <js...@ac...> - 2008-03-22 00:54:03
|
On Saturday 22 March 2008 01:32, Nicholas Nethercote wrote: > On Fri, 21 Mar 2008, Oswald, Michael wrote: > >> I would say first that in my view using MAP_FIXED for anything is a > >> bad idea. It silently replaces or truncates any existing mapping which > >> overlaps the requested range, but there is no easy way to know > >> beforehand if this will happened. The only way to use it safely is to > >> have some way to know what the process' address space layout is, like > >> reading /proc/self/maps, or in some very specialised situations, as > >> ld.so does. > > > > I totally agree with that. The system I am working on was developed by > > many companies and we proposed a few times to drop POST and use something > > different, more portable and safe, but the proposal was never accepted. > > So you run the program natively, write out a data structure from memory to > a file, and then try to read it in from a program running under Valgrind? > And it doesn't work because the reading-in expects the data structure to be > at exactly the same address as when it was written out? > > Assuming that's right, I don't see how it's ever going to work -- Valgrind > provides an environment that is similar to native, but not identical, and > any program that relies so much on things such as memory layout is a > hopeless case for Valgrind, IMO. I agree; and so (in contradition to my previous comments) I don't think there's much point in you making a test case. (sorry) GNU emacs has some similar kind of weirdness, resulting in it being one of the few programs that won't run on Valgrind (at least with a default build of emacs). It complains that it has run out of memory as soon as it starts up, and quits. J |