valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] VALGRIND_DO_CLIENT_REQUEST

[Philippe W. <phi...@sk...>]

On Wed, 2014-12-24 at 16:42 +0200, Yakir Ben Senyur wrote:
> Hi,
> I moving my code from 32bit to 64bit and the pointers changed from 4
> bytes to 8 bytes.
> I try to you valgrind function   VALGRIND_DO_CLIENT_REQUEST .
> my code send to this function void*.
> It failed on cast from 8 bytes of pointer to unsigned int (4 bytes).
> my code :
>  void markAsUnaccessible(void* address, size_t size)
>   {
>     VALGRIND3_DISCARD(VALGRIND3_MAKE_NOACCESS(address,size));
>   }


It looks like you are having problems because of local
redefinitions of valgrind requests.

The usual way to do is to just include valgrind.h or memcheck.h or ...
and then use the requests defined in these files.
E.g. 
   ...
   char magic_foople_zone[0x1000];
   ...
   (void) VALGRIND_MAKE_MEM_NOACCESS(magic_foople_zone, 0x1000)

A.o., the valgrind regression test testing such requests
have no special thing to do to compile cleanly in 32 bits or 64 bits.

Using the include files provided in valgrind will also work in the
(unlikely) case the 'magic' instructions of a client request would
change in a newer valgrind version.

Philippe

Re: [Valgrind-users] VALGRIND_DO_CLIENT_REQUEST

[John R. <jr...@bi...>]

> #define VALGRIND_DO_CLIENT_REQUEST(               \
>            _zzq_rlval, _zzq_default, _zzq_request,                 \
>            _zzq_arg1, _zzq_arg2, _zzq_arg3, _zzq_arg4, _zzq_arg5)    \
> -  { volatile unsigned long long int _zzq_args[6];               \
> -    volatile unsigned long long int _zzq_result;                \
> -    _zzq_args[0] = (unsigned long long int)(_zzq_request);        \
> -    _zzq_args[1] = (unsigned long long int)(_zzq_arg1);           \
    [[snip]]
> +  { volatile uint64_t _zzq_args[6]; \
> +    volatile uint64_t _zzq_result;  \
> +    _zzq_args[0] = (uint64_t)(_zzq_request);  \
> +    _zzq_args[1] = (uint64_t)(_zzq_arg1); \
    [[snip]]
>
> but this only handle 64bit, i need solulition that work both ways when i compile to  32bit/64bit executable

Use "void *" to handle the native width:
	volatile void *_zzq_args[6];
	volatile void *_zzq_result;
	_zzq_args[0] = (void *)(unsigned long)(_zzq_request);
	_zzq_args[1] = (void *)(unsigned long)(_zzq_arg1);
    [[snip]]

The cast to "(unsigned long)" is required to avoid the complaint from gcc:
	cast to pointer from integer of different size [-Wint-to-pointer-cast]
when -m64 and _zzq_arg1 is only an 'int'.  This solution depends on
   sizeof(void *) <= sizeof(unsigned long)
for which the only important exception is Microsoft C in 64-bit mode.
[MSVC chooses 4==sizeof(long) in *ALL* cases.]

Note that the producer and the consumer must agree on the actual type
of each argument, particularly 'unsigned' or not, and 'long' or not.
Otherwise it is impossible to choose a type for casting the pass-through
arguments that conveys the correct value in all cases of mismatched
expectations.

[Valgrind-users] VALGRIND_DO_CLIENT_REQUEST

[Yakir B. S. <Yak...@mo...>]

Hi,
I moving my code from 32bit to 64bit and the pointers changed from 4 
bytes to 8 bytes.
I try to you valgrind function   VALGRIND_DO_CLIENT_REQUEST .
my code send to this function void*.
It failed on cast from 8 bytes of pointer to unsigned int (4 bytes).
my code :
  void markAsUnaccessible(void* address, size_t size)
   {
     VALGRIND3_DISCARD(VALGRIND3_MAKE_NOACCESS(address,size));
   }

#define VALGRIND3_DISCARD(_qzz_blkindex)                          \
    (__extension__ ({unsigned int _qzz_res;                       \
     VALGRIND3_DO_CLIENT_REQUEST(_qzz_res, 0 /* default return */, \
                             VG3_USERREQ__DISCARD,                 \
                             0, _qzz_blkindex, 0, 0, 0);          \
     _qzz_res;                                                    \
    }))


   #define VALGRIND3_DO_CLIENT_REQUEST(                               \
         _zzq_rlval, _zzq_default, _zzq_request,                   \
         _zzq_arg1, _zzq_arg2, _zzq_arg3, _zzq_arg4, _zzq_arg5)    \
   { volatile unsigned int _zzq_args[6];                           \
     volatile unsigned int _zzq_result;                            \
     _zzq_args[0] = (unsigned int)(_zzq_request);                  \
     _zzq_args[1] = (unsigned int)(_zzq_arg1);                     \
     _zzq_args[2] = (unsigned int)(_zzq_arg2);                     \
     _zzq_args[3] = (unsigned int)(_zzq_arg3);                     \
     _zzq_args[4] = (unsigned int)(_zzq_arg4);                     \
     _zzq_args[5] = (unsigned int)(_zzq_arg5);                     \
     __asm__ volatile(__SPECIAL_INSTRUCTION_PREAMBLE               \
                      /* %EDX = client_request ( %EAX ) */         \
                      "xchgl %%ebx,%%ebx"                          \
                      : "=d" (_zzq_result)                         \
                      : "a" (&_zzq_args[0]), "0" (_zzq_default)    \
                      : "cc", "memory"                             \
                     );                                            \
     _zzq_rlval = _zzq_result;                                     \
   }


can you help?
I try find solution over the internet and i see that many users have - 
VALGRIND_DO_CLIENT_REQUEST
as this code :
#define VALGRIND_DO_CLIENT_REQUEST(                               \
           _zzq_rlval, _zzq_default, _zzq_request,                   \
           _zzq_arg1, _zzq_arg2, _zzq_arg3, _zzq_arg4, _zzq_arg5)    \
-  { volatile unsigned long long int _zzq_args[6];                 \
-    volatile unsigned long long int _zzq_result;                  \
-    _zzq_args[0] = (unsigned long long int)(_zzq_request);        \
-    _zzq_args[1] = (unsigned long long int)(_zzq_arg1);           \
-    _zzq_args[2] = (unsigned long long int)(_zzq_arg2);           \
-    _zzq_args[3] = (unsigned long long int)(_zzq_arg3);           \
-    _zzq_args[4] = (unsigned long long int)(_zzq_arg4);           \
-    _zzq_args[5] = (unsigned long long int)(_zzq_arg5);           \
+  { volatile uint64_t _zzq_args[6];                 \
+    volatile uint64_t _zzq_result;                  \
+    _zzq_args[0] = (uint64_t)(_zzq_request);        \
+    _zzq_args[1] = (uint64_t)(_zzq_arg1);           \
+    _zzq_args[2] = (uint64_t)(_zzq_arg2);           \
+    _zzq_args[3] = (uint64_t)(_zzq_arg3);           \
+    _zzq_args[4] = (uint64_t)(_zzq_arg4);           \
+    _zzq_args[5] = (uint64_t)(_zzq_arg5);           \

but this only handle 64bit, i need solulition that work both ways when i 
compile to  32bit/64bit executable

thanks,
yakir

This mail was sent via Mail-SeCure system.



 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************

Re: [Valgrind-users] Problem running even simple programs

[Philippe W. <phi...@sk...>]

On Thu, 2014-12-11 at 14:48 +0300, Mikhail Baikov wrote:
> On 12/05/2014 09:26 PM, Philippe Waroquiers wrote:
> > On Thu, 2014-12-04 at 16:16 +0300, Mikhail Baikov wrote:
> >
> >> And the crash... I'm sorry it's not a segfault. It's a crash.
> >> One of the strange things is that inspite of --run-libc-freeres set no
> >> in the log appears
> >> /bin/sh: symbol '__libc_freeres': can't resolve symbol and the rest...
> > This is I suppose because valgrind has not been properly compiled
> > for ulibc.
> > If you look in coregrind/vg_preloaded.c, you will see that if symbol
> > __UCLIBC__ is defined, then no calls to __libc_freeres();
> > will be generated.
> > So, that looks a first problem to solve : I guess you should
> > ensure that  __UCLIBC__ is defined when you compile on the host,
> > and ensure to compile with the relevant uclibc headers files at
> > the host side.
> >
> >
> Yeah. Raising __UCLIBC__ flag (export CFLAGS="-D__UCLIBC__") has helped 
> but it seems to me that this flag will never be raised in normal 
> conditions. Searching this flag among sources I found no place where 
> it's defined.
> $ grep -R "__UCLIBC__" ./valgrind-3.10.1/*
> ./valgrind-3.10.1/coregrind/vg_preloaded.c:#  if !defined(__UCLIBC__) \
> ./valgrind-3.10.1/coregrind/m_debuginfo/minilzo-inl.c:#elif 
> defined(__UCLIBC__) && defined(__UCLIBC_MAJOR__) && 
> defined(__UCLIBC_MINOR__)
> ./valgrind-3.10.1/coregrind/m_debuginfo/lzodefs.h:#elif 
> defined(__UCLIBC__) && defined(__UCLIBC_MAJOR__) && 
> defined(__UCLIBC_MINOR__)
> 
Yes, it looks like uclibc is not detected during configure time.
So, you have to set this flag yourself.

Philippe

Re: [Valgrind-users] KCachegrind

[Josef W. <Jos...@gm...>]

Hi,

You found a very old version of KCachegrind web pages.
>From where did you get this URL? Via Google?

I need to remove them. Anyway, if you use

  http://kcachegrind.sourceforge.net

the pages are quite up-to-date.
And as Milian said, of course you also can either use a distribution
package or check out sources via git.

Josef


Am 12.12.2014 um 05:57 schrieb Wei Wen:
> Hello,
> 
> I was trying to install KCachegrind so that I can view the data
> generated by callgrind graphically. However, the webpage for KCachegrind
> seems very old. It says that in order to install KCachegrind, two more
> installations are needed: (1)  Qt 3.x (with development package), and
> (2) KDE libraries (kdelibs) from KDE 3.0.x or KDE 3.1.x or KDE 3.2.x
> (with development package). For the first software, I already have it
> installed,, but it is version 5. I installed it using its online
> installer and am not sure if it includes the development package. For
> the second software, I am not sure if the KDE here means the KDE desktop
> that is similiar to GNOME. If it is, then I have it installed, but I
> don't know where its path is. 
> 
> In KCachegrind
> website: http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindInstallation,
> the installation steps for KCachegrind is:
> 
> ./configure --prefix=/opt/kde3
>   make
>   make install (as "root" if needed)
> 
> I am stuck on step one. I didn't include "--prefix" since I don't know the path, and my KDE may not be kde3. The error I have is something like X is not found. I don't know what that means. If I continue with "make", then it says that there is nothing to make. I think there is no makefile. 
> 
> Does anyone know how to install KCachegrind? Any help is greatly appreciated.
> 
> 
> Sincerely,
> 
> Wei Wen
> 
> 
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

Re: [Valgrind-users] KCachegrind

[Milian W. <ma...@mi...>]

On Thursday 11 December 2014 23:57:01 Wei Wen wrote:
> Hello,
> 
> I was trying to install KCachegrind so that I can view the data generated
> by callgrind graphically. However, the webpage for KCachegrind seems very
> old. It says that in order to install KCachegrind, two more installations
> are needed: (1)  Qt 3.x (with development package), and (2) KDE libraries
> (kdelibs) from KDE 3.0.x or KDE 3.1.x or KDE 3.2.x (with development
> package). For the first software, I already have it installed,, but it is
> version 5. I installed it using its online installer and am not sure if it
> includes the development package. For the second software, I am not sure if
> the KDE here means the KDE desktop that is similiar to GNOME. If it is,
> then I have it installed, but I don't know where its path is.
> 
> In KCachegrind website:
> http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindInstallation,
> the installation steps for KCachegrind is:
> 
> ./configure --prefix=/opt/kde3
>   make
>   make install (as "root" if needed)
> 
> I am stuck on step one. I didn't include "--prefix" since I don't know
> the path, and my KDE may not be kde3. The error I have is something
> like X is not found. I don't know what that means. If I continue with
> "make", then it says that there is nothing to make. I think there is
> no makefile.
> 
> Does anyone know how to install KCachegrind? Any help is greatly
> appreciated.

All of the above is horribly outdated. And, more importantly, it is probably 
not required for 99.999% of the people out there anyways. Just install 
kcachegrind via your distributions package manager. If you want to compile it 
from hand, here are the steps for the KDE4/Qt4 version:

git clone git://anongit.kde.org/kcachegrind
cd kcachegrind
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_PREFIX=<something> ..
make
make install

bye, HTH

-- 
Milian Wolff
ma...@mi...
http://milianw.de

[Valgrind-users] KCachegrind

[Wei W. <wei...@gm...>]

Hello,

I was trying to install KCachegrind so that I can view the data generated
by callgrind graphically. However, the webpage for KCachegrind seems very
old. It says that in order to install KCachegrind, two more installations
are needed: (1)  Qt 3.x (with development package), and (2) KDE libraries
(kdelibs) from KDE 3.0.x or KDE 3.1.x or KDE 3.2.x (with development
package). For the first software, I already have it installed,, but it is
version 5. I installed it using its online installer and am not sure if it
includes the development package. For the second software, I am not sure if
the KDE here means the KDE desktop that is similiar to GNOME. If it is,
then I have it installed, but I don't know where its path is.

In KCachegrind website:
http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindInstallation,
the installation steps for KCachegrind is:

./configure --prefix=/opt/kde3
  make
  make install (as "root" if needed)

I am stuck on step one. I didn't include "--prefix" since I don't know
the path, and my KDE may not be kde3. The error I have is something
like X is not found. I don't know what that means. If I continue with
"make", then it says that there is nothing to make. I think there is
no makefile.

Does anyone know how to install KCachegrind? Any help is greatly appreciated.


Sincerely,

Wei Wen

Re: [Valgrind-users] Problem running even simple programs

[Mikhail B. <mik...@de...>]

On 12/05/2014 09:26 PM, Philippe Waroquiers wrote:
> On Thu, 2014-12-04 at 16:16 +0300, Mikhail Baikov wrote:
>
>> And the crash... I'm sorry it's not a segfault. It's a crash.
>> One of the strange things is that inspite of --run-libc-freeres set no
>> in the log appears
>> /bin/sh: symbol '__libc_freeres': can't resolve symbol and the rest...
> This is I suppose because valgrind has not been properly compiled
> for ulibc.
> If you look in coregrind/vg_preloaded.c, you will see that if symbol
> __UCLIBC__ is defined, then no calls to __libc_freeres();
> will be generated.
> So, that looks a first problem to solve : I guess you should
> ensure that  __UCLIBC__ is defined when you compile on the host,
> and ensure to compile with the relevant uclibc headers files at
> the host side.
>
>
Yeah. Raising __UCLIBC__ flag (export CFLAGS="-D__UCLIBC__") has helped 
but it seems to me that this flag will never be raised in normal 
conditions. Searching this flag among sources I found no place where 
it's defined.
$ grep -R "__UCLIBC__" ./valgrind-3.10.1/*
./valgrind-3.10.1/coregrind/vg_preloaded.c:#  if !defined(__UCLIBC__) \
./valgrind-3.10.1/coregrind/m_debuginfo/minilzo-inl.c:#elif 
defined(__UCLIBC__) && defined(__UCLIBC_MAJOR__) && 
defined(__UCLIBC_MINOR__)
./valgrind-3.10.1/coregrind/m_debuginfo/lzodefs.h:#elif 
defined(__UCLIBC__) && defined(__UCLIBC_MAJOR__) && 
defined(__UCLIBC_MINOR__)

Re: [Valgrind-users] mmap(2) returns 0x0 for <=4096 bytes

[Philippe W. <phi...@sk...>]

On Mon, 2014-12-08 at 13:38 +0100, Kristaps Dzonsons wrote:
> Hello list,
> 
> I'm experiencing a very strange error with valgrind-3.10.1 on Mac OS X 
> 10.7.5 (via homebrew).  In short, mmap(2) returns 0x0 for a regular 
> MAP_FILE of <=4096 bytes.  To reproduce, I use the following simple test:
This looks like a Mac OS specific bug, as this is working for me
on linux (32 bits and 64 bits).

Having no access to a MacOs system, no way for me to investigate.

The best is to file a bug report on bugzilla, and maybe a MacOS
afficionado will dig into it.
Please attach the test program.

Thanks

Philippe

[Valgrind-users] FOSDEM Valgrind dev-room - Brussels, 31 Jan 2015 - DEADLINE this weekend/Monday

[Mark W. <mj...@re...>]

Hi Valgrind Users and Developers!

> It is December already and we would really like to collect some more
> proposals for our FOSDEM collaboration room in Brussels on Sunday 31
> January 2015.
> 
> The original Call For Participation (see below) said the Talk/Discussion
> Submission deadline was today, but we will extend it a little to make
> sure we have enough interesting talks/discussion topics.
> 
> If you are coming and want to talk about or discuss something, please
> submit a proposal (they don't have to be perfect or complete yet). And
> please feel free to contact one of the organizers or discuss your idea
> on the developer list first before entering it into the penta system.

DEADLINE for submitting proposals is THIS WEEKEND/MONDAY.
Please make sure you submit ideas before end of day Monday, 15 December.
We will start making a preliminary schedule for the devroom after that.

[Original CFP follows]

Valgrind developer room at FOSDEM 2015 (Brussels, Belgium, 31 January).

FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate.  It is renown for being
highly developer-oriented and brings together 5000+ hackers from all
over the world.  It is held in the city of Brussels (Belgium).
http://fosdem.org/

FOSDEM 2015 will take place during the weekend of Saturday, 31 January
and Sunday 1 February 2015.  On Saturday we will have a devroom for
Valgrind.  Devrooms are a place for development teams to meet,
discuss, hack and publicly present the project's latest improvements
and future directions.

We will have a whole day to hang out together as Valgrind community.
Please join us, regardless of whether you are a Valgrind core hacker,
Valgrind tool hacker, Valgrind user, Valgrind packager or hacker on a
project that integrates, extends or complements Valgrind.

Call For Participation

We would like to organize a series of talks/discussions on various
topics relevant to both core hackers, new developers, users, packagers
and cross project functionality.  Please do submit a talk proposal by
Monday 1 December 2014, so we can make a list of activities during the
day.

Some possible topics for talks/discussions are:

- Recently added functional changes (for valgrind users).

- State of the valgrind code base (core hackers).

- Speeding up Memcheck by inlining of the fast cases of its helper
  function calls (core hackers).

- Supporting Valgrind on MacOS X 10.9 (Mavericks) and 10.10 (Yosemite)
  (valgrind developers and users).

- The AArch64 ARMv8 port (valgrind developers and users).

- Valgrind and Wine (valgrind developers and users).

- Helgrind - basic design, problems and opportunities (core and tools).

- Get feedback on what what kinds of new functionality would
  be useful. Which tools users would like to see and/or which new
  features for the existing tools. (valgrind developers and users).

  - Modify memcheck to report the last leaked pointer to a block
    integrate "omega" as a memcheck option or omega as a separate tool.

  - Better support compiled and JITted code.
    allowing the JIT compiler to indicate the link between
    the JITted code and the source code.

  - Valgrind and transactional memory.

- How to add simple features (adding syscalls for a platform or VEX
  instructions for a architecture port). (new core developers).

- Making Valgrind really multi-threaded, parallelising Memcheck
  parallelising the rest of the framework, and tools (for core hackers).

- Should we continue to support MacOS? What about Valgrind on
  MS-Windows? Solaris? (attracting new hackers).

- Redo the JIT framework to reduce baseline overheads? (core hackers).

- Make Callgrind work sanely on ARM (core hackers).

- Discuss release/bugfixing strategy/policy (core hackers, packagers).

- Packaging valgrind for distros, handling patches, suppressions, etc.
  (packagers).

- Valgrind/GDB integration (cross project).

- Valgrind vs the compiler. Compilers like GCC and clang now have
  "valgrind like" features, eg -fsanitize=address|thread|undefined.
  How does valgrind complement or improve on these features?

- Eclipse and other visualisation tools for valgrind (cross project).

- Practical examples of using Valgrind in (big) system automatic
  regression testing (users).

Use the FOSDEM 'pentabarf' tool to submit your proposal.
https://penta.fosdem.org/submission/FOSDEM15/

- If necessary, create a Pentabarf account and activate it.

- In the "Person" section, provide First name, Last name
  (in the "General" tab), Email (in the "Contact" tab)
  and Bio ("Abstract" field in the "Description" tab).

- Submit a proposal by clicking on "Create event".

- Important! Select the "Valgrind devroom" track
  (on the "General" tab).

- Provide the title of your talk ("Event title" in the "General" tab).

- Provide a description of the subject of the talk and the
  intended audience (in the "Abstract" field of the "Description" tab)

- Provide a rough outline of the talk or goals of the session (a short
  list of bullet points covering topics that will be discussed) in the
  "Full description" field in the "Description" tab

Julian, Philippe and Mark will review the proposals and organize the
schedule for the day.  Please feel free to suggest or discuss any ideas
for the devroom on the Valgrind developer mailinglist before creating a
proposal: val...@li...

Recording of talks

This year the FOSDEM organisers plan to have live streaming and
recording fully working, both for remote/later viewing of talks, and
so that people can watch streams in the hallways when rooms are full.
This obviously requires speakers to consent to being recorded and
streamed.  If you plan to be a speaker, please understand that by
doing so you implicitly give consent for your talk to be recorded and
streamed.  The recordings will be published under the same licence as
all FOSDEM content (CC-BY).

Important dates:

  Talk/Discussion Submission deadline:    Monday    1 Dec 2014
  Devroom Schedule announcement:          Monday   15 Dec 2014
  Devroom day:                            Saturday 31 Jan 2015

Hope to see you all at FOSDEM 2015 in the Valgrind devroom.
Brussels (Belgium), Saturday 31 January 2015.
https://fosdem.org/2015/schedule/track/valgrind/

[Valgrind-users] Announcing heaptrack - A heap memory profiler for Linux

[Milian W. <ma...@mi...>]

Hello all,

with the consent of Julian, I'm happy to advertise a new tool of mine:
heaptrack, a heap memory profiler for Linux:

I've written a lengthy article about it with some details here:

http://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux

The tl;dr; version is:

- it's an alternative to heap profiling with Massif
- it has a lower overhead
- it collects much more data
- it can runtime-attach to existing processes

I'd like to see more people using it and giving me feedback. You'll need a 
CMake, a modern C++ compiler, parts of Boost, and libunwind. Then it's as easy 
as

    git://anongit.kde.org/heaptrack
    mkdir build
    cd build
    cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
    make install

to install heaptrack. Then, you can run it on your applications:

    heaptrack <yourapp> <your arguments>
    # ...
    heaptrack_print heaptrack.<yourapp>.$$.gz | less

Or attach to a running process:

    heaptrack -p $(pidof <yourapp>)
    # ...
    ^C
    heaptrack_print heaptrack.<yourapp>.$$.gz | less

The source code is tiny, and hopefully easy to read and hack. Patches welcome!

Cheers, happy profiling

-- 
Milian Wolff
ma...@mi...
http://milianw.de

Re: [Valgrind-users] source file location

[João M. S. S. <joa...@gm...>]

> As far as I know the Ubuntu dbg packages are built automatically just as
> the Fedora debuginfo ones are, so I would have expected one to exist...

You are right. I looked for it and found additional repos with the 
-dbgsym package for libtesseract3. The repos are located at 
http://ddebs.ubuntu.com

Thanks, this improves my already excellent experience with valgrind.

-- 
João M. S. Silva

Re: [Valgrind-users] source file location

[Tom H. <to...@co...>]

On 08/12/14 20:12, "João M. S. Silva" wrote:
> I'm using Ubuntu and I can't seem to find an exact equivalent of
> Fedora's debuginfo, except -dbg packages. However, tesseract does not
> have a -dbg package.
>
> My code uses tesseract library, i.e. libtesseract-dev. Since a
> libtesseract-dbg package is not available, I probably have to compile it
> myself.

As far as I know the Ubuntu dbg packages are built automatically just as 
the Fedora debuginfo ones are, so I would have expected one to exist...

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] source file location

[João M. S. S. <joa...@gm...>]

I'm using Ubuntu and I can't seem to find an exact equivalent of 
Fedora's debuginfo, except -dbg packages. However, tesseract does not 
have a -dbg package.

My code uses tesseract library, i.e. libtesseract-dev. Since a 
libtesseract-dbg package is not available, I probably have to compile it 
myself.

On 12/08/2014 07:31 PM, Tom Hughes wrote:
> On 08/12/14 19:28, "João M. S. Silva" wrote:
>
>> Thanks Tom, I was not sure that was feasible.
>>
>> What is the easiest/standard way in which I can get the source code line
>> of the possible leak? Is it compiling my code against tesseract's source
>> code?
>>
>> Or should I compile tesseract in debug mode and then use that library?
>
> Well I don't know what here is "your" code and what isn't, but broadly
> speaking for your own code just make sure to compile with debug and for
> code from the distro make sure to install the debuginfo packages.
>
> Tom
>

-- 
João M. S. Silva

Re: [Valgrind-users] source file location

[Tom H. <to...@co...>]

On 08/12/14 19:28, "João M. S. Silva" wrote:

> Thanks Tom, I was not sure that was feasible.
>
> What is the easiest/standard way in which I can get the source code line
> of the possible leak? Is it compiling my code against tesseract's source
> code?
>
> Or should I compile tesseract in debug mode and then use that library?

Well I don't know what here is "your" code and what isn't, but broadly 
speaking for your own code just make sure to compile with debug and for 
code from the distro make sure to install the debuginfo packages.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] source file location

[João M. S. S. <joa...@gm...>]

Thanks Tom, I was not sure that was feasible.

What is the easiest/standard way in which I can get the source code line 
of the possible leak? Is it compiling my code against tesseract's source 
code?

Or should I compile tesseract in debug mode and then use that library?

Thanks.

On 12/08/2014 07:24 PM, Tom Hughes wrote:
> On 08/12/14 19:09, "João M. S. Silva" wrote:
>
>> Can I provide valgrind with source files so that source code lines of
>> libraries compiled without -g are still shown?
>>
>> For example, I get this memory leak warning:
>
> [ snipped ]
>
>> but I can't tell exactly where it comes from.
>>
>> If I was able to tell valgrind that the source code for tesseract is
>> somewhere, it would avoid having to recompile all my code against
>> tesseract sources?
>
> How would that work? Valgrind would still need the debug information in
> order to know which addresses in your compiled code map to each line in
> the source files...
>
> Tom
>

-- 
João M. S. Silva

Re: [Valgrind-users] source file location

[Tom H. <to...@co...>]

On 08/12/14 19:09, "João M. S. Silva" wrote:

> Can I provide valgrind with source files so that source code lines of
> libraries compiled without -g are still shown?
>
> For example, I get this memory leak warning:

[ snipped ]

> but I can't tell exactly where it comes from.
>
> If I was able to tell valgrind that the source code for tesseract is
> somewhere, it would avoid having to recompile all my code against
> tesseract sources?

How would that work? Valgrind would still need the debug information in 
order to know which addresses in your compiled code map to each line in 
the source files...

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] source file location

[João M. S. S. <joa...@gm...>]

Hi,

Can I provide valgrind with source files so that source code lines of 
libraries compiled without -g are still shown?

For example, I get this memory leak warning:

==19995== 24 bytes in 1 blocks are possibly lost in loss record 110 of 354
==19995==    at 0x4C2ABBD: malloc (vg_replace_malloc.c:299)
==19995==    by 0x5D7C4F3: STRING::AllocData(int, int) (in 
/usr/lib/libtesseract.so.3.0.3)
==19995==    by 0x5D7C5E2: STRING::STRING() (in 
/usr/lib/libtesseract.so.3.0.3)
==19995==    by 0x5D2E597: tesseract::DawgLoader::Load() (in 
/usr/lib/libtesseract.so.3.0.3)
==19995==    by 0x5D2E972: _TessMemberResultCallback_0_0<true, 
tesseract::Dawg*, tesseract::DawgLoader>::Run() (in 
/usr/lib/libtesseract.so.3.0.3)
==19995==    by 0x5D2E848: tesseract::DawgCache::GetSquishedDawg(STRING 
const&, char const*, tesseract::TessdataType, int) (in 
/usr/lib/libtesseract.so.3.0.3)
==19995==    by 0x5D3623F: tesseract::Dict::Load(tesseract::DawgCache*) 
(in /usr/lib/libtesseract.so.3.0.3)
==19995==    by 0x5CF910F: tesseract::Wordrec::program_editup(char 
const*, bool, bool) (in /usr/lib/libtesseract.so.3.0.3)
==19995==    by 0x5C28C28: 
tesseract::Tesseract::init_tesseract_internal(char const*, char const*, 
char const*, tesseract::OcrEngineMode, char**, int, 
GenericVector<STRING> const*, GenericVector<STRING> const*, bool) (in 
/usr/lib/libtesseract.so.3.0.3)
==19995==    by 0x5C2949E: tesseract::Tesseract::init_tesseract(char 
const*, char const*, char const*, tesseract::OcrEngineMode, char**, int, 
GenericVector<STRING> const*, GenericVector<STRING> const*, bool) (in 
/usr/lib/libtesseract.so.3.0.3)
==19995==    by 0x5BDD4BB: tesseract::TessBaseAPI::Init(char const*, 
char const*, tesseract::OcrEngineMode, char**, int, 
GenericVector<STRING> const*, GenericVector<STRING> const*, bool) (in 
/usr/lib/libtesseract.so.3.0.3)
==19995==    by 0x420E07: Tesseract::Tesseract() (Tesseract.cpp:13)

but I can't tell exactly where it comes from.

If I was able to tell valgrind that the source code for tesseract is 
somewhere, it would avoid having to recompile all my code against 
tesseract sources?

Thanks.

-- 
João M. S. Silva

[Valgrind-users] mmap(2) returns 0x0 for <=4096 bytes

[Kristaps D. <kri...@bs...>]

Hello list,

I'm experiencing a very strange error with valgrind-3.10.1 on Mac OS X 
10.7.5 (via homebrew).  In short, mmap(2) returns 0x0 for a regular 
MAP_FILE of <=4096 bytes.  To reproduce, I use the following simple test:

#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int
main(int argc, char *argv[])
{
	int i, fd;
	void *buf;
	struct stat st;

	for (i = 1; i < argc; i++) {
		if (-1 == (fd = open(argv[i], O_RDONLY, 0))) {
			perror(argv[i]);
			break;
		}
		if (-1 == fstat(fd, &st)) {
			perror(argv[i]);
			break;
		}
		buf = mmap(NULL, st.st_size,
			PROT_READ, MAP_SHARED, fd, 0);
		if (MAP_FAILED == buf) {
			perror(argv[i]);
			break;
		}
		printf("%s -> %p (%zu)\n",
			argv[i], buf, (size_t)st.st_size);
		munmap(buf, st.st_size);
		close(fd);
	}
	return(i < argc ? EXIT_FAILURE : EXIT_SUCCESS);
}

When I run it on perfectly ordinary files, at first it randomly returned 
0x0 instead of the usual mapped address, for example,

% valgrind ./a.out ../kcgi/*.xml
../kcgi/index.xml -> 0x338000 (12424)
../kcgi/template.xml -> 0x0 (188)
../kcgi/test.xml -> 0x0 (4)
../kcgi/version_0_4_2.xml -> 0x0 (488)
../kcgi/version_0_4_3.xml -> 0x0 (576)
../kcgi/version_0_4_4.xml -> 0x0 (291)

And now without valgrind...

% ./a.out ../kcgi/*.xml
../kcgi/index.xml -> 0x109ecf000 (12424)
../kcgi/template.xml -> 0x109ecf000 (188)
../kcgi/test.xml -> 0x109ecf000 (4)
../kcgi/version_0_4_2.xml -> 0x109ecf000 (488)
../kcgi/version_0_4_3.xml -> 0x109ecf000 (576)
../kcgi/version_0_4_4.xml -> 0x109ecf000 (291)

After running this on more files, I noticed that large files seemed ok; 
small files failed.  I bisected, and in the end:

% valgrind  ./a.out test*.xml
test1.xml -> 0x0 (617)
test2.xml -> 0x338000 (6170)
test3.xml -> 0x0 (3117)
test4.xml -> 0x338000 (4820)
test5.xml -> 0x0 (4096)
test6.xml -> 0x338000 (4097)

In short, I can reliably have a value of 0x0 returned for files of less 
than or equal to 4096 bytes.

Any thoughts?  valgrind itself doesn't report anything, and 
--trace-syscalls for the offending parts show nothing different for the 
"failed" cases.

Best,

Kristaps

Re: [Valgrind-users] Question about memcheck error messages

[John R. <jr...@bi...>]

> I ran valgrind to check a fairly large open source software, and found a number of memory leak issues. But I am not sure if those leaks are issues in valgrind or the tested software. I list part of the error messages below:
>
> 20 bytes in 2 blocks are definitely lost in loss record 12 of 53
> at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
>
> by 0x6113AB1: strdup (strdup.c 43)
> by 0x476767:  tpltlex() (in /usr/sbin/xorpsh)
> by 0x471EA8:  tpltparse (in /usr/sbin/xorpsh)
> by 0x47281B:  parse_template() (in /usr/sbin/xorpsh)
> by 0x45D446:  TemplateTree::parse_file (std::string const& , std::string const&, std::string&)  (in /usr/sbin/xorpsh)
> by 0x45E9A4:  TemplateTree::load_template_tree(std::string const& , std::string&) (in /usr/sbin/xorpsh)
> by 0x425BAB:  XorpShell::XorpShell(EventLoop&, std::string const&, std::string const&, std::string const&, bool)  (in /usr/sbin/xorpsh)
> by 0x426293:  main(in /usr/sbin/xorpsh)
>
>
> The loss is in a valgrind file,

The malloc() subroutine which performed the allocation is the memcheck function
which intercepts the call to the malloc that is contained in libc.
All memory leaks will show some memcheck intercepting function as the
allocator of the leaked block.  That is the way that memcheck starts
tracking the allocated blocks.

  but in the tested software, even though the lost is caused by a number of functions and methods in the tested software.

Yes, the tested software forgot to call free() for this particular block.

  How to interpret this? Thank you very much.

[Valgrind-users] Question about memcheck error messages

[Wei W. <wei...@gm...>]

Hello,

I ran valgrind to check a fairly large open source software, and found a
number of memory leak issues. But I am not sure if those leaks are issues
in valgrind or the tested software. I list part of the error messages below:

20 bytes in 2 blocks are definitely lost in loss record 12 of 53
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so

by 0x6113AB1: strdup (strdup.c 43)
by 0x476767:  tpltlex() (in /usr/sbin/xorpsh)
by 0x471EA8:  tpltparse (in /usr/sbin/xorpsh)
by 0x47281B:  parse_template() (in /usr/sbin/xorpsh)
by 0x45D446:  TemplateTree::parse_file (std::string const& , std::string
const&, std::string&)  (in /usr/sbin/xorpsh)
by 0x45E9A4:  TemplateTree::load_template_tree(std::string const& ,
std::string&) (in /usr/sbin/xorpsh)
by 0x425BAB:  XorpShell::XorpShell(EventLoop&, std::string const&,
std::string const&, std::string const&, bool)  (in /usr/sbin/xorpsh)
by 0x426293:  main(in /usr/sbin/xorpsh)


The loss is in a valgrind file, but in the tested software, even though the
lost is caused by a number of functions and methods in the tested software.
How to interpret this? Thank you very much.

Sincerely,
Wei Wen

Re: [Valgrind-users] Problem running even simple programs

[Philippe W. <phi...@sk...>]

On Thu, 2014-12-04 at 16:16 +0300, Mikhail Baikov wrote:

> And the crash... I'm sorry it's not a segfault. It's a crash.
> One of the strange things is that inspite of --run-libc-freeres set no 
> in the log appears
> /bin/sh: symbol '__libc_freeres': can't resolve symbol and the rest...
This is I suppose because valgrind has not been properly compiled
for ulibc.
If you look in coregrind/vg_preloaded.c, you will see that if symbol
__UCLIBC__ is defined, then no calls to __libc_freeres();
will be generated.
So, that looks a first problem to solve : I guess you should
ensure that  __UCLIBC__ is defined when you compile on the host,
and ensure to compile with the relevant uclibc headers files at
the host side.

>From what I see in the trace below, the problem happens
with /bin/sh (/bin/bash).
So, I guess none of your own executables are even started.
After first fixing the above compilation problem, you might
maybe understand better what is happening by having shell debugging
(e.g. do  valgrind /bin/sh -x <your script>)

Alternatively, to simplify seeing what happens, do run valgrind
on a trivial program that does a malloc/free (hoping
this reproduces the problem you see)
and give the full trace e.g. with 
    -v -v -v -d -d -d --trace-malloc=yes --trace-syscalls=yes
--trace-redir=yes --trace-signals=yes

Otherwise, try the same trace with the big program, hoping
this is not GBs of traces.

Philippe 

> I have no idea what exactly to show
> 
> ==2633== Adding active redirection:
> --2633--     new: 0x048965d0 (valloc              ) R-> (1012.0) 
> 0x0481ea98 valloc
> --2633:2:transtab   discard_translations(0x4896734, 1) req by 
> redir_new_DebugInfo(from_addr)
> --2633:2:transtab                       FAST, ec = 44
> --2633:2:transtab   discard_translations(0x481ea00, 1) req by 
> redir_new_DebugInfo(to_addr)
> --2633:2:transtab                       FAST, ec = 61
> ==2633== Adding active redirection:
> --2633--     new: 0x04896734 (posix_memalign      ) R-> (1016.0) 
> 0x0481ea00 posix_memalign
> 
> /bin/sh: symbol '__libc_freeres': can't resolve symbol
> --2633:1:syswrap- thread_wrapper(tid=1): exit, schedreturncode 
> VgSrc_ExitThread
> --2633:1:syswrap- run_a_thread_NORETURN(tid=1): post-thread_wrapper
> --2633:1:syswrap- run_a_thread_NORETURN(tid=1): last one standing
> --2633:1:main     entering VG_(shutdown_actions_NORETURN)
> --2633:1:aspacem  <<< SHOW_SEGMENTS: Memory layout at client shutdown 
> (57 segments, 9 segnames)
> --2633:1:aspacem  ( 0) 
> /bin/mbaikov/valgrind_arm/lib/valgrind/memcheck-arm-linux
> --2633:1:aspacem  ( 1) /bin/bash
> --2633:1:aspacem  ( 2) /lib/ld-uClibc-0.9.32.1.so
> --2633:1:aspacem  ( 3) /tmp/vgdb-pipe-shared-mem-vgdb-2633-by-root-on-???
> --2633:1:aspacem  ( 4) 
> /bin/mbaikov/valgrind_arm/lib/valgrind/vgpreload_core-arm-linux.so
> --2633:1:aspacem  ( 5) 
> /bin/mbaikov/valgrind_arm/lib/valgrind/vgpreload_memcheck-arm-linux.so
> --2633:1:aspacem  ( 6) /lib/libdl-0.9.32.1.so
> --2633:1:aspacem  ( 7) /lib/libgcc_s.so.1
> --2633:1:aspacem  ( 8) /lib/libuClibc-0.9.32.1.so
> --2633:1:aspacem    0: RSVN 0000000000-0000007fff   32768 ----- SmFixed
> --2633:1:aspacem    1: file 0000008000-00000a0fff  626688 r-x-- d=0x00c 
> i=6174178 o=0       (1)
> --2633:1:aspacem    2: RSVN 00000a1000-00000a7fff   28672 ----- SmFixed
> --2633:1:aspacem    3: file 00000a8000-00000acfff   20480 rw--- d=0x00c 
> i=6174178 o=622592  (1)
> --2633:1:aspacem    4: anon 00000ad000-00000b1fff   20480 rw---
> --2633:1:aspacem    5: RSVN 00000b2000-0003ffffff     63m ----- SmFixed
> --2633:1:aspacem    6: file 0004000000-0004008fff   36864 r-xT- d=0x00c 
> i=6160505 o=0       (2)
> --2633:1:aspacem    7: anon 0004009000-000400afff    8192 rw---
> --2633:1:aspacem    8:      000400b000-000400ffff   20480
> --2633:1:aspacem    9: file 0004010000-0004011fff    8192 rw--- d=0x00c 
> i=6160505 o=32768   (2)
> --2633:1:aspacem   10: anon 0004012000-0004012fff    4096 rwx--
> --2633:1:aspacem   11: RSVN 0004013000-0004811fff 8384512 ----- SmLower
> --2633:1:aspacem   12: file 0004812000-0004812fff    4096 r-x-- d=0x00c 
> i=6948052 o=0       (4)
> --2633:1:aspacem   13: anon 0004813000-0004819fff   28672 -----
> --2633:1:aspacem   14: file 000481a000-000481afff    4096 rw--- d=0x00c 
> i=6948052 o=0       (4)
> --2633:1:aspacem   15: file 000481b000-0004827fff   53248 r-x-- d=0x00c 
> i=6948058 o=0       (5)
> --2633:1:aspacem   16: anon 0004828000-000482efff   28672 -----
> --2633:1:aspacem   17: file 000482f000-000482ffff    4096 rw--- d=0x00c 
> i=6948058 o=49152   (5)
> --2633:1:aspacem   18: file 0004830000-0004832fff   12288 r-x-- d=0x00c 
> i=6160501 o=0       (6)
> --2633:1:aspacem   19: anon 0004833000-0004839fff   28672 -----
> --2633:1:aspacem   20: file 000483a000-000483bfff    8192 rw--- d=0x00c 
> i=6160501 o=8192    (6)
> --2633:1:aspacem   21: file 000483c000-0004845fff   40960 r-x-- d=0x00c 
> i=6160503 o=0       (7)
> --2633:1:aspacem   22: anon 0004846000-000484cfff   28672 -----
> --2633:1:aspacem   23: file 000484d000-000484dfff    4096 rw--- d=0x00c 
> i=6160503 o=36864   (7)
> --2633:1:aspacem   24: file 000484e000-00048d5fff  557056 r-x-- d=0x00c 
> i=6160509 o=0       (8)
> --2633:1:aspacem   25: anon 00048d6000-00048dcfff   28672 -----
> --2633:1:aspacem   26: file 00048dd000-00048defff    8192 rw--- d=0x00c 
> i=6160509 o=552960  (8)
> --2633:1:aspacem   27: anon 00048df000-00048e3fff   20480 rw---
> --2633:1:aspacem   28:      00048e4000-0037ffffff    823m
> --2633:1:aspacem   29: FILE 0038000000-0038057fff  360448 r-x-- d=0x00c 
> i=6947992 o=0       (0)
> --2633:1:aspacem   30: file 0038058000-0038058fff    4096 r-x-- d=0x00c 
> i=6947992 o=360448  (0)
> --2633:1:aspacem   31: FILE 0038059000-00383cffff 3633152 r-x-- d=0x00c 
> i=6947992 o=364544  (0)
> --2633:1:aspacem   32: FILE 00383d0000-00383d4fff   20480 rw--- d=0x00c 
> i=6947992 o=3997696 (0)
> --2633:1:aspacem   33: ANON 00383d5000-0039500fff     17m rw---
> --2633:1:aspacem   34:      0039501000-006159dfff    640m
> --2633:1:aspacem   35: RSVN 006159e000-006159efff    4096 ----- SmFixed
> --2633:1:aspacem   36: ANON 006159f000-0062139fff     11m rwx--
> --2633:1:aspacem   37:      006213a000-006213bfff    8192
> --2633:1:aspacem   38: FILE 006213c000-006213cfff    4096 rw--- d=0x00e 
> i=2198    o=0       (3)
> --2633:1:aspacem   39: ANON 006213d000-0062164fff  163840 rwx--
> --2633:1:aspacem   40:      0062165000-0062219fff  741376
> --2633:1:aspacem   41: ANON 006221a000-0062319fff 1048576 rwx--
> --2633:1:aspacem   42: ANON 006231a000-006231bfff    8192 -----
> --2633:1:aspacem   43: ANON 006231c000-006241bfff 1048576 rwx--
> --2633:1:aspacem   44: ANON 006241c000-006241dfff    8192 -----
> --2633:1:aspacem   45:      006241e000-006250efff  987136
> --2633:1:aspacem   46: ANON 006250f000-006274dfff 2355200 rwx--
> --2633:1:aspacem   47:      006274e000-00628f7fff 1744896
> --2633:1:aspacem   48: ANON 00628f8000-0064fa6fff     38m rwx--
> --2633:1:aspacem   49:      0064fa7000-00bd33cfff   1411m
> --2633:1:aspacem   50: RSVN 00bd33d000-00bdb3afff 8380416 ----- SmUpper
> --2633:1:aspacem   51: anon 00bdb3b000-00bdb3cfff    8192 rw---
> --2633:1:aspacem   52:      00bdb3d000-00beb1bfff     15m
> --2633:1:aspacem   53: ANON 00beb1c000-00beb3cfff  135168 rw---
> --2633:1:aspacem   54: RSVN 00beb3d000-00fffeffff   1044m ----- SmFixed
> --2633:1:aspacem   55: anon 00ffff0000-00ffff0fff    4096 r-x--
> --2633:1:aspacem   56: RSVN 00ffff1000-00ffffffff   61440 ----- SmFixed
> --2633:1:aspacem  >>>
> ==2633==
> ==2633== HEAP SUMMARY:
> ==2633==     in use at exit: 0 bytes in 0 blocks
> ==2633==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==2633==
> ==2633== All heap blocks were freed -- no leaks are possible
> ==2633==
> ==2633== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> ==2633== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> --2633:1:gdbsrv   VG core calling VG_(gdbserver_exit) tid 1 will exit
> --2633:1:gdbsrv   not connected
> --2633:1:gdbsrv   remote_finish (reason orderly_finish) 1030 -1
> --2633:1:gdbsrv   2633 (creator 2633) maybe unlinking
>      /tmp/vgdb-pipe-from-vgdb-to-2633-by-root-on-???
>      /tmp/vgdb-pipe-to-vgdb-from-2633-by-root-on-???
>      /tmp/vgdb-pipe-shared-mem-vgdb-2633-by-root-on-???
> --2633:1:core_os  VG_(terminate_NORETURN)(tid=1)
> Supervisor has crashed at Thu Jan  1 08:10:47 EST 1970, exit code 255
> 
> 

Re: [Valgrind-users] Problem running even simple programs

[Mikhail B. <mik...@de...>]

On 12/04/2014 12:44 AM, Philippe Waroquiers wrote:
> Then I might have missed something in the mail exchanges.
>
> Your initial mail said that the bug is valgrind fails to find
> problems even in simple applications.
> The example shown was with /bin/true. This was reporting 'invalid read
> errors' originating from ulibc loader.
> This I guess can be fixed by having a ulibc.supp file.
>
> So, what is the segfault in a bigger application ?
>
> Philippe
>
>

The bigger application starts from valgrind with verbose debugging.

==2633== Command: ./nexus ./supervisor ./powerup-launcher
==2633==
--2633-- Valgrind options:
--2633--    -v
--2633--    -v
--2633--    -v
--2633--    -d
--2633--    -d
--2633--    -d
--2633--    --run-libc-freeres=no
--2633--    --suppressions=/bin/mbaikov/uclibc.supp
--2633--    --trace-children=yes
--2633--    --workaround-gcc296-bugs=yes

And the crash... I'm sorry it's not a segfault. It's a crash.
One of the strange things is that inspite of --run-libc-freeres set no 
in the log appears
/bin/sh: symbol '__libc_freeres': can't resolve symbol and the rest... I 
have no idea what exactly to show

==2633== Adding active redirection:
--2633--     new: 0x048965d0 (valloc              ) R-> (1012.0) 
0x0481ea98 valloc
--2633:2:transtab   discard_translations(0x4896734, 1) req by 
redir_new_DebugInfo(from_addr)
--2633:2:transtab                       FAST, ec = 44
--2633:2:transtab   discard_translations(0x481ea00, 1) req by 
redir_new_DebugInfo(to_addr)
--2633:2:transtab                       FAST, ec = 61
==2633== Adding active redirection:
--2633--     new: 0x04896734 (posix_memalign      ) R-> (1016.0) 
0x0481ea00 posix_memalign

/bin/sh: symbol '__libc_freeres': can't resolve symbol
--2633:1:syswrap- thread_wrapper(tid=1): exit, schedreturncode 
VgSrc_ExitThread
--2633:1:syswrap- run_a_thread_NORETURN(tid=1): post-thread_wrapper
--2633:1:syswrap- run_a_thread_NORETURN(tid=1): last one standing
--2633:1:main     entering VG_(shutdown_actions_NORETURN)
--2633:1:aspacem  <<< SHOW_SEGMENTS: Memory layout at client shutdown 
(57 segments, 9 segnames)
--2633:1:aspacem  ( 0) 
/bin/mbaikov/valgrind_arm/lib/valgrind/memcheck-arm-linux
--2633:1:aspacem  ( 1) /bin/bash
--2633:1:aspacem  ( 2) /lib/ld-uClibc-0.9.32.1.so
--2633:1:aspacem  ( 3) /tmp/vgdb-pipe-shared-mem-vgdb-2633-by-root-on-???
--2633:1:aspacem  ( 4) 
/bin/mbaikov/valgrind_arm/lib/valgrind/vgpreload_core-arm-linux.so
--2633:1:aspacem  ( 5) 
/bin/mbaikov/valgrind_arm/lib/valgrind/vgpreload_memcheck-arm-linux.so
--2633:1:aspacem  ( 6) /lib/libdl-0.9.32.1.so
--2633:1:aspacem  ( 7) /lib/libgcc_s.so.1
--2633:1:aspacem  ( 8) /lib/libuClibc-0.9.32.1.so
--2633:1:aspacem    0: RSVN 0000000000-0000007fff   32768 ----- SmFixed
--2633:1:aspacem    1: file 0000008000-00000a0fff  626688 r-x-- d=0x00c 
i=6174178 o=0       (1)
--2633:1:aspacem    2: RSVN 00000a1000-00000a7fff   28672 ----- SmFixed
--2633:1:aspacem    3: file 00000a8000-00000acfff   20480 rw--- d=0x00c 
i=6174178 o=622592  (1)
--2633:1:aspacem    4: anon 00000ad000-00000b1fff   20480 rw---
--2633:1:aspacem    5: RSVN 00000b2000-0003ffffff     63m ----- SmFixed
--2633:1:aspacem    6: file 0004000000-0004008fff   36864 r-xT- d=0x00c 
i=6160505 o=0       (2)
--2633:1:aspacem    7: anon 0004009000-000400afff    8192 rw---
--2633:1:aspacem    8:      000400b000-000400ffff   20480
--2633:1:aspacem    9: file 0004010000-0004011fff    8192 rw--- d=0x00c 
i=6160505 o=32768   (2)
--2633:1:aspacem   10: anon 0004012000-0004012fff    4096 rwx--
--2633:1:aspacem   11: RSVN 0004013000-0004811fff 8384512 ----- SmLower
--2633:1:aspacem   12: file 0004812000-0004812fff    4096 r-x-- d=0x00c 
i=6948052 o=0       (4)
--2633:1:aspacem   13: anon 0004813000-0004819fff   28672 -----
--2633:1:aspacem   14: file 000481a000-000481afff    4096 rw--- d=0x00c 
i=6948052 o=0       (4)
--2633:1:aspacem   15: file 000481b000-0004827fff   53248 r-x-- d=0x00c 
i=6948058 o=0       (5)
--2633:1:aspacem   16: anon 0004828000-000482efff   28672 -----
--2633:1:aspacem   17: file 000482f000-000482ffff    4096 rw--- d=0x00c 
i=6948058 o=49152   (5)
--2633:1:aspacem   18: file 0004830000-0004832fff   12288 r-x-- d=0x00c 
i=6160501 o=0       (6)
--2633:1:aspacem   19: anon 0004833000-0004839fff   28672 -----
--2633:1:aspacem   20: file 000483a000-000483bfff    8192 rw--- d=0x00c 
i=6160501 o=8192    (6)
--2633:1:aspacem   21: file 000483c000-0004845fff   40960 r-x-- d=0x00c 
i=6160503 o=0       (7)
--2633:1:aspacem   22: anon 0004846000-000484cfff   28672 -----
--2633:1:aspacem   23: file 000484d000-000484dfff    4096 rw--- d=0x00c 
i=6160503 o=36864   (7)
--2633:1:aspacem   24: file 000484e000-00048d5fff  557056 r-x-- d=0x00c 
i=6160509 o=0       (8)
--2633:1:aspacem   25: anon 00048d6000-00048dcfff   28672 -----
--2633:1:aspacem   26: file 00048dd000-00048defff    8192 rw--- d=0x00c 
i=6160509 o=552960  (8)
--2633:1:aspacem   27: anon 00048df000-00048e3fff   20480 rw---
--2633:1:aspacem   28:      00048e4000-0037ffffff    823m
--2633:1:aspacem   29: FILE 0038000000-0038057fff  360448 r-x-- d=0x00c 
i=6947992 o=0       (0)
--2633:1:aspacem   30: file 0038058000-0038058fff    4096 r-x-- d=0x00c 
i=6947992 o=360448  (0)
--2633:1:aspacem   31: FILE 0038059000-00383cffff 3633152 r-x-- d=0x00c 
i=6947992 o=364544  (0)
--2633:1:aspacem   32: FILE 00383d0000-00383d4fff   20480 rw--- d=0x00c 
i=6947992 o=3997696 (0)
--2633:1:aspacem   33: ANON 00383d5000-0039500fff     17m rw---
--2633:1:aspacem   34:      0039501000-006159dfff    640m
--2633:1:aspacem   35: RSVN 006159e000-006159efff    4096 ----- SmFixed
--2633:1:aspacem   36: ANON 006159f000-0062139fff     11m rwx--
--2633:1:aspacem   37:      006213a000-006213bfff    8192
--2633:1:aspacem   38: FILE 006213c000-006213cfff    4096 rw--- d=0x00e 
i=2198    o=0       (3)
--2633:1:aspacem   39: ANON 006213d000-0062164fff  163840 rwx--
--2633:1:aspacem   40:      0062165000-0062219fff  741376
--2633:1:aspacem   41: ANON 006221a000-0062319fff 1048576 rwx--
--2633:1:aspacem   42: ANON 006231a000-006231bfff    8192 -----
--2633:1:aspacem   43: ANON 006231c000-006241bfff 1048576 rwx--
--2633:1:aspacem   44: ANON 006241c000-006241dfff    8192 -----
--2633:1:aspacem   45:      006241e000-006250efff  987136
--2633:1:aspacem   46: ANON 006250f000-006274dfff 2355200 rwx--
--2633:1:aspacem   47:      006274e000-00628f7fff 1744896
--2633:1:aspacem   48: ANON 00628f8000-0064fa6fff     38m rwx--
--2633:1:aspacem   49:      0064fa7000-00bd33cfff   1411m
--2633:1:aspacem   50: RSVN 00bd33d000-00bdb3afff 8380416 ----- SmUpper
--2633:1:aspacem   51: anon 00bdb3b000-00bdb3cfff    8192 rw---
--2633:1:aspacem   52:      00bdb3d000-00beb1bfff     15m
--2633:1:aspacem   53: ANON 00beb1c000-00beb3cfff  135168 rw---
--2633:1:aspacem   54: RSVN 00beb3d000-00fffeffff   1044m ----- SmFixed
--2633:1:aspacem   55: anon 00ffff0000-00ffff0fff    4096 r-x--
--2633:1:aspacem   56: RSVN 00ffff1000-00ffffffff   61440 ----- SmFixed
--2633:1:aspacem  >>>
==2633==
==2633== HEAP SUMMARY:
==2633==     in use at exit: 0 bytes in 0 blocks
==2633==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2633==
==2633== All heap blocks were freed -- no leaks are possible
==2633==
==2633== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==2633== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
--2633:1:gdbsrv   VG core calling VG_(gdbserver_exit) tid 1 will exit
--2633:1:gdbsrv   not connected
--2633:1:gdbsrv   remote_finish (reason orderly_finish) 1030 -1
--2633:1:gdbsrv   2633 (creator 2633) maybe unlinking
     /tmp/vgdb-pipe-from-vgdb-to-2633-by-root-on-???
     /tmp/vgdb-pipe-to-vgdb-from-2633-by-root-on-???
     /tmp/vgdb-pipe-shared-mem-vgdb-2633-by-root-on-???
--2633:1:core_os  VG_(terminate_NORETURN)(tid=1)
Supervisor has crashed at Thu Jan  1 08:10:47 EST 1970, exit code 255

Re: [Valgrind-users] Problem running even simple programs

[Philippe W. <phi...@sk...>]

On Wed, 2014-12-03 at 19:51 +0300, Mikhail Baikov wrote:

> 
> The main problem for me is not in basic applications. The problem is 
> that the application that I want to test works fine without valgrind but 
> segfaults when I try to run it in valgrind.
> 
Then I might have missed something in the mail exchanges.

Your initial mail said that the bug is valgrind fails to find
problems even in simple applications.
The example shown was with /bin/true. This was reporting 'invalid read
errors' originating from ulibc loader.
This I guess can be fixed by having a ulibc.supp file.

So, what is the segfault in a bigger application ?

Philippe

Re: [Valgrind-users] Problem running even simple programs

[Mikhail B. <mik...@de...>]

> On Thu, 2014-11-27 at 23:06 +0300, Mikhail Baikov wrote:
>
>> ==1654== Invalid read of size 4
>> ==1654==    at 0x489B248: __uClibc_main (in /lib/libuClibc-0.9.32.1.so)
>> ==1654==  Address 0xbdd74b44 is on thread 1's stack
>> ==1654==  20 bytes below stack pointer
>> ==1654==
>> I also have
>> # valgrind -v -v -v -d -d -d --trace-redir=yes /bin/true
>> log but it's really big to attach it here.
>>
>> And i really can't understand where is the problem because I tried to
>> build trunk valgring (which fails with the same errors), tried 3.10.0
>> with patches from buildroot with the same result.
>>
>> And now I don't know where to dig.
> A possible cause of the above problem is that valgrind does
> not recognise the name of the uClibc dynamic loader.
> There is some code that handles specially the dynamic loader.
> See coregrind/m_redir.c line 1363 for the expected names on arm
> or some similar names in include/pub_tool_redir.h
In include/pub_tool_redir.h there is a
#  define  VG_Z_LIBC_SONAME  libcZdsoZa              // libc.so*
that corresponds with what I have in my /lib directory
ls -la /lib/libc.so.0
lrwxrwxrwx    1 root     root            21 Nov 18  2014 /lib/libc.so.0 
-> libuClibc-0.9.32.1.so
# readelf -a /lib/libuClibc-0.9.32.1.so | grep soname
  0x0000000e (SONAME)                     Library soname: [libc.so.0]

In coregrind/m_redir.c there are two ld-linux.so.3 and 
ld-linux-armhf.so.3 loader names. If I add ld-uClibc.so.0 loader, 
rebuild valgrind and try to run any binary i get this kind of error

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strcmp
valgrind:  in an object with soname matching:   ld-uClibc.so.0
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-uClibc.so.0

> It might also just be "normal" errors, that are suppressed
> by the standard valgrind suppression files, but that in your
> case are not matching due to the uClibc use ?
> See e.g. default.supp (generated from various *.supp files).
> I see no uclibc specific files there, which makes me believe
> valgrind is not (yet) fine tuned to be used with uclibc.
>
> For what concerns the error message
>     /bin/true: can't resolve symbol '__libc_freeres'
> again that is probably caused by uClib, which I guess does not
> provide __libc_freeres
> To avoid this msg, you can use --run-libc-freeres=no
I've taken uclibc.supp from buildroot and added suppression option with 
it but it hasn't helped.
> Note however that I see in coregrind/vg_preloaded.c (line 59)
> that the call should not be done when valgrind is "compiled"
> for UCLIBC.
> So, might be good to verify how e.g. vg_preloaded.c was
> compiled.
gcc -v of the toolchain i've been given is
./arm-linux-uclibcgnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=./arm-linux-uclibcgnueabi-gcc
COLLECT_LTO_WRAPPER=/home/mikhail/zodiac/toolchain/humax-fxpp/opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/bin/../libexec/gcc/arm-linux-uclibcgnueabi/4.5.4/lto-wrapper
Target: arm-linux-uclibcgnueabi
Configured with: ../gcc-4.5.4/configure --target=arm-linux-uclibcgnueabi 
--enable-multilib 
--prefix=/usr/src/redhat/BUILD/build-toolchain//opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp 
--with-local-prefix=/usr/src/redhat/BUILD/build-toolchain//opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/arm-linux-uclibcgnueabi/sys-root 
--with-sysroot=/usr/src/redhat/BUILD/build-toolchain//opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/arm-linux-uclibcgnueabi/sys-root 
--enable-threads=posix --enable-long-long --enable-c99 
--enable-__cxa_atexit --with-gmp=/usr/src/redhat/BUILD/prereq 
--with-mpfr=/usr/src/redhat/BUILD/prereq 
--with-mpc=/usr/src/redhat/BUILD/prereq 
--with-libelf=/usr/src/redhat/BUILD/prereq --disable-nls 
--enable-symvers=gnu --enable-languages=c,c++ --enable-target-optspace 
--with-pkgversion='Broadcom stbgcc-4.5.4-2.7_uclibc_ssp' 
--with-host-libstdcxx='-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' 
--with-float=soft
Thread model: posix
gcc version 4.5.4 (Broadcom stbgcc-4.5.4-2.7_uclibc_ssp)

The single line where I see something about vg_preloaded.c is
  /home/mikhail/zodiac/toolchain/humax-fxpp/opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/bin/../libexec/gcc/arm-linux-uclibcgnueabi/4.5.4/cc1 -quiet -v -I. -I.. -I.. -I../include -I../VEX/pub -I../VEX/pub -I../coregrind -iprefix /home/mikhail/zodiac/toolchain/humax-fxpp/opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.5.4/ -isysroot /home/mikhail/zodiac/toolchain/humax-fxpp/opt/toolchains/stbgcc-4.5.4-2.7_uclibc_ssp/bin/../arm-linux-uclibcgnueabi/sys-root -MD vgpreload_core_arm_linux_so-vg_preloaded.d -MF .deps/vgpreload_core_arm_linux_so-vg_preloaded.Tpo -MP -MT vgpreload_core_arm_linux_so-vg_preloaded.o -DHAVE_CONFIG_H -DVGA_arm=1 -DVGO_linux=1 -DVGP_arm_linux=1 -DVGPV_arm_linux_vanilla=1 -DVG_LIBDIR="/bin/mbaikov/valgrind_arm/lib/valgrind" -DVG_PLATFORM="arm-linux" vg_preloaded.c -quiet -dumpbase vg_preloaded.c -marm -mcpu=cortex-a8 -marm -mabi=aapcs-linux -msoft-float -muclibc -auxbase-strip vgpreload_core_arm_linux_so-vg_preloaded.o -g -g -O2 -O -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -Wno-long-long -Wall -Wno-endif-labels -Wno-multichar -Wno-switch -Wno-unknown-pragmas -Wsystem-headers -Wno-unused-parameter -Wno-missing-field-initializers -version -fpic -fno-builtin -fPIC -fmerge-constants -funswitch-loops -fno-jump-tables -fno-strict-aliasing -fno-omit-frame-pointer -fno-stack-protector -o /tmp/cchpJUN3.s
and I can't get whether it is compiled for uClibc or not.
> Philippe
>
>

The main problem for me is not in basic applications. The problem is 
that the application that I want to test works fine without valgrind but 
segfaults when I try to run it in valgrind.