On Tuesday, April 03, 2012, Peter Toft wrote:
> Hi Valgrinders
>
> I am debugging a beast of C/C++ - ~800.000 lines of code.
800k LOC is small (very) compared to some ..
> I see with GCC 4.5.2 and valgrind 3.7.0 on Red Hat 5.7 64 bit, that
> valgrind exits with no warning. Bummer!
Is it usi
On Monday, March 26, 2012, Per Bull Holmen wrote:
> What is the current status on valgrinding OpenGL applications for Mac
> OS X? I remember last time I tried, I just got an awful lot of error
> reports from inside opengl functions, even though the app worked
> perfectly... so I just gave up.
It
> In sum, you should get one *possible* execution, but it won't necessarily
> be one typical of truly concurrent execution. (Just because you have
> threads that are *runnable* at the same time does not mean that they
> actually run *concurrently* in a real system, unless you guarantee
> multuple
On Friday, March 23, 2012, Eliot Moss wrote:
> On 3/23/2012 9:10 AM, Hamid Reza Khaleghzadeh wrote:
> > Hi,
> >
> > I have some questions about Valgrind tool. I would be thankful if answer
> > me.
> >
> > 1- I want to know does Valgrind support Pthread and openMP programs?
> > 2- I need a tool th
On Tuesday, March 20, 2012, Sohail Shafii wrote:
> Undefined symbols for architecture i386:
> "_PMPI_Type_extent", referenced from:
>
Are you trying to build w/ the MPI checking library, or is that
just an unintended side effect? If the latter, you can disable
the build of libmpiwrap.dyli
On Wednesday, March 14, 2012, Ian Mallett wrote:
> I'm trying to get Valgrind working on a virtual machine running Ubuntu
> 9.04. The computer is a x86-64 architecture, and the Ubuntu distro of the
> virtual machine *should* have been x86, and is a basically fresh OS
> install. To install Valgri
On Tuesday, March 13, 2012, Ólafur Waage wrote:
> Removing SSE4.1 and SSE4.2 flags did the trick. Thanks.
SSE4.x isn't supported in 32-bit mode, but it is in 64 bit
mode. So, if you need it, rebuild your program as a 64 bit
app, and try again.
J
-
On Sunday, February 26, 2012, Steve Burden wrote:
> > I don't understand why it fails unless if was added since you checked
>
> out from SVN.
>
> Ok apparently there have been some changes to the guest_amd64_toIR.c file
> since I checked out, everything runs fine with the HEAD revision :).
Are
On Friday, February 24, 2012, erotavlas_tu...@libero.it wrote:
> Hi all,
>
> I would like to use Helgrind tool of Valgrind but I read on the manual the
> following statement: Runtime support library for GNU OpenMP (part of GCC),
> at least for GCC versions 4.2 and 4.3. The GNU OpenMP runtime libra
I have had it running on a Nexus S and more recently on a
Motorola Xoom (the original version, not Xoom 2). The Xoom
is somewhat more practical as it has more CPU clout and more
memory.
That said however, running any real sized application (anything
that wants to do graphics, I think) requires
On Friday, March 02, 2012, SFBay Area wrote:
> Hi,
>
> I have started coding in C++ and use a lot of templates, and I do mean a
> lot. Unfortunately, my type names became way too long for Valgrind to
> handle. Currently, it seems that it cuts the type name at around 4100
> characters (slightly les
On Thursday, February 23, 2012 02:02:23 PM Eliot Moss wrote:
> On 2/23/2012 7:51 AM, jee wrote:
> > My code change itself with running, and, I use
> > VALGRIND_DISCARD_TRANSLATIONS with I changed the function's assembly
> You have self-modifying code, so probably need to specify
> some flavor of t
On Thursday, February 23, 2012, John Reiser wrote:
> > --2990-- Considering /usr/lib/mylib.so.debug ..
> > --2990-- .. CRC is valid
> >
>
> Based on what you did say, it is somewhat likely that valgrind got confused
> by the debugging info in your executable program. Find a program which
> p
> Background: I am using Valgrind on optimized SSE4.2 output from the
> Intel C Compiler. I am seeing massive amounts of "Invalid read of
> size 8" false positives. I believe these false positives would
> disappear if "--partial-loads-ok=yes" worked as documented. The
> problem is that it does
I just committed a fix (vex r2255).
J
On Thursday, February 16, 2012, Tom Hughes wrote:
> On 16/02/12 02:26, Patrick J. LoPresti wrote:
> > Disassembly of myApp leading up to 0x1FF07B5:
> > 0x1ff07aa<__intel_get_new_mem_ops_cpuid+26>:mov
> > %edx,0xc(%r9) 0x1ff07ae<__intel_get
> So ... I am running tests with the decoder revised
> to allow 0x66 on the fpu instructions.
>
> Does anyone know of a reason why doing this would
> be bad/wrong?
Giving a blanket OK for 0x66 on FPU instructions makes me
nervous, that we might inadvertantly accept an 0x66 prefix
that had some s
Hmm, this doesn't sound like it's going to be simple to fix in
a clean way.
For the moment, can we do the incremental fix of taking Philippe's
patch (with the off-by-one fixed) ? That's a very simple patch
and uncontroversial patch. (Maybe should also backport it for
3.7.1 ?)
J
On Tuesday, F
On Saturday, February 11, 2012, Philippe Waroquiers wrote:
> On Fri, 2012-02-10 at 16:01 +, Rob wrote:
> > Thanks for the patch. I have manually applied it to 3.7.0 (not svn) and
> > it is a big improvement.
> >
> > The number seems to be offset by 1 from what I would expect though, eg.
> >
> at runtime if AES is supported or not (e.g. if this is checked at
> installation time and different executable is installed depending on
> this install check, then no luck (until Valgrind supports the AES
> instructions).
Yeah, I agree with that analysis. The failing instruction is in a
system
> Does valgrind restrict the number of open files? I noticed
> that the benchmark had over 50 files open, and might have
> hit a limit if it is set at 64 or something.
No; or if it does, to something quite high, like 1024 or some such.
> I also have one run that just core dumps. No valgrind
> en
> Why only VEX? I also added tests in none/test/amd64.
> Is there some reason to avoid svn up in the valgrind
> top-level directory?
Oh, I forgot :)
So .. VEX and valgrind are different svn repos. You need to
svn up in both. Then svn diff -rHEAD in both. That generates
two patches -- the impl
> This would be a good time to ask about how to prepare and send
> patches, i.e., what you want for these (re)additions.
# merge any other changes that happened in the meantime
cd VEX
svn up
cd ..
# remake, re-test
# generate diff
cd VEX
svn diff -rHEAD
# send the diff
One thing though. Bugs
> I did that, but when I run the updated valgrind on
> the same program as before (Oracle's HotSpot JVM),
> it fails on a 0xF 0xAE 0x3F instruction, which
> appears to be either a CLFLUSH or an SFENCE (both
> decode the same way in the docs, so I am slightly
> confused). Either way, it worked in
> 0x66 0x0F 0x3A 0x61 0x06 0x0D: PCMPESTRI for 16-bit characters
>For this one I am attempting to add the 16-bit versions of those
>PCMPxSTRx instructions already supported for 8-bit. Once
>I have tested it some, I will see about submitting a patch.
>It's relatively straightforwar
On Thursday, January 26, 2012, David Henningsson wrote:
> Hi,
>
> I'm trying to run PulseAudio under valgrind, and I think valgrind is
> reporting a false positive; i e, it reports "Conditional jump or move
> depend on uninitialised value(s)" where in fact the value seems to be
> perfectly initial
> I did try massif, but the program is terminated (3G limit)
> before I get any output. It seems to happen extremely fast.
Maybe try to find a smaller workload that allows Massif to
complete successfully, so you can get some results from it.
Also as Philippe says, if Memcheck indicates any error
You need to figure out whether the extreme growth is due to the
behaviour of your program, or a bug in Valgrind. You can investigate
the space usage of your program in various ways (some of which
PhilippeW has already described) and you can also use the tools
--tool=massif and (advanced, but some
On Tuesday, December 13, 2011 09:04:09 pm janjust wrote:
> Hey group,
> I'm wondering if it's possible to intercept the malloc calls without
> having to call valgrind's malloc wrapper.
> The reason being is that I'm noticing the wrapper allocating chunks in
> different sizes than say glibc's ma
On Thursday, December 15, 2011 04:18:52 am 奕楠 邱 wrote:
> Hello,
> I want to know the place where valgrind intercepts every memory
> access(store & load) I want to log the every access behavior inside the
> program, Does anyone know which function of which file can achieve
> this?(inside the directo
On Friday, November 25, 2011, Alexander Graf wrote:
> That way I was able to at least debug my actual problem.
Good.
> It would still be nice to have a real fix at the end of the day though.
> Would you prefer me to file a bug report or is this email enough to make
> you aware of it? :)
Please
> I
> find that Helgrind and DRD reports the same - and I see the problems
> very very seldom (similar to memtool) ,
> ==4698==
> Destroying locked mutex: mutex 0x4fc0808, recursion count 1, owner 3.
> ==4698== at 0x490B014: pthread_mutex_destroy
> (drd_pthread_intercepts.c:569)
> ...
> ==4698
On Thursday, November 24, 2011, Alexander Graf wrote:
> agraf: 0xEB0D 0x0E4B: that is ADD.W r14, r13, r11 lsl 1 (encoding
> T3) so looks ok let me just see if it's fixed in svn
> nope, svn still has this bug, valgrind isn't allowing ADD.W rd,
> r13, rm, shifted
>
> I'm not that deep into valg
On Thursday, November 24, 2011, Peter Toft wrote:
> Since my problem happens very
> seldom, one follow-up question is whether I can combine --tool=memtool
> and --tool=drd in one run?
No, you can't.
But note: it might be that the problem occurs all the time (a race of
some kind, for example) but
> Question; Can I ... or should I ... also throw "valgrind
> --tool=helgrind" into the game? I have not been using this yet.
You can use --tool=helgrind or --tool=drd to check threaded
programs for errors. They provide similar functionality but using
different algorithms, and using both is often
On Tuesday, November 15, 2011, Александар Миленковић wrote:
> Thanks for the replies so far!
>
> But I don't see a autogen.sh script in Valgrind root. The ones i do
> have are as follows
> compile, config.guess, config.status, configure, depcomp, install-sh,
> missing and vg-in-place
>
> So thats
On Saturday, November 12, 2011, Jesper Friis wrote:
> Dear all,
> I get "Invalid read of size 8" in strspn(). The error can be reproduced by
> the following small program on Fedora 15 (glibc-2.14-5.x86_64):
Upgrade to 3.7.0. 3.6.1 doesn't support glibc-2.14 properly. Then, if
the error is still
> Now, the only difference between the readme.android and this I see is
> that in the readme, they say i should see this:
> # Platform variant: android
> # Primary -DVGPV string: -DVGPV_arm_linux_android=1
>
> ... so, how do I hack this platform variant to return a proper result? :)
> access is safe. This leads me to believe that Helgrind is not recognizing
> the fact that the variables are thread-local.
Possibly so; but it's too hard to diagnose without a specific test case.
Please send a small program that shows the problem, or (better) file a
bug report and attach the fi
We are pleased to announce a new release of Valgrind, version 3.7.0,
available from http://www.valgrind.org.
Valgrind is an open-source suite of simulation based debugging and
profiling tools. With the tools that come with Valgrind, you can
automatically detect many memory management and threadi
On Wednesday, November 02, 2011 09:31:18 am Peter Toft wrote:
> #include /* Save as code.c */
> int main(void) { int
> i=-1,a[2],b[2],c[2];
> a[0] = 1; a[1] = 2; b[0] = 3; b[1] = 4; c[0] = 5;
> c[1] = 6;
> printf("%i %in",b[i],a[i]); return 0;
> }
> I cannot see exp-sgcheck catching anything
> Can you give an explicit literal example?
> >
> > This works for me: valgrind 3.7.0-SVN on Fedora 14 x86_64.
> > It does not complain about SSE2 not supported:
> > -
> > $ /usr/local/valgrind-svn/bin/valgrind -v
> > /usr/lib/jvm/java-1.6.0-openjdk-1.6.
On Monday, October 10, 2011, Francesco Zappa Nardelli wrote:
> Dear all
>
> if I understand correctly, the function
>
> VG_(get_datasym_and_offset)(..addr..&name...)
>
> looks at the debug informations to return the name and the offset of
> the (global) variable stored at addr.
>
> This works
Hi,
You need to ask the people who maintain the FreeBSD port about this.
J
On Friday, October 07, 2011, Mustafa Reşit Şahin wrote:
> Hi all,
>
> I am using Valgrind in FreeBSD. I am getting an error about semaphores.
> I would like to know if valgrind supports semaphores in FreeBSD?
>
> If it
On Thursday, September 22, 2011, pankaj pawan wrote:
> Hi all,
>
> For a simple program with two consecutive reads to same registers.
>
> 0x80483e3: mov0x8049ce0,%eax (a)
> 0x80483e8: mov0x8049cd0,%eax (b)
These are writes to registers, not reads from them.
> IR
> $ arm-linux-gcc -W -Wall -gdwarf-2 hello.c -o hello
What happens if you use plain -g rather than -gdwarf-2 ?
J
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers
er somewhere else!
>
> Shall I really do some bugreport?
>
> Valgrind crashes and give the following output:
> > ==27561== Memcheck, a memory error detector
> > ==27561== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
> > ==27561== Using Valgrind-3.
On Friday, September 02, 2011 12:56:25 AM David Lerner wrote:
> > # valgrind -v ./diftDec dift_422cmode2_no_hdr.data output.dat -hdr -f
> > 422 Illegal instruction
>
> I'm seeing the same symptom on a cortex a9 (see 1 below) which doesn't have
> the SIMD (neon) nor VFP extensions. From the arm r
That's a bit strange, considering that it does work well on the A8. There
must be something a bit funny about your setup. I wonder if it is to do
with ucLibc. Or something alignment related, maybe.
w.r.t. your SoC, what capabilities does the CPU have? Neon? VFP?
> ==483== Process terminatin
It might be that I fixed something like that post-3.6.0. I don't
remember now. Have you tried the svn trunk ?
J
On Monday, August 29, 2011 04:54:58 AM Jeffrey Walton wrote:
> Hi All,
>
> Is it safe to ignore warnings from mythread_wrapper?
>
> The test program causing the warning spins up 64
> So for this particular instruction it generates 2 READ events and 1 WRITE
> event.
Yes. It translates all atomic operations into C-A-S sequences.
> But there would be only 1 READ and 1 WRITE followed by a flush when it runs
> on a processor. Am I right?
I have no idea how a processor would a
Just to add my 2 euro-cents (basically Bart said it all already, tho)
My impressions are that:
1. Double checked locking is fundamentally broken:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
2. Even if you verify by hand the resulting machine code, you still need
> Does the most recent version of Valgrind support Lion?
> If it does support, any documentation and help would be appreciated.
The latest formal release (3.6.1) does not support it. However
I am working to make the svn trunk support it. This is being tracked
at https://bugs.kde.org/show_bug.cg
On Thursday, August 18, 2011, Martin Heller wrote:
> Hi all,
>
> is it possible to make Helgrind print out stack trace for all threads at
> a given moment?
> I am debugging a quite complex program (~20 threads) and this would
> really help me finding the origins of a deadlock which occurs when
> r
On Wednesday, August 10, 2011, ENDERLIN Christophe wrote:
> Do you plan to make Valgrind work under OSX Lion ? And if so, do you know
> when ?
Yes. I had already a preliminary look at this, and will spend
more time on it probably starting some time next week. How
successful this will be, and ho
On Wednesday, July 20, 2011, John Reiser wrote:
> > Does it mean that valgrind can not run with NFS mount?
Should work fine with NFS. I haven't heard that it doesn't.
If you want to cross-compile for Android, check out the svn trunk
and follow the instructions in README.android.
If you want a n
> Ok, makes sense. Tom Hughes suggested that I create a bug and attach
> my patch, so that's what I did. If it is going to be a significant
> performance hit, maybe it would be better to have an option that can
> turn this on for all syscalls?
In the past we've simply added the SfMayBlock flags o
Does it help if you give the flag --vex-guest-chase-thresh=0 ?
This guarantees that each new basic block is translated into
its own IR block.
J
On Saturday, July 16, 2011, David Granchinho wrote:
> Hi! I've modified lackey so that it tracks every time a function
> belonging to a specified group
> Is there any way I can get the address stored at those temporaries?
Sounds like you're confusing the concepts of JIT-time and run-time.
JIT-time is one-time instrumentation of each block, immediately before it is
used, and is what you're doing in the code fragment you posted. Run-time
is when
On Friday, July 08, 2011, Greg Czajkowski wrote:
> > Did you change any #defines in the source code? Is this a clean 3.6.1.
> > build?
>
> #define VG_N_SEGMENTS 5
>
> Plus the failed attempt at extending valgrind to use more than 32GB
>
> # if VG_WORDSIZE == 8
> ///gczajkow aspacem_max
You'd be well advised to play around with a standard build of
Valgrind, with "--tool=none --trace-flags=10001000 --trace-notbelow=0"
to get some idea what you're going to be able to get from vex.
> I've spent a bit of time looking at libvex.h and libvex_ir.h, and it
> seems as though this should
> mc_main.c:5972 (mc_pre_clo_init): Assertion 'MAX_PRIMARY_ADDRESS ==
> 0x7ULL' failed.
Did you change any #defines in the source code? Is this a clean
3.6.1. build?
J
--
All of the data generated in your IT in
On Thursday, July 07, 2011, WAROQUIERS Philippe wrote:
> As part of Valgrind 3.7.0 SVN (not yet released so), a gdbserver has
> been integrated
> in Valgrind.
> With this gdbserver, the process running under Valgrind can be "fully"
> debugged
> (e.g. it is possible to use break/next/info thread/...
> Really? Can you send a complete test program that demonstrates this?
Oh, I didn't read it carefully enough. Ignore that. I'll get
another coffee.
J
--
All of the data generated in your IT infrastructure is seriousl
On Thursday, June 30, 2011, Szabolcs Nagy wrote:
> in a custom allocator like
>
> int *alloczero() {
> int *p = malloc(sizeof *p);
>
> if (*p)
> *p = 0;
> return p;
> }
>
> valgrind reports 'conditional jump..'
> at line 'if (*p)', which is correct
> and easy to suppress
>
>
> I thought anything in a pub_tool_* header was available to tools?
Yeah .. it is. I'm not exactly clear about the architectural rationale
of having a formal core-tool interface (include/pub_tool_tooliface.h) and
also a bunch of functions (include/pub_tool_everythingelse.h). There's
probably a
> What you need to look at is VG_(atfork) in include/pub_tool_libcproc.h
> anyway, which will let you register callbacks to be called at various
> points in the fork process.
That's not part of the formal core-tool interface though.
Another possibility is to use the VG_(needs_syscall_wrapper)
fac
On Wednesday, June 29, 2011, CHEN Hong lin wrote:
> Hi,
> I managed to cross-compile valgrind for linux on ppc (MPC8313), but
> failed to run it. Below is the err info caught by strace.
> What's wrong with it? Thanks in advance.
> BTW, the configure options are like:
> configure --host=power
> vex amd64->IR: unhandled instruction bytes: 0x49 0xF 0xFC 0x6B 0x10 0xF
This instruction (paddb) is supported, but I think the 0x49 might be a
redundant REX prefix that causes the problem. It would help to see a
disassembly of the instruction and the few on either side; can you get
that? Runn
Try building the svn trunk, as described as
http://www.valgrind.org/downloads/repository.html
since this problem might already have been fixed there
(not sure, but worth a try.)
J
On Wednesday, June 15, 2011, Nuno Cardoso wrote:
> Hi list,
> I cross-compile valgrind-3.6.0 to run on devkit8000
On Wednesday, June 01, 2011, Nicholas Nethercote wrote:
> On Mon, May 30, 2011 at 11:04 PM, Josef Weidendorfer
>
> wrote:
> > this really sounds like a discussion on the color of the bike shed.
I agree.
> I want to keep short prefixes. 2 or 3 letters is fine; DRD uses
> 'drd' in a lot of pl
On Wednesday, May 25, 2011, Josef Weidendorfer wrote:
> On Wednesday 25 May 2011, Florian Krohm wrote:
> > On 05/25/2011 04:06 AM, Josef Weidendorfer wrote:
> > > You need to use callgrind_annotate.
> > > cg_annotate is the tool for cachegrind output.
> > >
> > > The naming is a little bit unfortu
It's not directly what you're after, but have you tried the exp-dhat
tool in 3.6.x ? (--tool=exp-dhat)
Amongst things it can find allocation stacks responsible for large amounts
of short term allocation, which sounds like what you're trying to find.
See
http://www.valgrind.org/docs/manual/dh-
> 1) Suppose that there is a global array named 'global_array'. Image the
> scenario where Thread1 does *global_array[0]*=value1 and Thread2 does *
> global_array[1]*=value2 without any protection. Clearly, that scenario does
> not cause any inconsistency problems. Is it possible that helgrind re
> write(1018, "C", 1) = 1
> rt_sigprocmask(SIG_SETMASK, [], ~[ILL TRAP BUS FPE KILL SEGV STOP], 8) = 0
> read(162, "", 2952) = 0
> rt_sigprocmask(SIG_SETMASK, ~[ILL TRAP BUS FPE KILL SEGV STOP], NULL, 8) =
> 0 gettid()= 30593
> Running memcheck on our large binaries (5-10GB resident) causes mem check
> to abort. Any ideas?
By default Memcheck is limited to using the first 32GB of memory,
so it can't manage processes that go over about 14GB natively. That's
adjustable though.
I'm more concerned about a couple of othe
> > > For example, I have such fragment:
> > > for (j = 0; j < length; j++) {
> > >
> > > for (i = ip[j]; i <= ip[j+1]-1; i++) {
> > >
> > > b[ia[i]] = b[ia[i]] + a[i]*x[j];
> > >
> # valgrind --tool=memcheck --leak-check=yes --show-reachable=yes
> --num-callers=20 ./test-arm-static
> ==2131== HEAP SUMMARY:
> ==2131== in use at exit: 0 bytes in 0 blocks
> ==2131== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==2131==
> ==2131== All heap blocks were freed -
> > with C/C++ code compiled with LLVM/clang 2.9. There are some kinks:
> > * Line information is missing in valgrind report. That works when
> > compiling with gcc.
>
> Try the patch below. It fixes it for me.
Committed as r11705.
J
-
> Can anyone tell me, is it possible to collect number of fetches and
> cache misses for a particular array using Callgrind/Cachegrind?
> For example, I have such fragment:
>
> for (j = 0; j < length; j++) {
> for (i = ip[j]; i <= ip[j+1]-1; i++) {
>
On Wednesday, April 20, 2011, Patrick Ohly wrote:
> I use valgrind-3.6.0.SVN-Debian on Debian Stable/Testing in 64 bit mode,
> with C/C++ code compiled with LLVM/clang 2.9. There are some kinks:
>
> * Line information is missing in valgrind report. That works when
> compiling with g
> * Line information is missing in valgrind report. That works when
> compiling with gcc.
Yes, I noticed that too. I haven't investigated. btw, you should
have a look at https://bugs.kde.org/show_bug.cgi?id=242137,
which is also related to a LLVM+Valgrind issue.
> * clang c
On Tuesday, April 19, 2011, Wan Mohd Fairuz Wan Ismail wrote:
> Hi,
> I see that there are efforts to make Valgrind works on Android as referred
> in https://bugs.kde.org/show_bug.cgi?id=266035 .. Will these patches make
> it to the next release of Valgrind?
See https://bugs.kde.org/show_bug.cgi?i
> I want to use valgrind to debug my memory leaking application on PowerPC
> 64 bit machine running AIX 5.3.
> Can someone please tell me if valgrind is supported on AIX or not. If
> yes which version I should use.
Basically, no. The last version that worked was 3.4.1, and support
for AIX is lik
On Tuesday, April 05, 2011, Stefan Kost wrote:
> hi,
>
> I just upgraded my disto
What's the new distro?
J
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable netwo
y_char1 = new char[100];
> array_char[4] = 'b';
> return 0;
> }
Hmm, that's strange. Here's what I get using the svn trunk
on 32-bit ppc (Debian 6.0.1):
==24922== Memcheck, a memory error detector
==24922== Copyright (C) 2002-2010, and GNU GPL'd, by J
On Tuesday, March 29, 2011, Mike McQuaid wrote:
> I see a bug has been filed about this here:
> http://bugs.kde.org/show_bug.cgi?id=268792
>
> Now this is publicly released is there any workaround or possible fix?
Just FTR (for the list), these segfaults occur when Valgrind is built
with xcode 4.
[... mucho discussion ...]
I'm now comprehensively confused. Is there any bug/failure in
Memcheck resulting from this, that needs to be looked at?
J
--
Create and publish websites with WebMatrix
Use the most popular F
On Wednesday, March 30, 2011, Adam Seering wrote:
> I'll take a look. If it's easy enough that I can figure it out, I'll make
> the change myself; otherwise I'll file an appropriate bug report.
It's trivial -- look at the code. The only distinction you need
to make is whether or not the returned
address a bit
above that point:
$ readelf -a memcheck/memcheck-x86-linux | grep Entry
Entry point address: 0x38040f40
J
On Tuesday, March 29, 2011, Jason Kraftcheck wrote:
> On 03/29/2011 11:21 AM, Julian Seward wrote:
> >> VALGRIND_LAUNCHER=memcheck-ppc32-linux me
> VALGRIND_LAUNCHER=memcheck-ppc32-linux memcheck-ppc32-linux a.out
>
> Now I see the following error:
Try again with
VALGRIND_LAUNCHER=memcheck-ppc32-linux memcheck-ppc32-linux \
-d -d -v -v a.out
so at least we can see what's going on at startup. There may
be a lot of output.
J
-
On Monday, March 28, 2011, Bart Van Assche wrote:
> On Mon, Mar 28, 2011 at 6:32 PM, Julian Seward wrote:
> > On Monday, March 28, 2011, Piotr Jaroszyński wrote:
> > > I think the proper solution is to add __attribute__((unused)) to
> > > _qzz_res. What do you t
On Monday, March 28, 2011, Bart Van Assche wrote:
> On Mon, Mar 28, 2011 at 6:32 PM, Julian Seward wrote:
> > On Monday, March 28, 2011, Piotr Jaroszyński wrote:
> > > I think the proper solution is to add __attribute__((unused)) to
> > > _qzz_res. What do you t
On Monday, March 28, 2011, Piotr Jaroszyński wrote:
> I think the proper solution is to add __attribute__((unused)) to
> _qzz_res. What do you think?
Yes. I just committed exactly such cleanups (r11673). Could
you try it, to see if that also makes your compiles quiet again?
J
-
> 1. Using a constant index value for an array on the stack resulting in
> an invalid access. I got from the documentation that the first access
> has to be valid; my code does that. I've noticed that detection works OK
> in for loop, but, when unrolled (for example when using -O2 option for
> opt
It starts at the handwritten piece of assembly called _start
towards the bottom of m_main.c. Then it jumps to _start_in_C_linux.
J
On Sunday, March 20, 2011, maria ahmed wrote:
> can anyone tell me what functions are called when valgrind first starts
> execution. They are independent of tool us
> I get this behaviour on various distributions and several people
> confirmed. I now wonder if there is a bug in udev or something is wrong
> in valgrind? Any idea from the valgrind perspective?
Yes: the program is buggy (reads freed memory) and therefore its
behaviour after that point is of cou
> VALGRIND_HG_CLEAN_MEMORY((char*)0, ~0)) clear the lock graph for me
> without nasty side effects?
>
> Actually, I know that the macro doesn't work with those particular
>
> arguments. It yields:
> > ==7592== Valgrind's memory management: out of memory:
> > ==7592==helgrind:shmem__
Strange that the link fails. It builds OK for me on Ubuntu 10.04
on ARM (Cortex-A8).
Do you have some custom CFLAGS? I see some gcc flags in there
that I don't immediately expect:
> -fexpensive-optimizations -fomit-frame-pointer -frename-registers
> -mthumb-interwork -mno-thumb
What happens i
> This is in an app that assembles and executes code, so it could be a
> genuine error.
Apps like that tend to die with very strange errors unless you run
with --smc-check=all. Did you do that?
J
--
Colocation vs. Mana
> valgrind and daemon exit shortly after launch, at some close but random
Have you tried --trace-children=yes ?
> One more. Valgrind also complains about unhandled system call, like that:
> That's a sigwait() system call:
That's difficult to fix because it interacts with the signals simulation.
201 - 300 of 498 matches
Mail list logo
