John Reiser | 3 Oct 06:25 2011

Re: valgrind support for ARMv5TE with MMU

On 08/26/2011 04:32 AM, Ali Günhan Akyürek wrote:
> Thanks for the responses. As far as I understand, currently it's not
> possible to the some limitations.

I've achieved initial success for armv5te: "valgrind /bin/date" runs
on my sheevaplug (1200 BogoMIPS, 512MB RAM) under Debian testing (wheezy).
The patch is:  https://bugs.kde.org/show_bug.cgi?id=276897#c2
to the bug report titled "ARM v6 legacy patches."

--

-- 

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
Gaetano Mendola | 3 Oct 14:17 2011
Picon

valgrind and CUDA4.0

Hi all,
running my program (it uses cuda) with valgrind I'm getting this warning:

Warning: set address range perms: large range [0x800000000,
0x1300000000) (noaccess)

and I think even some false allarms (I will ask in CUDA forum).

Is that warning something to worry about ?

With CUDA 4.0 Nvidia introduced the Unified Memory Model, and even
launching the following
code:

#include <stdlib.h>
#include <iostream>
#include <cufft.h>

int main(int argc, char** argv) {
  unsigned int myPlan;

  if(cufftPlan1d(&myPlan, 1024, CUFFT_C2C, 1) != CUFFT_SUCCESS) {
    std::cout << "cufftPlan1d failed" << std::endl;
    ::abort();
  }

  if(cufftDestroy(myPlan) != CUFFT_SUCCESS) {
    std::cout << "cufftDestroy failed" << std::endl;
    ::abort();
  }
(Continue reading)

Dmitry N. Mikushin | 3 Oct 14:55 2011
Picon

Re: valgrind and CUDA4.0

Hi Gaetano,

With CUDA I often see the same output you showed: CUDA runtime has
out-of-range reads and leaks some memory. But these issues should be
harmless.

- D.

2011/10/3 Gaetano Mendola <mendola <at> gmail.com>:
> Hi all,
> running my program (it uses cuda) with valgrind I'm getting this warning:
>
> Warning: set address range perms: large range [0x800000000,
> 0x1300000000) (noaccess)
>
> and I think even some false allarms (I will ask in CUDA forum).
>
> Is that warning something to worry about ?
>
> With CUDA 4.0 Nvidia introduced the Unified Memory Model, and even
> launching the following
> code:
>
> #include <stdlib.h>
> #include <iostream>
> #include <cufft.h>
>
> int main(int argc, char** argv) {
>  unsigned int myPlan;
>
(Continue reading)

Andrew Cooper | 3 Oct 16:23 2011

Query about Invalid reads

Hello,

I am using valgrind-3.6.0.SVN-Debian, and cant work out why I am getting
Invalid read errors.

The routine is one which is adding symbols to a std::map, indexed by
their virtual address.  As multiple symbols may share the same virtual
address, I need to concatenate the symbol names in the already present
symbol entry.

I have the following (cut down, debugging) code which demonstrates the
problem:

            Symbol * prev = prev_itt->second;
            char * prev_name = prev->name;

            size_t newsize = strlen(prev_name);
            newsize += strlen(sym->name);
            newsize += 2;

            prev->name = new char[newsize];
            //Should concat and delete prev_name, but for debugging
leave like this
            delete [] prev->name;

            //For debugging, put this back, so no leaks
            prev->name = prev_name;

With the new char[newsize] and delete [] prev->name commented out,
valgrind is perfectly happy with the code (which is effectively a nop)
(Continue reading)

Tom Hughes | 3 Oct 16:41 2011
Picon

Re: Query about Invalid reads

On 03/10/11 15:23, Andrew Cooper wrote:

> Where the two errors are referring to the two strlen() calls when
> calculating newsize.
>
> Are these errors indicating a supposed bug in my code, or are they
> complaining about something in the __GI_strlen replaced code.  If so,
> does this mean there is a bug in __GI_strlen ?

Most likely it means you are calling strlen on something that isn't nul 
terminated.

Make sure the code at symbol.cpp:9 is nul terminating the string, as 
that is where the allocation is made that you are running off the end of.

Tom

--

-- 
Tom Hughes (tom <at> compton.nu)
http://compton.nu/

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
Andrew Cooper | 3 Oct 17:04 2011

Re: Query about Invalid reads

On 03/10/11 15:41, Tom Hughes wrote:
> On 03/10/11 15:23, Andrew Cooper wrote:
>
>> Where the two errors are referring to the two strlen() calls when
>> calculating newsize.
>>
>> Are these errors indicating a supposed bug in my code, or are they
>> complaining about something in the __GI_strlen replaced code.  If so,
>> does this mean there is a bug in __GI_strlen ?
> Most likely it means you are calling strlen on something that isn't nul 
> terminated.
>
> Make sure the code at symbol.cpp:9 is nul terminating the string, as 
> that is where the allocation is made that you are running off the end of.
>
> Tom
>

Ah - fantastic catch.  Thankyou.  I had an off by one error when
allocating the original name, which was hidden by a strncpy.

FYI: I am in the process of optimizing a working application for space -
this bug has come about as a result of converting from std::string to
char *.  Profiling appears to show this leading to a 7% memory reduction.

Is there a useful location to put an FAQ/equiv stating that an apparent
error in __GI_strlen might suggest that you are not working with NULL
terminating strings? Google was no use which is why I emailed the list.

--

-- 
(Continue reading)

Tom Hughes | 3 Oct 17:07 2011
Picon

Re: Query about Invalid reads

On 03/10/11 16:04, Andrew Cooper wrote:

> Is there a useful location to put an FAQ/equiv stating that an apparent
> error in __GI_strlen might suggest that you are not working with NULL
> terminating strings? Google was no use which is why I emailed the list.

It's kind of valgrind 101 really - read what the error report says and 
consider what memory that routine will be reading, and where valgrind 
says that memory was allocated.

I mean if valgrind says that strlen is reading 0 bytes beyond the end of 
a block allocated at a given location then it's a pretty good bet that 
the nul terminator was missing on a string and it ran off the end.

Tom

--

-- 
Tom Hughes (tom <at> compton.nu)
http://compton.nu/

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
Andrew Cooper | 3 Oct 17:15 2011

Re: Query about Invalid reads

On 03/10/11 15:52, David Chapman wrote:
> On 10/3/2011 7:23 AM, Andrew Cooper wrote:
>> Hello,
>>
>> I am using valgrind-3.6.0.SVN-Debian, and cant work out why I am getting
>> Invalid read errors.
>>
>> The routine is one which is adding symbols to a std::map, indexed by
>> their virtual address.  As multiple symbols may share the same virtual
>> address, I need to concatenate the symbol names in the already present
>> symbol entry.
>>
>> I have the following (cut down, debugging) code which demonstrates the
>> problem:
>>
>>              Symbol * prev = prev_itt->second;
>>              char * prev_name = prev->name;
>>
>>              size_t newsize = strlen(prev_name);
>>              newsize += strlen(sym->name);
>>              newsize += 2;
>>
>>
>>              prev->name = new char[newsize];
>>              //Should concat and delete prev_name, but for debugging
>> leave like this
>>              delete [] prev->name;
>>
>>              //For debugging, put this back, so no leaks
>>              prev->name = prev_name;
(Continue reading)

Andrew Cooper | 3 Oct 17:19 2011

Re: Query about Invalid reads

On 03/10/11 16:07, Tom Hughes wrote:
> On 03/10/11 16:04, Andrew Cooper wrote:
>
>> Is there a useful location to put an FAQ/equiv stating that an apparent
>> error in __GI_strlen might suggest that you are not working with NULL
>> terminating strings? Google was no use which is why I emailed the list.
> It's kind of valgrind 101 really - read what the error report says and 
> consider what memory that routine will be reading, and where valgrind 
> says that memory was allocated.
>
> I mean if valgrind says that strlen is reading 0 bytes beyond the end of 
> a block allocated at a given location then it's a pretty good bet that 
> the nul terminator was missing on a string and it ran off the end.
>
> Tom

I suppose.  I am still getting used to valgrind.

Anyway, thanks for the help and I will try not to be so dim in the future.

--

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
(Continue reading)

David Chapman | 3 Oct 16:52 2011
Picon

Re: Query about Invalid reads

On 10/3/2011 7:23 AM, Andrew Cooper wrote:
> Hello,
>
> I am using valgrind-3.6.0.SVN-Debian, and cant work out why I am getting
> Invalid read errors.
>
> The routine is one which is adding symbols to a std::map, indexed by
> their virtual address.  As multiple symbols may share the same virtual
> address, I need to concatenate the symbol names in the already present
> symbol entry.
>
> I have the following (cut down, debugging) code which demonstrates the
> problem:
>
>              Symbol * prev = prev_itt->second;
>              char * prev_name = prev->name;
>
>              size_t newsize = strlen(prev_name);
>              newsize += strlen(sym->name);
>              newsize += 2;
>
>
>              prev->name = new char[newsize];
>              //Should concat and delete prev_name, but for debugging
> leave like this
>              delete [] prev->name;
>
>              //For debugging, put this back, so no leaks
>              prev->name = prev_name;

(Continue reading)


Gmane