On Thu, 2012-02-02 at 17:07 +0500, Mohammad Ali wrote:
After configuring valgrind. I took the Inst directory (as mentioned in
Readme.android) and copied it to two emulators, one running on MacOSx
and the other running on Ubuntu 11.10.
I created the emulator using 2.2 API (platform-8).
On
On Thu, 2012-02-09 at 17:47 +0400, Alexander Potapenko wrote:
under Valgrind on your machine?
If it returns 0, it means that the code you're running is incorrectly
assuming AES support on the CPU (this is still a reason to fix
AESKEYGENASSIST)
Otherwise cpuid is broken under Valgrind.
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.
--vgdb-error=5 stops after detecting 6 errors.
Thanks for the feedback.
On Thu, 2012-02-09 at 13:40 +, Tom Hughes wrote:
On 09/02/12 13:00, Eliot Moss wrote:
0x66 0x0F 0x3A 0xDF appears to be AESKEYGENASSIST.
Someone else will have to address that (if at all).
There's a bug for that already:
https://bugs.kde.org/show_bug.cgi?id=290655
I just attached
On Tue, 2012-02-14 at 13:54 +, Rob wrote:
One thing that might be relevant is that errors already have a
32 bit value that identifies them uniquely. struct _Error :: unique
You can see them in the XML output, eg
./vg-in-place --xml=yes --xml-fd=1 memcheck/tests/errs1
I would
On Tue, 2012-02-14 at 23:52 +0100, Julian Seward wrote:
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.
On Fri, 2012-02-17 at 16:01 -0800, Richa Mehta wrote:
Hi,
I am a valgrind user, and while running valgrind on my program, it got
stuck on one of my library files.
Following is the output of the running valgrind:
--2990-- Considering /usr/lib/mylib.so.debug ..
--2990-- .. CRC is
On Thu, 2012-02-23 at 17:59 +0800, 张昭 wrote:
static int b[60];
int main ( int argc, char *argv[] )
{
int a[50];
int ret;
/*a[50] = 1;
a[51] = 1;*/
b[59] = 1;
b[60] = 2;
return EXIT_SUCCESS;
}
and I find this result; why? I always have a array out
On Thu, 2012-02-23 at 21:33 +0800, jee wrote:
like this:
in gdb:
137 while(fgets(buff, PATH_MAX, p_file)){
(gdb) //when i press n, .. there's no n,it's dead -_-!
What happens if you press Control-c ?
Control-c should indicate to the Valgrind gdbserver to give back the
On Fri, 2012-02-24 at 09:46 +0800, jee wrote:
the same,can not pause.
2012/2/24 Philippe Waroquiers philippe.waroqui...@skynet.be
On Thu, 2012-02-23 at 21:33 +0800, jee wrote:
like this:
in gdb:
137 while(fgets(buff, PATH_MAX, p_file
On Fri, 2012-03-30 at 10:52 +0800, 田东云 wrote:
-bash-3.2$ vgdb -d -d -d help
1329272585.803212 searching pid in directory /tmp/ format
/tmp/vgdb-pipe-from-vgdb-to-
1329272585.803691 check_trial 0
...
1329272585.811478 trying
/tmp/vgdb-pipe-from-vgdb-to-3380-by-weblogic-on-tdy218
On Tue, 2012-04-03 at 18:48 +0200, Peter Toft wrote:
I do not have any $LD_PRELOAD set. Should I?
Not AFAIK.
J
What is the Valgrind error-message then telling me?
This looks like bug
https://bugs.kde.org/show_bug.cgi?id=286270
which is solved in 3.8.0 SVN.
If this is the same bug,
On Tue, 2012-04-03 at 22:06 +0200, ольга крыжановская wrote:
How do I use custom memory allocators with valgrind? We'd like to use
the memory allocators from ATT libast but also like to use valgrind
for (automated) error checking. Is there any howto document how to do
this?
Olga
On Tue, 2012-04-03 at 22:40 +0200, ольга крыжановская wrote:
Philippe, libast provides both malloc replacement and a complex
allocation system based on io streams, e.g.sort of stdio with
disciplines on steroids where even string buffers, or lists and trees
of (nested) string buffers, can be a
On Sun, 2012-04-15 at 00:26 +0100, Plug Gulp wrote:
I tried starting apache webserver and gdb from root login. Did not
help, because the valgrind is still launched from under apache user.
So I set the LOGNAME and HOST to ??? as suggested above and started
the webserver and gdb from root
On Sun, 2012-04-15 at 19:17 +0200, Folkert van Heusden wrote:
Hi,
I'm trying to debug this (opengl) application I'm writing.
Now something odd happens: when I run it in gdb, it occasionally
sigsegvs which is not ok but expected, but when ran under valgrind the
whole system crashes.
I think
On Tue, 2012-04-17 at 20:16 +0200, Folkert van Heusden wrote:
From what I read on wikipedia, Valgrind runs things in a virtual
machine and from my experience (wrote an MSX (z80) emulator once,
no twice) you can emulate everything, maybe a tad slow.
Valgrind provides a simulated cpu, but not a
On Tue, 2012-04-17 at 21:02 +0200, Folkert van Heusden wrote:
Valgrind provides a simulated cpu, but not a simulated OS and
simulated mmu etc etc.
In other words, Valgrind runs a unix application process on
top of a virtual cpu, Valgrind does not provide a virtual
machine like kvm or Xen
On Tue, 2012-04-17 at 21:55 +0200, Folkert van Heusden wrote:
The problem I see is that the stacktraces seem to be incorrect.
gdb unwinder might work better = try with the Valgrind gdbserver
(give --vgdb-error=0 arg to Valgrind, and follow instructions
to attach gdb, and then 'continue' your
On Tue, 2012-04-24 at 14:06 -0400, Matt Broadstone wrote:
Not sure how to post to this thread having just signed up for the
list, but hopefully this routes correctly..
Hi,
I wanted to confirm that the aes changes in trunk do indeed solve that
unrecognized instruction issue, however,
I am
On Thu, 2012-04-26 at 09:29 -0400, Matt Broadstone wrote:
As for doing a db-attach, that seems to have failed as well - I never
make it to a gdb session. Here is the full output of a db-attach
valgrind run on TextEdit.app:
==76980== Attach to debugger ? --- [Return/N/n/Y/y/C/c]
On Thu, 2012-04-26 at 14:17 -0400, Matt Broadstone wrote:
and then:
(gdb) target remote | /usr/local/bin/vgdb
| /usr/local/bin/vgdb: Undefined error: 0
You must have a version of gdb recent enough (I believe = 6.5)
otherwise GDB does not understand the | target.
Two alternatives:
*
On Fri, 2012-04-27 at 11:49 +0200, Matthias Schwarzott wrote:
Hi there!
Comparing the output from gdb attached to valgrind gdbserver and the
core file valgrind creates, the thread order is inverted.
As I have more minor issues with gdb and valgrind core files, I do not
known if this is
Maybe there is some other piece missing (see my posting before this topic).
My gdb is not sure about the threads:
(gdb) info threads
Cannot find new threads: generic error
But:
(gdb) thread apply 1-2 bt
Thread 1 (LWP 6):
#0 0x003e93a329b5 in raise () from /lib64/libc.so.6
#1
On Fri, 2012-05-04 at 17:32 +, Oliver Schneider wrote:
Hi folks,
I've got a question about Valgrind and its Memcheck tool. Is it possible
to take a snapshot of a program under Valgrind, kinda similar to the way
a fork() clones the process space, and then continue again from that
On Thu, 2012-05-03 at 23:37 -0400, Zheng Da wrote:
Is this normal? Is it because my program is written in C++? How do I
suppress these errors very effectively? or these errors are actually
caused by some bugs of my program?
C++ is supported by Valgrind.
Valgrind reports some errors in glibc
On Sat, 2012-05-05 at 14:25 +0200, Martin Kalany wrote:
Hello,
I'm trying to use valgrind do debug an mpich2 program. Unfortunately, I get
the following error:
libmpi.so.0: cannot open shared object file: No such file or directory
I found out that libmpich.so.1.0 should be linked to
On Sat, 2012-05-05 at 18:14 +0200, Martin Kalany wrote:
Is the 'cannot open' error only there when running under Valgrind ?
Yes. When I use mpirun, it's fine.
What I think is strange that valgrind apperantly tries to load
libmpi.so, although it should load libmpich.so.1.0
Maybe a
On Sat, 2012-05-05 at 14:45 -0400, Zheng Da wrote:
The corresponding code is shown below. I don't understand
which variable isn't initialized?
If you upgrade to Valgrind 3.7.0, you can use gdb to debug
your program under Valgrind.
With this, you have GDB monitor
On Sun, 2012-05-06 at 00:24 +0200, Martin Kalany wrote:
Valgrind documation states that The MPI functions to be wrapped are assumed
to be in an ELF shared object with soname matching libmpi.so*. This is
knownto be correct at least for Open MPI and Quadrics MPI, and can easily
be changed if
On Mon, 2012-05-07 at 21:15 +0200, Martin Kalany wrote:
Nevertheless, valgrind doesn't print anything similar to
valgrind MPI wrappers 31901: Active for pid 31901
valgrind MPI wrappers 31901: Try MPIWRAP_DEBUG=help for possible options
as stated in the documentation. How do I know whether
On Mon, 2012-05-21 at 10:01 +0800, 王?? wrote:
Hello everyone.
Massif is a heap and stack profiler, I have a question about massif when I
use it. It is that I can’t get the output log(massif.out.pid) until the
program tested is over. If the program tested is just like endless while
On Mon, 2012-06-04 at 14:14 +0200, Christoph Bartoschek wrote:
Am 04.06.2012 14:00, schrieb Tom Hughes:
On 04/06/12 12:27, Christoph Bartoschek wrote:
how should one interpret the following report:
Thread #11: Bug in libpthread: recursive write lock granted on
mutex/wrlock which does
On Mon, 2012-06-18 at 17:05 -0400, Brian Helenbrook wrote:
I don't know why it tries to switch to the i386 architecture.
I also have no idea (and no MacOS system to play with).
Maybe
./configure --enable-only64bit
will help/bypass the problem ?
Philippe
On Mon, 2012-06-18 at 15:34 -0700, Ajay Kalambur wrote:
Hi
Is the support for MIPS checked into trunk already
https://bugs.kde.org/show_bug.cgi?id=270777
As per this bug it seems to suggest the patches are in latest trunk.
Yes, the trunk contains the MIPS patches (see commit
revision
On Wed, 2012-06-20 at 16:09 -0400, Bob Rossi wrote:
Hi,
I'm using valgrind with a C++ program that embeds python.
The stack trace is pretty deep, greater than 50 at almost every
point valgrind finds a memory leak.
Unfortunately, I can't see the stack frame that started this
chain
On Mon, 2012-06-25 at 11:03 +0200, Julian Seward wrote:
Is there any eay how to 'iterate' over all the current threads (let us
say that we know their thread id's - we do) and print their stack
traces? That would help us a lot.
One hack that might be worth a try is this. Your SIGTERM is
You need to activate the Valgrind gdbserver for that, using options
--vgdb=yes (and possible give --vgdb-prefix=
to point at a file system supporting FIFOs).
Note that you should also be able to obtain the stack trace of
all threads using the standard gdbserver part of the android
On Fri, 2012-06-29 at 17:46 +0400, Alexander Potapenko wrote:
This may be not that easy to guess which locks are taken when the
deadlock has already occurred.
However a Valgrind-like tool is really an overkill for deadlock
detection: a small library that interposes pthread_mutex_* (or other
On Sat, 2012-06-30 at 18:00 +0100, Josh Reese wrote:
...
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
make[2]: *** [libmpiwrap-x86-darwin.so] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
If anyone has any experience with this I
On Sat, 2012-07-07 at 03:19 +0300, Zvi Vered wrote:
If I run gcc --version (on my gcc) I get:
.i686-nptl-linux-gnu-gcc (crosstool-NG-1.5.2) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
If I run gcc --version on the default gcc installed on my Centos 5.3 I get:
gcc (GCC) 4.1.2
On Thu, 2012-07-12 at 14:42 -0700, Jacob Goldstein wrote:
Primary build arch: amd64
Secondary build arch: x86
I'm running on a MacBook Pro with an Intel i7 CPU (running OS X
10.7.4), so I'm not sure why the primary build arch is amd64.
amd64 indicates it is the intel
On Sat, 2012-07-14 at 00:44 +, Anup wrote:
Hi,
I am trying to debug memory corruption in a program by attaching it to
valgrind
gdbserver and GDB (valgrind version 3.7.0).
Command: valgrind --tool=memcheck --vgdb=full --vgdb-error=0 prog
With --vgdb-error=0, Valgrind should stop
On Wed, 2012-07-18 at 01:22 +, Anup wrote:
--4562:1:gdbsrv getpkt (C14); [no ack]
--4562:1:gdbsrv set_desired_inferior use_general 0 found 0x402514BE0 tid 1
lwpid 4562
--4562:1:gdbsrv resume_info thread 4562 leave_stopped 0 step 0 sig 17
stepping
0
--4562:1:gdbsrv stop pc
On Thu, 2012-08-02 at 18:21 -0400, Wonjoon Song wrote:
...
valgrind: the 'impossible' happened:
Killed by fatal signal
==24479==at 0x38059A25: vgPlain_do_syscall (m_syscall.c:72)
==24479==by 0x3808E5E1: handle_syscall (scheduler.c:1057)
...
I tried to search for examples using
On Tue, 2012-08-07 at 17:12 -0700, John Reiser wrote:
On 08/07/2012 04:43 PM, Jacob Goldstein wrote:
--22925:0:schedule VG_(sema_down): read returned -4
That unexpected behavior of sema_down should be investigated.
The code explicitely retry in case read on the sema returns
-4 (i.e.
On Sun, 2012-08-12 at 18:10 +0200, Francis Giraldeau wrote:
Of course you are right! Thought, I just tested without updating dst and
the problem is raised anyway. The error is not caused in the printf(),
but in the stpncpy().
String functions might be optimised very specially by the compiler
On Sun, 2012-08-12 at 19:15 +0200, Francis Giraldeau wrote:
I confirm this too. I did a trivial implementation of stpcpy/stpncpy
with strcpy and it do not raise the issue. Maybe they can be a basis for
an additional REDIR?
The best is to file a bug on bugzilla,
with the test program to
On Tue, 2012-08-14 at 10:20 +, Adishesh wrote:
Hi,
I have used below program for testing. Below are the steps I have
followed.
Compile: gcc -g3 test_shm.c -o test_shm
Create shared memory: ./test_shm –c
Get shared memory without valgrind: ./test_shm –g ( this works fine)
Get with
On Thu, 2012-08-16 at 12:51 +0530, Adishesh M wrote:
Hi Philippe,
After applying patch shmat is working fine.
Does this patch will be included in the next valgrind release?
Patch has been committed (revision 12874), so will be in next release.
Philippe
On Tue, 2012-10-02 at 12:48 -0700, John Reiser wrote:
In any case, please run cat /proc/PID/maps (where PID is the numerical
process ID) and show us what the mappings look like for addresses 0xFE00
and above, when the program hits the memcheck error (or shortly before.)
The easiest to
On Thu, 2012-10-04 at 13:19 -0500, Kerrick Staley wrote:
I can't track down the error since the stack trace doesn't indicate
which shared object and function it occurs in.
According to http://valgrind.org/docs/manual/faq.html#faq.unhelpful,
if a shared object is unloaded before the program
On Thu, 2012-10-04 at 11:34 -0700, Dan Kegel wrote:
On Thu, Oct 4, 2012 at 11:31 AM, Don Rosengrant
drosengr...@westbrooktech.com wrote:
I’ve read where Windows programs can be run under Valgrind with some effort
with Wine. What is involved in doing this?
Otherwise, if you are courageous
On Tue, 2012-10-09 at 11:40 -0500, Kerrick Staley wrote:
Otherwise, you might always try using gdb/vgdb to connect to the process
under Valgrind when the error is raised : gdb might maybe help
to see what is going on.
You mean I should use --db-attach=yes (as Greg suggested)?
Since
On Tue, 2012-11-06 at 13:43 +0100, David Faure wrote:
On Monday 05 November 2012 23:19:42 Philippe Waroquiers wrote:
On Mon, 2012-11-05 at 18:59 +0100, David Faure wrote:
The testcase http://www.davidfaure.fr/2012/qmutex_trylock.cpp
(from https://bugs.kde.org/show_bug.cgi?id=243232
On Wed, 2012-11-07 at 16:54 +0100, Matthias Schwarzott wrote:
Printing thread names is not a bad idea (not too sure that a lot
of applications are using pthread_setname or prctl but never mind).
In any case, I see several subtilities to look at.
Using plain gdb, info threads also lists these
On Wed, 2012-11-07 at 10:51 +0100, David Faure wrote:
The idea of helgrind is that it detects lock order problems and/or
race condition problems *even* if no deadlock happens and/or if no
race condition really happened.
Maybe it is very unlikely that the trylock fails. Still would be nice
On Thu, 2012-11-08 at 00:18 +0100, David Faure wrote:
On Wednesday 07 November 2012 23:00:51 Philippe Waroquiers wrote:
discover the bug is related to the doubful construct, not
to a race condition
If there's no race condition and no deadlock, I'm not sure what bug you want
to detect
On Fri, 2012-11-09 at 07:52 -0700, Tom Tromey wrote:
Matthias Using plain gdb, info threads also lists these user-defined names.
Matthias But valgrind and gdb+vgdb only show the thread-ids.
Currently I don't think there is a way for vgdb to report this back to
gdb.
The thread name could
On Thu, 2012-11-15 at 07:49 -0800, John Reiser wrote:
==15447== error 22 Invalid argument
==15447== error VG_(am_shared_mmap_file_float_valgrind)
/tmp/vgdb-pipe-shared-mem-vgdb-15447-by-root-on-???
Run with valgrind --trace-syscalls=yes ./maintest (or use strace)
to find the system
On Fri, 2012-11-16 at 09:09 +0800, lchquan wrote:
By using --vgdb=no, it works .
Good that it bypasses the problem.
Still, there is a latent bug in the mmap area which would be
nice to understand.
I am amazed that the --trace-syscalls=yes did not give any output.
(at least on my setup, it gives
On Mon, 2012-11-26 at 12:46 -0800, Wiser, Tyson wrote:
Does anyone have any idea what I am doing wrong? I am new to valgrind
so I'm sure it is something simple that I have missed.
Not too sure it is very simple. Normally, massif should work with default args.
Maybe there is a problem with
On Tue, 2012-11-27 at 23:35 +0100, Philippe Waroquiers wrote:
On Mon, 2012-11-26 at 12:46 -0800, Wiser, Tyson wrote:
Does anyone have any idea what I am doing wrong? I am new to valgrind
so I'm sure it is something simple that I have missed.
I just saw your follow-up telling you have
On Wed, 2012-11-28 at 11:06 -0800, Wiser, Tyson wrote:
I tried it with 3.8.1 that I built locally and got the same result
(i.e. no profile). The command I used was:
valgrind --tool=massif --soname-synonyms=somalloc=NONE ./MyProg
The above is supposed to properly replace a static malloc.
I
Currently, Valgrind does not provide a fully flexible
way to indicate which leak kinds to show,
which leak kinds to consider as an error,
and which leak kinds to suppress.
This is a.o. described in bugs 284540 and 307465.
For example, the current options
(--show-reachable=yes|no
On Thu, 2012-11-29 at 08:44 +0100, David Faure wrote:
Here are the new command lines args:
--show-leak-kinds=kind1,kind2,.. which leak kinds to show?
[definite,possible]
--errors-for-leak-kinds=kind1,kind2,.. which leak kinds are
On Thu, 2012-11-29 at 06:25 -0800, John Reiser wrote:
This is good as far as it goes. The presentation in the output from
valgrind --help will matter, and so will the explanation given
in the user manual. Just finding and understanding the new options
is a significant barrier to usability.
On Thu, 2012-11-29 at 07:30 -0800, Wiser, Tyson wrote:
Can you try with -v and/or with --trace-redir=yes ?
That might give some lights about the problem ?
I used both options and it produced the following output. Thanks for taking
the time to look at this.
There is an unexpected (or rather
On Thu, 2012-11-29 at 17:31 +0100, Pedro Larroy wrote:
Without valgrind everything works fine, it tries to map a file of 20GB
or so, might this be the reason?
Yes, it might be the reason.
Try to reduce the size to e.g. 1GB and see if it works.
-v -v -v -d -d -d args will also activate tracing
On Fri, 2012-11-30 at 06:56 -0800, Wiser, Tyson wrote:
I'm not sure how to interpret these results. Does all this look OK?
Yes, it looks similar to what I see here.
To see that the whole replacement thing is working,
the command
valgrind --tool=memcheck --soname-synonyms=somalloc=NONE
On Wed, 2012-12-05 at 11:57 -0800, John Reiser wrote:
On 12/05/2012 09:18 AM, Simon Bonello wrote:
I am trying to track a memory leak in a vmware service and I tried to use
valgrind to track the leak. Unfortunately it is stopping for the following
instruction.
vex x86-IR:unhandled
On Mon, 2012-12-17 at 21:03 +0900, ISHIKAWA,chiaki wrote:
During running mozilla thunderbird mail client under helgrind,
I got the following message:
==13832== Thread #1: pthread_cond_destroy: destruction of condition
variable being waited upon
(See mozilla bugzilla entry
On Tue, 2012-12-18 at 21:00 +0900, ISHIKAWA,chiaki wrote:
(2012/12/18 8:07), Philippe Waroquiers wrote:
Destruction of unknown cond var is probably/maybe bug
https://bugs.kde.org/show_bug.cgi?id=307082
I have produced a patch to take care of the issue.
But before that, I have a question
helgrind can't really know which task is being removed from the waiting list
and
so decrmenting nWaiters is all it does (I think).
I think it does a lot more (otherwise helgrind could not follow at all what
would
happen with cond variables).
See e.g. pthread_cond_wait_WRK
Also, does
On Sun, 2012-12-30 at 22:45 +0100, Emilio Coppa wrote:
Thank both of you for your answers.
Each CPU core may switch logical threads only at a superblock
boundary,
but mutual exclusion between threads on different CPU cores is
not guaranteed.
For
On Tue, 2013-01-15 at 15:15 +0100, Josef Weidendorfer wrote:
Am 15.01.2013 07:36, schrieb Steph:
root@bt:~# ==1975==
==1975== Error: can not open cache simulation output file
`/root/callgrind.out.1975'
Are you allowed to create a file in /root ?
Anyway, you should not run valgrind as
On Thu, 2013-01-17 at 19:00 +, Phil Longstaff wrote:
What is the cause of “stack unavailable”? This error message doesn’t
give me enough information to go on, since it doesn’t tell me anything
about what the first incorrectly locked mutex is or about the stacks
establishing the correct
On Sun, 2013-01-20 at 01:07 -0700, vijay singh wrote:
I have a suspected native memory leak in a Java Web Application
deployed on WebSphere App Server. We are trying to use valgrind to
debug the same.
Can anyone help me with the commands to be used to start the server
process under
On Mon, 2013-02-04 at 16:26 +, Rehrmann, Robin wrote:
printing the result. Since memory leaks can only be detected at the
end of a program, these are printed out at the end of the program, so
If you want to find which test specifically leaks some memory
(i.e. loses the last pointer to a
On Thu, 2013-02-14 at 07:21 +0100, Matthias Schwarzott wrote:
I will create a bug ticket to track this.
No time for the moment to look at your patch, but it is a good
idea to enter a bug in bugzilla with the patch and the before/after
diffs for the test.
Philippe
On Wed, 2013-02-20 at 07:09 -0800, Greg Czajkowski wrote:
If this assertion is not tied to any possible damage it may cause, can
it be removed or perhaps turned into a warning?
A warning is similar to other similar things in Valgrind.
E.g. a warning is produced when the permission of a large
On Fri, 2013-02-22 at 20:02 -0500, Konstantine Bogach wrote:
Hi, I am on 3.8.1 now and I can not get massif to produce an output
file, neither default name nor specifying it on command line. I
terminate my program by sending TERM signal to valgrind process. That
worked on 3.4.1 (yes,
On Wed, 2013-02-27 at 16:29 +0100, Nils Köhler wrote:
si_code=80; Faulting address: 0x0; sp: 0x62a9d8f8
valgrind INTERNAL ERROR received a signal 11 (SIGSEV)- exiting
I have hundrets of that messages with different SP:adresses
Is it and issue in my programm or in valgrind?
Does anyone
On Wed, 2013-02-27 at 09:58 -0800, John Reiser wrote:
I am on 3.8.1 now and I can not get massif to produce an output
file, neither default name nor specifying it on command line. I
terminate my program by sending TERM signal to valgrind process. That
worked on 3.4.1 (yes, I don't
On Thu, 2013-02-28 at 14:53 -0800, Kyle Mahan wrote:
Hi all, I'm wondering if it's possible for memcheck to show the last
place that some memory was accessible before being leaked. For
example, I would like to see the line numbers for both allocated
here and leaked here in the example below.
On Mon, 2013-03-04 at 22:08 +0100, Roland Mainz wrote:
On Mon, Mar 4, 2013 at 9:29 PM, Philippe Waroquiers
philippe.waroqui...@skynet.be wrote:
GNAT runtime is implementing various features (e.g. float images)
by using long_long_float, which are 80 bits floats.
As these are not properly
On Tue, 2013-03-05 at 18:54 +0100, Lionel Cons wrote:
(1) in https://bugs.kde.org/show_bug.cgi?id=197915#c9 is a joke:
Julian Seward 2010-07-12 15:58:25 UTC
As per comment #0, adding support for 80-bit floats is low priority,
because (1) AIUI the majority of floating point code is portable
On Thu, 2013-03-14 at 18:48 +0100, David Faure wrote:
The attached testcase (which is simply pthread_cond_init +
pthread_cond_destroy), leads to an error in helgrind:
pthread_cond_destroy: destruction of unknown cond var
Looks like this is:
https://bugs.kde.org/show_bug.cgi?id=307082
which
On Thu, 2013-03-14 at 19:21 +, Phil Longstaff wrote:
Memcheck will report that memory is potentially lost if there is no
pointer to the beginning of a block, but there is an internal pointer.
One valid use of an internal pointer is a pointer to a base class in C
++. How hard would it be
On Thu, 2013-03-14 at 13:47 -0700, John Reiser wrote:
In the NEWS section, Release 3.8.0 (10 August 2012), TOOL CHANGES,
* Non-libc malloc implementations are now supported. This is useful
for tools that replace malloc (Memcheck, Massif, DRD, Helgrind).
Using the new option
On Thu, 2013-03-14 at 14:18 -0700, Patrick J. LoPresti wrote:
On Thu, Mar 14, 2013 at 1:58 PM, Philippe Waroquiers
philippe.waroqui...@skynet.be wrote:
On Thu, 2013-03-14 at 19:21 +, Phil Longstaff wrote:
How hard would it be for memcheck to not report a block as being
potentially lost
On Tue, 2013-03-26 at 14:30 +0100, Jonatan Wallmander wrote:
Feature-request:
Add backtrace to output for these warnings:
Warning: set address range perms: large range
[0x4c339040, 0x206094130) (undefined)
Probably not difficult to implement, however, see below ...
On Tue, 2013-03-26 at 22:52 +0100, Philippe Waroquiers wrote:
The best would be to file a bug in bugzilla, for the false negative
caused by code such as:
{
size_t undef;
char *p = malloc (undef);
}
Too late to file a bug in bugzilla :).
An improvement has been
On Fri, 2013-04-12 at 11:03 +0200, MOULINIER Luc (UDS) wrote:
As my program is multi-threaded, a normal run of valgrind doesn't work.
Valgrind is able to run a multi-thread program (even if it serialises
the execution, i.e. even on a multi-cpu, only one thread runs at
a single time).
However, if
On Wed, 2013-04-17 at 13:07 +0800, Ice Frog wrote:
I'm using Valgrind for profiling, but it reported failures(lots of
failures with same error message) as below:
Thread 295: status = VgTs_WaitSys
There is very little info with which help can be provided.
Are you using callgrind or
On Thu, 2013-04-18 at 08:50 -0700, Brian Budge wrote:
Hi Paul. I am at 20% of memory use. I should also note that I
followed Julian's advice for increasing vg_n_segments and memory size
to 128 GB.
Does valgrind itself do anything multithreaded? My program uses all
cores on the machine at
On Tue, 2013-04-23 at 13:08 -0700, Brian Budge wrote:
Some prototyping was done of a non serialised valgrind.
See https://bugs.kde.org/show_bug.cgi?id=301830
and the MTV branch in svn.
This prototype is not usable in its current state: only the
none
On Sun, 2013-05-05 at 18:20 +0400, Anton Kozlov wrote:
So, the question is, what mechanism can be used to make bare version
act like libc one? I've tried to do STACK_REGISTER, but it brought
no success.
Increase the size of the stack. If you put 0x1 instead of 0x1000,
then both
On Tue, 2013-05-14 at 04:28 +0200, Roland Mainz wrote:
On Thu, Apr 25, 2013 at 1:42 PM, Sebastian Feld
sebastian.n.f...@gmail.com wrote:
On Wed, Apr 24, 2013 at 11:10 PM, Roland Mainz roland.ma...@nrubsig.org
wrote:
On Wed, Apr 24, 2013 at 10:14 PM, Roland Mainz roland.ma...@nrubsig.org
On Mon, 2013-06-10 at 01:23 -0700, mnaret wrote:
Hello,
Recently I'm getting lot's of invalid read/invalid write valgrind errors
which point out at memory allocated for the stack. However the code doesn't
crush and finish running successfully.
I'm trying to understand where the error comes
1 - 100 of 365 matches
Mail list logo