1db10 002a427
74a6c1b1 007f1da
Going from 0041db10 to a symbol works fine, the shared library
(74a6c1b1) is a bit troublesome though (disabled
randomize_va_space and using eu-addr2line).
Folkert van Heusden
--
___
Valg
> Anyhow, it sounds like you are starting to reinvent heaptrack - it does
> exactly the above and then some.
Indeed it does: I looked at and it is perfectly for my use-case.
Thank you!
___
Valgrind-users mailing list
Hi,
How can I obtain the number of mallocs per type in a time-frame using
massif? I'm NOT interested in the total in use, I would like to know how
often type x is allocated between t+1 and t+2.
regards
___
Valgrind-users mailing list
3== Illegal opcode at address 0x40274E
> > ==77043== at 0x40274E: ??? (in /home/folkert/Projects/bf-compiler/test)
> > ==77043==by 0x4020EE: ??? (in /home/folkert/Projects/bf-compiler/test)
...
> > If you're curious what is going wrong here, the source assembly and th
Hi,
I wrote a compiler for brainfuck to x86.
The result is quite fast but I was curious if I could tune it even more.
So I ran it in callgrind but this resulted in:
folkert@snsv ~/Projects/bf-compiler (master)$ valgrind --tool=callgrind ./test
==77043== Callgrind, a call-graph generating cache
> > The 2 calls it does are:
> >
> > print_char:
> > movb (%esi), %al
> > movb %al, buffer
> > movl $4, %eax
> > movl $1, %ebx
> > movl $buffer, %ecx
> > movl $1, %edx
> > int $0x80
> > ret
> >
> > exit:
> > movl $1, %eax
> > movl $0, %ebx
> >
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 it starts swapping like hell, but far more than the usual out
of
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 it starts swapping like hell, but far more than the usual out
I'm also not entirely sure if it indeed is a leak in my program as I
have a routine in it which constantly (20 times/sec) checks the memory
usage (via /proc) of my program and does an exit() when it reaches
500MB (normally it should not use more than 120MB).
If it is something in Xorg,
So when this happens, my program would allocate gigabytes of ram. And
since I used --malloc-fill=, valgrind would then initialize this ram
(I'm speculating here) causing big time swapping. I found this out by
disabling swap memory.
To verify that this is the problem, you might use
: ???
==21521==by 0x12FEFFFD67: ???
==21521==by 0x1FEFFFD5F: ???
==21521==by 0x103BB88F: ???
==21521==by 0x7FEFFFD8F: ???
==21521==by 0x59EF7D: ??? (in
/home/folkert/Projects/sysopview/trunk/sysopview)
==21521==by 0x109B088F: ???
==21521==by 0xEC398BA: ??? (in /usr/lib/x86_64
Hi Philippe,
hmmm ok.
it seems it can't handle corruptions that nicely:
Not too sure I understand. The below msgs from Valgrind
are indicating (probable/possible) bugs. Apart of reporting
the error, the behaviour is (usually) not influenced too much
(compared to a native execution).
12 matches
Mail list logo
