Thanks for all the insightful comments, I actually found an existing bug
report regarding precisely the movdqa problem --
http://bugs.kde.org/show_bug.cgi?id=153699 -- which I'll vote up :-)
// Christoffer
_
CHRISTOFFER HAGLUND
Software Developer, Dec
> Once you start vectorising and using SSE instructions that will change
> however as many SSE instructions do care about alignment and will fault
> if the data is not correctly aligned.
>
> Most probably the reason it works in valgrind is that in the process of
> annotating the code the actual i
On 10/08/10 10:08, Christoffer Haglund wrote:
> Ok, I think I understand. This means the test application I sent in my
> previous mail shows the lack of alignment-awareness rather than an
> actual bug, right?
Well it's a bug in your application rather than a bug in valgrind.
I'm not quite sure h
Ok, I think I understand. This means the test application I sent in my
previous mail shows the lack of alignment-awareness rather than an
actual bug, right?
// Christoffer
tis 2010-08-10 klockan 09:33 +0100 skrev Tom Hughes:
> On 10/08/10 09:00, Christoffer Haglund wrote:
>
> > Oh, sorry, th
Ah, I got around to looking at the disassembly as well.
The instruction that fails is
movdqa %xmm0,(%r9,%rdi,1)
The contents of the input CPU registers rdi and r9 are
r9 = 7026104
rdi = 0
Now, I'm not that good at reading x86 assembler, but I'm pretty good at
Googling. If I've under
On 10/08/10 09:00, Christoffer Haglund wrote:
> Oh, sorry, that last reply wasn't very clear, let my try again. The
> problem occurs inside some proprietary code, so unfortunately I can't
> just copy the exact code that fails, but I'll try to describe it.
>
> There's a struct with the following de
Oh, sorry, that last reply wasn't very clear, let my try again. The
problem occurs inside some proprietary code, so unfortunately I can't
just copy the exact code that fails, but I'll try to describe it.
There's a struct with the following definition
typedef struct _session {
...
char gen
Dynamic memory, it points to an array inside a struct allocated with
normal calloc()
tis 2010-08-10 klockan 09:14 +0200 skrev Bart Van Assche:
> On Mon, Aug 9, 2010 at 4:01 PM, Christoffer Haglund
> wrote:
>
> That's interesting. This what Memcheck tells me about the
> applicatio
On Mon, Aug 9, 2010 at 4:01 PM, Christoffer Haglund <
christoffer.hagl...@nuance.com> wrote:
> That's interesting. This what Memcheck tells me about the application that
> crashes:
>
> $ valgrind --leak-check=full --show-reachable=yes --track-origins=yes
> ./unittest_t9write -r api -o api.xml
>
That's interesting. This what Memcheck tells me about the application
that crashes:
$ valgrind --leak-check=full --show-reachable=yes
--track-origins=yes ./unittest_t9write -r api -o api.xml
==19513== Memcheck, a memory error detector
==19513== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Sew
This is a known phenomenon. Valgrind (well, Memcheck, really) is more
robust against applications that overwrite the ends/beginnings of heap blocks
than the normal C malloc/free routines are. So if your application
is doing such overwrites, that could explain the difference. What
really would b
Hi,
here's a little problem that has bothered me for a few days. I'm working
on isolating it further but thought there might be someone here who
might just know if this is expected behaviour of Valgrind, or if this is
something that should be reported as a bug.
As the title says, I've managed to
12 matches
Mail list logo
