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
(5) |
3
(7) |
4
(8) |
5
(3) |
|
6
(2) |
7
|
8
(2) |
9
(20) |
10
(2) |
11
(14) |
12
(21) |
|
13
(6) |
14
(9) |
15
(31) |
16
(7) |
17
(5) |
18
(14) |
19
(3) |
|
20
(6) |
21
(9) |
22
(19) |
23
(14) |
24
(16) |
25
(10) |
26
(3) |
|
27
(2) |
28
(1) |
29
(10) |
30
(6) |
31
(16) |
|
|
|
From: Sirpa S. <Gu...@jm...> - 2005-03-23 11:30:30
|
Hello, should be honourably entreated, Captain Blood led the Bishop just issuing from the shed. He doffed his hat and stood with one hand, whilst with the other he pointed after the retreat forward all but unseating her rider. England, Scotland, France, and Ireland, with the dominions and was held to his quivering lips. He drank greedily, noisily, nor bow-legged animal with the arms of a Hercules and the jowl of a What shall that mean? quoth Lord Julian sharply. Have a nice day. |
|
From: Lei Z. <lei...@pk...> - 2005-03-23 08:22:22
|
Hello valgrind-users, it seems to have something dependent with x86 instructions? please help me, thank :) Yours Sincerely, Zhang, Lei lei...@pk... 2005-03-23 |
|
From: Paul P. <ppl...@gm...> - 2005-03-23 01:31:09
|
On Tue, 22 Mar 2005 15:56:04 -0800, Jeremy Fitzhardinge <je...@go...> wrote: > Scott Mills wrote: > > > Before we get a chance to upgrade (we're still running < 2.2.0), is > > there anyway I can 'unset' -rpath without rebuilding the target program? > > I don't think so; it's embedded in the .so files you generate. There sure is: load the exe/DSO into emacs, invoke hexl-mode, edit rpath away (replacing the first character of the string with NUL character should do the trick). Cheers, |
|
From: Jeremy F. <je...@go...> - 2005-03-22 23:56:14
|
Scott Mills wrote:
> Would -rpath be a parameter for the make/build of the target program then?
>
Yes, the -Wl,-rpath option you mentioned.
> Before we get a chance to upgrade (we're still running < 2.2.0), is
> there anyway I can 'unset' -rpath without rebuilding the target program?
>
I don't think so; it's embedded in the .so files you generate.
J
|
|
From: Scott M. <sm...@no...> - 2005-03-22 18:18:02
|
Thx Jeremy,
Would -rpath be a parameter for the make/build of the target program then?
Before we get a chance to upgrade (we're still running < 2.2.0), is there
anyway I can 'unset' -rpath without rebuilding the target program?
Cheers,
Scott.
-----Original Message-----
From: Jeremy Fitzhardinge [mailto:je...@go...]
Sent: Tuesday, March 22, 2005 1:11 PM
To: Mills, Scott [CAR:2V62:EXCH]
Cc: val...@li...
Subject: Re: [Valgrind-users] RE: Question about valgrind's libpthread
Scott Mills wrote:
> Can anyone confirm/deny my suspicions and provide insight on what the
> - -Wl,-rpath,/lib -L/lib flags are and how they are used?
>
-rpath sets the runtime linkers search path, and it takes precident over
all other path settings, including LD_LIBRARY_PATH (which is what
Valgrind 2.2.0 relies on to substitute its own libpthread).
This is all moot now, since Valgrind 2.4.0 doesn't have its own
libpthread anymore, in faviour of using the system libpthread.
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-22 18:10:58
|
Scott Mills wrote:
> Can anyone confirm/deny my suspicions and provide insight on what the
> - -Wl,-rpath,/lib -L/lib flags are and how they are used?
>
-rpath sets the runtime linkers search path, and it takes precident over
all other path settings, including LD_LIBRARY_PATH (which is what
Valgrind 2.2.0 relies on to substitute its own libpthread).
This is all moot now, since Valgrind 2.4.0 doesn't have its own
libpthread anymore, in faviour of using the system libpthread.
J
|
|
From: Scott M. <sm...@no...> - 2005-03-22 17:48:40
|
Resending, as first attempt didn't seem to go through... Scott. -----Original Message----- From: Mills, Scott [CAR:2V62:EXCH] Sent: Tuesday, March 22, 2005 10:31 AM To: val...@li... Subject: Question about valgrind's libpthread Hi, Still new to valgrind, so I some high level questions. I've noticed that when we run Valgrind on process Foo in environment A, it will pickup Valgrind's libpthread library properly. In a different environment B, when running Valgrind on process Foo, it ignored Valgrind's libpthread and only uses /lib/libpthread.so instead. The same version of Valgrind is run in both environments. I don't have a lot of knowledge about Foo, but my guess is that this problem is occurring because of how Foo was built/compiled in the two environments. I found some information online: http://sourceforge.net/mailarchive/forum.php?forum_id=32038&max_rows=25&styl e=nested&viewmonth=200312 which seems to suggest that the flags - -Wl,-rpath,/lib -L/lib were used when being built which somehow prevented Valgrind from using it's own libpthread. Can anyone confirm/deny my suspicions and provide insight on what the - -Wl,-rpath,/lib -L/lib flags are and how they are used? Thx for any help, Scott. |
|
From: Jeremy F. <je...@go...> - 2005-03-22 17:46:07
|
Benny Cheung wrote:
>Is there a more stable 2.4.0 release, or any version that fixed the 2.2.0
>bug you mentioned at this moment? Thanks!
>
2.4.0.rc4 is very close to what we're intending to release as 2.4.0.
Could you go into a bit more detail about this crash (like the full
output of valgrind -v)?
Thanks,
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-22 17:44:39
|
Nicholas Nethercote wrote:
> It's likely a bug in the pthreads library.
It's just uninitialized padding in a structure being written to a pipe;
it isn't really a bug.
>> Maybe someone out there know how to fix this warnings...or are those
>> supression candidates?
>
>
> I believe so, for both of them.
There are some suppressions for these already, but there seem to be lots
of variations.
J
|
|
From: Scott M. <sm...@no...> - 2005-03-22 15:32:16
|
Hi, Still new to valgrind, so I some high level questions. I've noticed that when we run Valgrind on process Foo in environment A, it will pickup Valgrind's libpthread library properly. In a different environment B, when running Valgrind on process Foo, it ignored Valgrind's libpthread and only uses /lib/libpthread.so instead. The same version of Valgrind is run in both environments. I don't have a lot of knowledge about Foo, but my guess is that this problem is occurring because of how Foo was built/compiled in the two environments. I found some information online: http://sourceforge.net/mailarchive/forum.php?forum_id=32038&max_rows=25&styl e=nested&viewmonth=200312 which seems to suggest that the flags - -Wl,-rpath,/lib -L/lib were used when being built which somehow prevented Valgrind from using it's own libpthread. Can anyone confirm/deny my suspicions and provide insight on what the - -Wl,-rpath,/lib -L/lib flags are and how they are used? Thx for any help, Scott. |
|
From: <oli...@on...> - 2005-03-22 15:00:31
|
> > Maybe someone out there know how to fix this warnings...or are those > > supression candidates? > > I believe so, for both of them. Maybe even out-of-the-box suppressions? Some users might get confused and think either their programs are buggy or valgrind is, because these warnings weren't there with 2.2.0. |
|
From: Nicholas N. <nj...@cs...> - 2005-03-22 14:35:14
|
On Tue, 22 Mar 2005 oli...@on... wrote: > Since the pthread emulation is gone I get a lot of those warnings: > > ==32250== Syscall param write(buf) points to uninitialised byte(s) > ==32250== at 0x1B9178CB: write (in /lib/i686/libpthread-0.10.so) > ==32250== by 0x80AF033: CCalThread::CCalThread(void* (*)(void*), > void*) (/cal/dev/source/libs/libcalbase/thread/ccalthread.h:23) That looks familiar, I've seen similar ones in pthreaded programs. > ==32250== 8160 bytes in 1 blocks are definitely lost in loss record 13 > of 14 > ==32250== at 0x1B901538: malloc (vg_replace_malloc.c:130) > ==32250== by 0x1B9134DE: __pthread_initialize_manager (in > /lib/i686/libpthread-0.10.so) > ==32250== by 0x1B913A4B: pthread_create@@GLIBC_2.1 (in > /lib/i686/libpthread-0.10.so) > ==32250== by 0x80AF033: CCalThread::CCalThread(void* (*)(void*), > void*) (/cal/dev/source/libs/libcalbase/thread/ccalthread.h:23) > > I just don't unterstand it, because all thread are being exited > successfully and pthread_exit is always called. I thought it might have > something to do with the join state, but they aren't even joinable. > It's the same code as shown above and adding a pthread_detach there > didn't help either. It's likely a bug in the pthreads library. > Maybe someone out there know how to fix this warnings...or are those > supression candidates? I believe so, for both of them. N |
|
From: <oli...@on...> - 2005-03-22 11:50:11
|
I forgot to mention, that I am using 2.4.0 CVS and GCC 3.2 on a 32-bit machine. |
|
From: <oli...@on...> - 2005-03-22 11:48:05
|
Since the pthread emulation is gone I get a lot of those warnings:
==32250== Syscall param write(buf) points to uninitialised byte(s)
==32250== at 0x1B9178CB: write (in /lib/i686/libpthread-0.10.so)
==32250== by 0x80AF033: CCalThread::CCalThread(void* (*)(void*),
void*) (/cal/dev/source/libs/libcalbase/thread/ccalthread.h:23)
==32250== by 0x80AE3A7: CThreadPool::Init(int,
_STL::basic_ostream<char, _STL::char_traits<char> >*, bool,
_STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char>
>) (../../source/libs/libcalbase/thread/threadpool.cpp:147)
==32250== by 0x805B0C4: CTestPlugin::Initialize()
(../../../source/apps/cal/test/testplugin/base/ctestplugin.cpp:405)
==32250== by 0x8067CB0: CTestPlugin::TestPlugin()
(../../../source/apps/cal/test/testplugin/base/ctestplugin.cpp:1551)
==32250== by 0x80670C9: CTestPlugin::RunTest()
(../../../source/apps/cal/test/testplugin/base/ctestplugin.cpp:1503)
==32250== by 0x807D18C: main
(../../../source/apps/cal/test/testplugin/testplugin.cpp:106)
==32250== Address 0x52BFDA3C is on thread 1's stack
It happens almost(?) always when calling pthread_create or pthread_join.
The code for the example above looks like this:
#include <pthread.h>
class CCalThread
{
public:
CCalThread(void* func(void*), void* arg)
: _res(-1)
{
int res = pthread_create(&_id, NULL, func, arg);
if( res == 0 ) {
_res = 0;
//pthread_detach(_id);
}
}
~CCalThread() {}
int _res;
private:
pthread_t _id;
};
And I am also always getting this memory leak:
==32250== 8160 bytes in 1 blocks are definitely lost in loss record 13
of 14
==32250== at 0x1B901538: malloc (vg_replace_malloc.c:130)
==32250== by 0x1B9134DE: __pthread_initialize_manager (in
/lib/i686/libpthread-0.10.so)
==32250== by 0x1B913A4B: pthread_create@@GLIBC_2.1 (in
/lib/i686/libpthread-0.10.so)
==32250== by 0x80AF033: CCalThread::CCalThread(void* (*)(void*),
void*) (/cal/dev/source/libs/libcalbase/thread/ccalthread.h:23)
==32250== by 0x80AE3A7: CThreadPool::Init(int,
_STL::basic_ostream<char, _STL::char_traits<char> >*, bool,
_STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char>
>) (../../source/libs/libcalbase/thread/threadpool.cpp:147)
==32250== by 0x805B0C4: CTestPlugin::Initialize()
(../../../source/apps/cal/test/testplugin/base/ctestplugin.cpp:405)
==32250== by 0x8067CB0: CTestPlugin::TestPlugin()
(../../../source/apps/cal/test/testplugin/base/ctestplugin.cpp:1551)
==32250== by 0x80670C9: CTestPlugin::RunTest()
(../../../source/apps/cal/test/testplugin/base/ctestplugin.cpp:1503)
==32250== by 0x807D18C: main
(../../../source/apps/cal/test/testplugin/testplugin.cpp:106)
I just don't unterstand it, because all thread are being exited
successfully and pthread_exit is always called. I thought it might have
something to do with the join state, but they aren't even joinable.
It's the same code as shown above and adding a pthread_detach there
didn't help either.
Maybe someone out there know how to fix this warnings...or are those
supression candidates?
|
|
From: Benny C. <bwl...@gm...> - 2005-03-22 08:51:04
|
Hi, Tom Hughes <tom <at> compton.nu> writes: > > valgrind: vg_memory.c:229 (vgPlain_unmap_range): Assertion `rs == s' failed. > > ==5504== at 0xB002A954: vgPlain_skin_assert_fail (vg_mylibc.c:1137) > > ==5504== by 0xB002A953: assert_fail (vg_mylibc.c:1133) > > ==5504== by 0xB002A991: vgPlain_core_assert_fail (vg_mylibc.c:1144) > > ==5504== by 0xB0028238: vgPlain_unmap_range (vg_memory.c:245) > > If you're using 2.2.0 then that looks like a known bug that is fixed > in the CVS code the 2.4.0 release candidates so you might want to try > that. Thanks, I have tried installed 2.4.0-rc4, but not long after the execution starts I got a "Segmentation Fault" without any further Valgrind messages. I invoked the program like this: vg/bin/valgrind -v --tool=memcheck --error-limit=no ./ad64k Is there a more stable 2.4.0 release, or any version that fixed the 2.2.0 bug you mentioned at this moment? Thanks! Best Regards, Benny. |
|
From: Jeremy F. <je...@go...> - 2005-03-22 07:58:02
|
Klint Gore wrote:
>ok. that worked.
>
>I got a long list of things from a non-trivial program. Now to spend
>some time working out what it's telling me.
>
Well, just from hello-world it looks like Kylix generates bad code - it
accesses memory below the stack pointer (hence the warning about
--workaround-gcc-296-bugs=yes).
J
|
|
From: Klint G. <kg...@kg...> - 2005-03-22 07:31:24
|
On Mon, 21 Mar 2005 16:58:08 -0800, Jeremy Fitzhardinge <je...@go...> wrote: > Run without -v, or try this patch: ok. that worked. I got a long list of things from a non-trivial program. Now to spend some time working out what it's telling me. thanks. klint. +---------------------------------------+-----------------+ : Klint Gore : "Non rhyming : : EMail : kg...@kg... : slang - the : : Snail : A.B.R.I. : possibilities : : Mail University of New England : are useless" : : Armidale NSW 2351 Australia : L.J.J. : : Fax : +61 2 6772 5376 : : +---------------------------------------+-----------------+ |
|
From: Tom H. <to...@co...> - 2005-03-22 07:13:12
|
In message <loo...@po...>
Benny Cheung <bwl...@gm...> wrote:
> <Program Execution Continues for some time...>
>
> valgrind: vg_memory.c:229 (vgPlain_unmap_range): Assertion `rs == s' failed.
> ==5504== at 0xB002A954: vgPlain_skin_assert_fail (vg_mylibc.c:1137)
> ==5504== by 0xB002A953: assert_fail (vg_mylibc.c:1133)
> ==5504== by 0xB002A991: vgPlain_core_assert_fail (vg_mylibc.c:1144)
> ==5504== by 0xB0028238: vgPlain_unmap_range (vg_memory.c:245)
If you're using 2.2.0 then that looks like a known bug that is fixed
in the CVS code the 2.4.0 release candidates so you might want to try
that.
> I am particularly concerned about the error message "Address 0x1C83E028 is
> 294912 bytes inside a block of size 268435456 alloc'd". Seems the malloc()
> gives me a chunk of memory already allocated in another malloc()'ed chunk.
That's just telling you where the first undefined byte is relative to
the start of the malloced block.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Benny C. <bwl...@gm...> - 2005-03-22 03:59:31
|
Julian Seward <jseward <at> acm.org> writes: > > Basically it is a mistake to use MAP_FIXED at all, unless you have > complete control of the address space. Which, in almost all programs > you don't. A few years ago I worked on a project which did this, and > our program started to fail on obscure Linux distros. We realised > our mistake and reworked it to get rid of MAP_FIXED. > > J Thanks Julian. I have changed the mmap() back to malloc(), and the program can run under Valgrind, but with such errors: ==5504== Syscall param write(buf) contains uninitialised or unaddressable byte (s) ==5504== at 0x1BACA743: __write_nocancel (in /mnt/nfsroot/lib/tls/libc- 2.3.2.so) ==5504== by 0x1BA65D4D: new_do_write (in /mnt/nfsroot/lib/tls/libc-2.3.2.so) ==5504== by 0x1BA66F3F: _IO_file_xsputn@@GLIBC_2.1 (in /mnt/nfsroot/lib/tls/libc-2.3.2.so) ==5504== by 0x1BA5C2CE: _IO_fwrite_internal (in /mnt/nfsroot/lib/tls/libc- 2.3.2.so) ==5504== Address 0x1C83E028 is 294912 bytes inside a block of size 268435456 alloc'd ==5504== at 0x1B903D48: malloc (vg_replace_malloc.c:131) ==5504== by 0x8054F38: dm_init() (dsmmem.cpp:181) ==5504== by 0x804931D: main (dsminit-add.cpp:123) <Program Execution Continues for some time...> valgrind: vg_memory.c:229 (vgPlain_unmap_range): Assertion `rs == s' failed. ==5504== at 0xB002A954: vgPlain_skin_assert_fail (vg_mylibc.c:1137) ==5504== by 0xB002A953: assert_fail (vg_mylibc.c:1133) ==5504== by 0xB002A991: vgPlain_core_assert_fail (vg_mylibc.c:1144) ==5504== by 0xB0028238: vgPlain_unmap_range (vg_memory.c:245) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==5504== at 0x52BFF042: ??? ==5504== by 0x1BA65569: _IO_file_close_it@@GLIBC_2.1 (in /mnt/nfsroot/lib/tls/libc-2.3.2.so) ==5504== by 0x1BA5AF38: _IO_fclose@@GLIBC_2.1 (in /mnt/nfsroot/lib/tls/libc- 2.3.2.so) ==5504== by 0x804C21F: swapoutobj(int, int, int, int, int) (dsm.h:836) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. I am particularly concerned about the error message "Address 0x1C83E028 is 294912 bytes inside a block of size 268435456 alloc'd". Seems the malloc() gives me a chunk of memory already allocated in another malloc()'ed chunk. Does it suggest that Valgrind has some problems under the Linux version I am using? I am using Fedora core 1. Thanks and Best Regards, Benny. |
|
From: Jeremy F. <je...@go...> - 2005-03-22 00:58:15
|
Klint Gore wrote:
>On Mon, 21 Mar 2005 15:21:37 -0800, Jeremy Fitzhardinge <je...@go...> wrote:
>
>
>>Turns out it was a simple fix. Try this out:
>>
>>
>
>ok, that got me past the segmentation fault. I have an internal error
>(signal 8) and a message that the impossible happened. attached is the
>output.
>
Run without -v, or try this patch:
Index: valgrind/coregrind/vg_from_ucode.c
===================================================================
--- valgrind.orig/coregrind/vg_from_ucode.c 2005-03-10 21:09:43.000000000 -0800
+++ valgrind/coregrind/vg_from_ucode.c 2005-03-21 16:56:59.000000000 -0800
@@ -154,6 +154,11 @@ static Histogram histogram[100];
void VG_(print_ccall_stats)(void)
{
+ if (ccalls == 0) {
+ VG_(message)(Vg_DebugMsg, " No ccalls");
+ return;
+ }
+
VG_(message)(Vg_DebugMsg,
" ccalls: %u C calls, %u%% saves+restores avoided"
" (%d bytes)",
J
|
|
From: Josef W. <Jos...@gm...> - 2005-03-22 00:55:36
|
On Tuesday 22 March 2005 01:01, jp...@mu... wrote: > Does anyone know the status of the callgrind skin, > perhaps with respect to Debian sid? Which version of valgrind are you using? For VG 2.4.0-rcX, you can checkout the CVS version of callgrind (see http://sourceforge.net/cvs/?group_id=64331, module callgrind). Josef |
|
From: <jp...@mu...> - 2005-03-22 00:02:09
|
Does anyone know the status of the callgrind skin,
perhaps with respect to Debian sid?
~ callgrind
Can't open tool "callgrind": /usr/lib/valgrind/vgskin_callgrind.so:
undefined symbol: vgPlain_register_compact_helper
valgrind: couldn't load tool
Available tools:
cachegrind
addrcheck
memcheck
corecheck
callgrind
lackey
none
massif
zsh: exit 127 callgrind
~ ll /usr/lib/valgrind
total 4288
drwxr-xr-x 2 root root 4096 Mar 20 18:00 ./
drwxr-xr-x 187 root root 69632 Mar 21 15:13 ../
-rw-r--r-- 1 root root 9021 Mar 15 05:49 debian.supp
-rw-r--r-- 1 root root 23500 Mar 15 05:52 default.supp
-rw-r--r-- 1 root root 3303 Mar 15 05:52 glibc-2.1.supp
-rw-r--r-- 1 root root 9204 Mar 15 05:52 glibc-2.2.supp
-rw-r--r-- 1 root root 7395 Mar 15 05:52 glibc-2.3.supp
-rwxr-xr-x 1 root root 156690 Mar 15 05:52 hp2ps*
-rw-r--r-- 1 root root 2162 Mar 19 13:49 python.supp
-rwxr-xr-x 1 root root 2409490 Mar 15 05:52 stage2*
-rw-r--r-- 1 root root 57312 Mar 15 05:52 vg_inject.so
-rw-r--r-- 1 root root 106463 Mar 15 05:52 vgpreload_addrcheck.so
-rw-r--r-- 1 root root 76871 Mar 15 05:52 vgpreload_massif.so
-rw-r--r-- 1 root root 106463 Mar 15 05:52 vgpreload_memcheck.so
-rw-r--r-- 1 root root 211314 Mar 15 05:52 vgskin_addrcheck.so
-rw-r--r-- 1 root root 98771 Mar 15 05:52 vgskin_cachegrind.so
-rw-r--r-- 1 root root 136744 Nov 11 13:44 vgskin_callgrind.so
-rw-r--r-- 1 root root 36455 Mar 15 05:52 vgskin_corecheck.so
-rw-r--r-- 1 root root 41240 Mar 15 05:52 vgskin_lackey.so
-rw-r--r-- 1 root root 79982 Mar 15 05:52 vgskin_massif.so
-rw-r--r-- 1 root root 615512 Mar 15 05:52 vgskin_memcheck.so
-rw-r--r-- 1 root root 36341 Mar 15 05:52 vgskin_none.so
-rw-r--r-- 1 root root 3107 Mar 15 05:52 xfree-3.supp
-rw-r--r-- 1 root root 3839 Mar 15 05:52 xfree-4.supp
-- Jason Weber
|
|
From: Klint G. <kg...@kg...> - 2005-03-21 23:44:20
|
On Mon, 21 Mar 2005 15:21:37 -0800, Jeremy Fitzhardinge <je...@go...> wrote: > Turns out it was a simple fix. Try this out: ok, that got me past the segmentation fault. I have an internal error (signal 8) and a message that the impossible happened. attached is the output. klint. +---------------------------------------+-----------------+ : Klint Gore : "Non rhyming : : EMail : kg...@kg... : slang - the : : Snail : A.B.R.I. : possibilities : : Mail University of New England : are useless" : : Armidale NSW 2351 Australia : L.J.J. : : Fax : +61 2 6772 5376 : : +---------------------------------------+-----------------+ |
|
From: Jeremy F. <je...@go...> - 2005-03-21 23:21:41
|
Jeremy Fitzhardinge wrote:
>The kernel has a special workaround to deal with Kylix binaries by
>ignoring errors on that zero operation, but usermode code can't easily
>do that. I'll need to think about the nicest way to solve this (lobby
>Borland to generate proper executables would be a good start).
>
>
Turns out it was a simple fix. Try this out:
Index: valgrind/coregrind/ume.c
===================================================================
--- valgrind.orig/coregrind/ume.c 2005-03-10 21:09:43.000000000 -0800
+++ valgrind/coregrind/ume.c 2005-03-21 15:19:58.000000000 -0800
@@ -261,7 +263,7 @@ ESZ(Addr) mapelf(struct elfinfo *e, ESZ(
}
bytes = bss & (VKI_PAGE_SIZE - 1);
- if (bytes > 0) {
+ if ((prot & PROT_WRITE) && (bytes > 0)) {
bytes = VKI_PAGE_SIZE - bytes;
memset((char *)bss, 0, bytes);
}
|
|
From: Jeremy F. <je...@go...> - 2005-03-21 23:10:24
|
Klint Gore wrote: >attached is version numbers, valgrind output, ldd on program, gbd >backtrace, strace. > >The binary is at http://abri.une.edu.au/staff/klint/hello.bz2 > > Ah, OK. This isn't actually a correctly formed executable: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x08048034 0x08048034 0x000a0 0x000a0 R E 0x4 INTERP 0x0000d4 0x080480d4 0x080480d4 0x00013 0x00013 R 0x1 [Requesting program interpreter: /lib/ld-linux.so.2] LOAD 0x000000 0x08048000 0x08048000 0x06230 0x106230 R E 0x1000 ^^^^^^^ ^^^^^^^^ ^ LOAD 0x006230 0x0814f230 0x0814f230 0x00b50 0x01640 RW 0x1000 DYNAMIC 0x006cf8 0x0814fcf8 0x0814fcf8 0x00088 0x00088 RW 0x4 The segment at 0x08048000 is mapped read-only, but it has a file size smaller than the memory size; the space between these two is defined to be zeroed. However, because it is read-only, Valgrind crashes when trying to zero it. The kernel has a special workaround to deal with Kylix binaries by ignoring errors on that zero operation, but usermode code can't easily do that. I'll need to think about the nicest way to solve this (lobby Borland to generate proper executables would be a good start). Could you file a bug for this? J |