valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] memory barriers support

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

On Tue, 2014-08-19 at 14:23 +0200, Jan Včelák wrote:
> Compile the server. We hit the problem with the following configuration:
> 
> $ autoreconf -fi
> $ export CC=gcc
> $ export CFLAGS="-O0 -g -j4"
> $ ./configure --enable-recvmmsg=no \
>               --enable-lto=no \
>               --disable-fastparser \
>               --disable-shared \
>               --enable-static
If you link with a static malloc library, you have to use
--soname-synonyms=somalloc=NONE
to have the malloc/free interceptions needed for memcheck, helgrind,
drd, ... to work properly.

Note also that these tools have a very limited functionality
and/or might not work properly if your application is completely
statically linked.
So ldd on your program should much better show at least one shared lib.

Philippe

Re: [Valgrind-users] Found A Spelling Mistake in faq page

[Florian K. <fl...@ei...>]

On 19.08.2014 04:37, Shaopeng Chen wrote:
> Hey all,
>       I found a spelling mistake in the web page of FAQ(
> http://valgrind.org/docs/manual/faq.html#faq.pronounce).
> 
> *1.1.**How do you pronounce "Valgrind"?*
>>
>> The "Val" as in the world "value". The "grind" is pronounced with a short
>> 'i' -- ie. "grinned" (rhymes with "tinned") rather than "grined" (rhymes
>> with "find").
>>
>> Don't feel bad: almost everyone gets it wrong at first.
>>
> 
>       The word "*world*" in first sentence should be ,I think ,"*word*".
> 

That's right. I've fixed this.

Thanks,
	Florian

Re: [Valgrind-users] memory barriers support

[Roland M. <rol...@nr...>]

On Tue, Aug 19, 2014 at 4:13 PM, Alexander Potapenko <gl...@go...> wrote:
> On Tue, Aug 19, 2014 at 5:59 PM, Milian Wolff <ma...@mi...> wrote:
>> On Tuesday 19 August 2014 14:23:26 Jan Včelák wrote:
>>> OK. Then it is likely that there is a bug in our software.
>>
>> <snip>
>>
>>> I run the test case several times without Valgrind with address sanitizer.
>>> But I didn't hit the problem.
>>
>> If you think it's a race, then the address sanitizer won't find it, I guess.
>> Rather, try the thread sanitizer.
>>
>> http://clang.llvm.org/docs/ThreadSanitizer.html
>
> ThreadSanitizer won't comprehend the fence instructions inserted by urcu.
> I believe even Helgrind won't, because these instructions do not imply
> any happens-before relation.

Is there any opensource or commercial tool which might help in such
situations (e.g. problems with memory barriers) ?

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) rol...@nr...
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Re: [Valgrind-users] memory barriers support

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

On Tuesday 19 August 2014 14:23:26 Jan Včelák wrote:
> OK. Then it is likely that there is a bug in our software.

<snip>

> I run the test case several times without Valgrind with address sanitizer.
> But I didn't hit the problem.

If you think it's a race, then the address sanitizer won't find it, I guess. 
Rather, try the thread sanitizer.

http://clang.llvm.org/docs/ThreadSanitizer.html

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

Re: [Valgrind-users] memory barriers support

[Alexander P. <gl...@go...>]

On Tue, Aug 19, 2014 at 5:59 PM, Milian Wolff <ma...@mi...> wrote:
> On Tuesday 19 August 2014 14:23:26 Jan Včelák wrote:
>> OK. Then it is likely that there is a bug in our software.
>
> <snip>
>
>> I run the test case several times without Valgrind with address sanitizer.
>> But I didn't hit the problem.
>
> If you think it's a race, then the address sanitizer won't find it, I guess.
> Rather, try the thread sanitizer.
>
> http://clang.llvm.org/docs/ThreadSanitizer.html
>
> Cheers
ThreadSanitizer won't comprehend the fence instructions inserted by urcu.
I believe even Helgrind won't, because these instructions do not imply
any happens-before relation.

Re: [Valgrind-users] memory barriers support

[Jan V. <jan...@ni...>]

> If you think it's a race, then the address sanitizer won't find it, I guess.
> Rather, try the thread sanitizer.
> 
> http://clang.llvm.org/docs/ThreadSanitizer.html

Unfortunatelly, thread sanitizer does not support synchronization using memory 
barriers. The same with Helgrind.

Re: [Valgrind-users] memory barriers support

[Jan V. <jan...@ni...>]

Dne Po 18. srpna 2014 10:25:42, Eliot Moss napsal(a):
> On 8/18/2014 9:09 AM, Jan Včelák wrote:
> > I'm not rejecting that there is a problem in our code, but I want to make
> > sure that we are chasing a real bug.
> 
> You might want to verify that valgrind and your code have the same
> notion of what the malloc/free routines are, etc., i.e., that valgrind
> is able to hook into all allocation and freeing calls your application
> uses.

We do not do anything special about malloc/free.

I believe the problem originates in some kind of race.

Jan

Re: [Valgrind-users] memory barriers support

[Jan V. <jan...@ni...>]

OK. Then it is likely that there is a bug in our software.

As for the tests - it is a bit complicated. But if you are willing to spend 
some time on it, we would be very happy. :-)

Get latest Knot DNS from git:

$ git clone https://gitlab.labs.nic.cz/labs/knot.git

Compile the server. We hit the problem with the following configuration:

$ autoreconf -fi
$ export CC=gcc
$ export CFLAGS="-O0 -g -j4"
$ ./configure --enable-recvmmsg=no \
              --enable-lto=no \
              --disable-fastparser \
              --disable-shared \
              --enable-static
$ make
$ make check

Setup environment for functional tests. You will need Python >= 3.3, BIND 9, 
lsof, and a few Python modules, which can be installed using pip:

$ cd tests-extra
$ pip install -r requirements.txt

To run the occasionally failing test, execute:

$ ./runtests.py ixfr/knot_bind

The test establishes Knot DNS as a master server, BIND as a slave and performs 
simple zone transfer.

Our testing machine is 4-core Intel Xeon machine, with 64-bit Linux (Ubuntu 
13.10. and 3.11.0-18-generic kernel).

I run the test case several times without Valgrind with address sanitizer. But 
I didn't hit the problem.

Jan

Dne Po 18. srpna 2014 18:01:15, Alexander Potapenko napsal(a):
> Valgrind should correctly translate the memory fence instructions into
> platform-specific memory fences that are at least not weaker,
> otherwise every synchronization algorithm would've been broken under
> Valgrind.
> On amd64 Valgrind creates an IRStmt_MBE(Imbe_Fence) for
> sfence/lfence/mfcence (see VEX/priv/guest_amd64_toIR.c), which is
> later translated to mfence when executing the code (see
> VEX/priv/host_amd64_isel.c).
> 
> (On the related note, I wanted to try Knot DNS under a couple of
> tools, but failed to find any documentation for running the tests)
> 
> On Mon, Aug 18, 2014 at 5:09 PM, Jan Včelák <jan...@ni...> wrote:
> > Hello list,
> > 
> > we develop an authoritative DNS server called Knot DNS and we use the
> > userspace-rcu library [1] for synchronization. The library implements the
> > synchronization by inserting appropriate sfence/lfence/mfcence
> > instructions
> > and some reference counting around.
> > 
> > Currently, we are trying to track down an invalid read reported by
> > Valgrind. The problem appears very rarely and it's quite difficult to
> > reproduce. Valgrind claims that a previously freed memory is being read.
> > However we quite sure that the synchronization is correct and that this
> > problem should not happen.
> > 
> > Does Valgrind support the mentioned memory barrier instructions?
> > 
> > I'm not rejecting that there is a problem in our code, but I want to make
> > sure that we are chasing a real bug.
> > 
> > Thanks and regards
> > 
> > Jan
> > 
> > [1] http://lttng.org/urcu

[Valgrind-users] Found A Spelling Mistake in faq page

[Shaopeng C. <ls...@gm...>]

Hey all,
      I found a spelling mistake in the web page of FAQ(
http://valgrind.org/docs/manual/faq.html#faq.pronounce).

*1.1.**How do you pronounce "Valgrind"?*
>
> The "Val" as in the world "value". The "grind" is pronounced with a short
> 'i' -- ie. "grinned" (rhymes with "tinned") rather than "grined" (rhymes
> with "find").
>
> Don't feel bad: almost everyone gets it wrong at first.
>

      The word "*world*" in first sentence should be ,I think ,"*word*".

> Best regards,
lessmoon

[Valgrind-users] track_new_mem_stack vs. track_new_mam_stack_signal

[janjust <tja...@un...>]

Hey guys,
   I'm a bit confused over the functionalities of track_new_mem_stack vs
new_mem_stack_signal.
When is the stack_signal called? I looked at pub_tool_tooliface.h but I'm
still confused.

I understand that the new_mem_stack is called when the SP changes, but what
I don't understand is 1) why is it called twice (llok at my trace [2]), and
2) how do I use this info to find the top of the stack including the size of
the memory reserved by the local variables that follow the function call?

For example I have a toy client [1], and a resulting trace given in [2]:
What I would like to find out is the top of the stack at any given time and
record when such change occurs, that is, the very lowest address accessed by
the stack (ignoring threads for right now).
I thought the address given by new_mem_stack is it, but...as can be seen
from the trace, the address returned with new_mem_stack points to he
beginning of the called function, not necessarily to the stack memory
reserved or accessed by individual variables/structures?

So my question is, what am I missing / not understanding here? How do I
capture the changing stack including the memory reserved by the local
variables?

Currently, within the tool, I check every memory read/write against the
accessed address and if it's higher than my global area or higher than my
tracked dynamic / mmaped area, I treat it as a stack access.
Any ideas?

the trace line format is similar to lackey with a few extensions:

store/load, virtual address, access size, thread_id, application segment
(stack, code, global, heap, mmap etc.), function name, scope, variable name
including the accessed offset.

[1] client code
  1 #include <stdio.h>
  2 #include <stdlib.h>
  |
  6 void doo(void){
  7   char doo_s[100];
  8
  9   doo_s[99] = 0;
 10   return;
 11 }
 12
 13 void boo(void){
 14   char boo_s[10];
 15
 16   boo_s[9] = 0;
 17
 18   return;
 19 }
 20
 21 void foo(void){
 22   long foo_v;
 23
 24   foo_v = 123;
 25
 26   return;
 27 }
 28
 29 int main(void){
 30   
 31
 32   foo();
 33   boo();
 34   doo();
 35
 36   
 37
 38   return 0;
 39 }

[2] trace when executing the client
  1 X START 0:1348 at 0
  2 X THREAD_CREATE 0:1
  3 S ffeffd408 8 1 S main
  4 L ffeffd408 8 1 S main
  5 new_stack @addr: ffeffd3b8, len: 8
  6 new_stack @addr: ffeffd3b0, len: 8
  7 S ffeffd3b8 8 1 S main
  8 S ffeffd3b0 8 1 S foo
  9 S ffeffd3a8 8 1 S foo LV foo_v
 10 die_stack @addr: ffeffd3b0, len: 8
 11 die_stack @addr: ffeffd3b8, len: 8
 12 L ffeffd3b0 8 1 S foo
 13 L ffeffd3b8 8 1 S foo
 14 new_stack @addr: ffeffd3b8, len: 8
 15 new_stack @addr: ffeffd3b0, len: 8
 16 S ffeffd3b8 8 1 S main
 17 S ffeffd3b0 8 1 S boo
 18 S ffeffd3a9 1 1 S boo LS boo_s[9]
 19 die_stack @addr: ffeffd3b0, len: 8
 20 die_stack @addr: ffeffd3b8, len: 8
 21 L ffeffd3b0 8 1 S boo
 22 L ffeffd3b8 8 1 S boo
 23 new_stack @addr: ffeffd3b8, len: 8
 24 new_stack @addr: ffeffd3b0, len: 8
 25 S ffeffd3b8 8 1 S main
 26 S ffeffd3b0 8 1 S doo
 27 S ffeffd3a3 1 1 S doo LS doo_s[99]
 28 die_stack @addr: ffeffd3b0, len: 8
 29 die_stack @addr: ffeffd3b8, len: 8
 30 L ffeffd3b0 8 1 S doo LS doo_s[16]
 31 L ffeffd3b8 8 1 S doo LS doo_s[24]
 32 S ffeffd3d0 8 1 S main LS _zzq_args[0]
 33 S ffeffd3d8 8 1 S main LS _zzq_args[1]
 34 S ffeffd3e0 8 1 S main LS _zzq_args[2]
 35 S ffeffd3e8 8 1 S main LS _zzq_args[3]
 36 S ffeffd3f0 8 1 S main LS _zzq_args[4]
 37 S ffeffd3f8 8 1 S main LS _zzq_args[5]
 38 X INST 141791
 39 X END 1348 at 141791





--
View this message in context: http://valgrind.10908.n7.nabble.com/track-new-mem-stack-vs-track-new-mam-stack-signal-tp50932.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] memory barriers support

[Eliot M. <mo...@cs...>]

On 8/18/2014 9:09 AM, Jan Včelák wrote:
> Hello list,
>
> we develop an authoritative DNS server called Knot DNS and we use the
> userspace-rcu library [1] for synchronization. The library implements the
> synchronization by inserting appropriate sfence/lfence/mfcence instructions
> and some reference counting around.
>
> Currently, we are trying to track down an invalid read reported by Valgrind.
> The problem appears very rarely and it's quite difficult to reproduce.
> Valgrind claims that a previously freed memory is being read. However we quite
> sure that the synchronization is correct and that this problem should not
> happen.
>
> Does Valgrind support the mentioned memory barrier instructions?

If it did not *recognize* the instruction, then valgrind would bomb out
with an error message giving the op code byte sequence and saying it did
not recognize it.  A possibility is that it recognizes the instruction
but does not implement it as you expect.  Someone else will need to
answer as to that possibility.

> I'm not rejecting that there is a problem in our code, but I want to make sure
> that we are chasing a real bug.

You might want to verify that valgrind and your code have the same
notion of what the malloc/free routines are, etc., i.e., that valgrind
is able to hook into all allocation and freeing calls your application
uses.

Best wishes -- Eliot Moss

Re: [Valgrind-users] memory barriers support

[Alexander P. <gl...@go...>]

Valgrind should correctly translate the memory fence instructions into
platform-specific memory fences that are at least not weaker,
otherwise every synchronization algorithm would've been broken under
Valgrind.
On amd64 Valgrind creates an IRStmt_MBE(Imbe_Fence) for
sfence/lfence/mfcence (see VEX/priv/guest_amd64_toIR.c), which is
later translated to mfence when executing the code (see
VEX/priv/host_amd64_isel.c).

(On the related note, I wanted to try Knot DNS under a couple of
tools, but failed to find any documentation for running the tests)

On Mon, Aug 18, 2014 at 5:09 PM, Jan Včelák <jan...@ni...> wrote:
> Hello list,
>
> we develop an authoritative DNS server called Knot DNS and we use the
> userspace-rcu library [1] for synchronization. The library implements the
> synchronization by inserting appropriate sfence/lfence/mfcence instructions
> and some reference counting around.
>
> Currently, we are trying to track down an invalid read reported by Valgrind.
> The problem appears very rarely and it's quite difficult to reproduce.
> Valgrind claims that a previously freed memory is being read. However we quite
> sure that the synchronization is correct and that this problem should not
> happen.
>
> Does Valgrind support the mentioned memory barrier instructions?
>
> I'm not rejecting that there is a problem in our code, but I want to make sure
> that we are chasing a real bug.
>
> Thanks and regards
>
> Jan
>
> [1] http://lttng.org/urcu
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



-- 
Alexander Potapenko
Software Engineer
Google Moscow

[Valgrind-users] memory barriers support

[Jan V. <jan...@ni...>]

Hello list,

we develop an authoritative DNS server called Knot DNS and we use the 
userspace-rcu library [1] for synchronization. The library implements the 
synchronization by inserting appropriate sfence/lfence/mfcence instructions 
and some reference counting around.

Currently, we are trying to track down an invalid read reported by Valgrind. 
The problem appears very rarely and it's quite difficult to reproduce. 
Valgrind claims that a previously freed memory is being read. However we quite 
sure that the synchronization is correct and that this problem should not 
happen.

Does Valgrind support the mentioned memory barrier instructions?

I'm not rejecting that there is a problem in our code, but I want to make sure 
that we are chasing a real bug.

Thanks and regards

Jan

[1] http://lttng.org/urcu

Re: [Valgrind-users] Complete precise profiling

[Francis G. <fra...@gm...>]

Le 17 août 2014 11:21, "Howard Chu" <hy...@sy...> a écrit :
>
> Philippe Waroquiers wrote:
> > On Sun, 2014-08-17 at 02:47 -0700, Van Snyder wrote:
> >> On Sun, 2014-08-17 at 09:48 +0200, Julian Seward wrote:
> >>> On 08/16/2014 03:19 AM, Van Snyder wrote:
> >>>> It seems that cachegrind could be extended to do complete precise
> >>>> profiling.
> >>>
> >>> What do you mean by "complete precise profiling"?  Can you clarify?
> >>
> >> Trace execution of every instruction and account for its execution
time,
> >> including the analyses that cachegrind does to model caches.
> >>
> >> Produce two reports, one sorted in decreasing order of the time spent
on
> >> each line of source, and another sorted in decreasing order of the time
> >> spent in each basic block, at last basic blocks as they are discovered
> >> by tracing execution.
> >>
> >> I used such a tool to productive advantage thirty years ago.  It didn't
> >> matter that the cost was eighty times the cost of running the program
on
> >> its own.
> >>
> >> Maybe cachegrind already does this, but the description isn't clear.
> > See cachegrind user manual, indicating e.g.
> >    "... I cache reads (Ir, which equals the number of instructions ..."
> >   http://www.valgrind.org/docs/manual/cg-manual.html#cg-manual.overview
> > For callgrind, see e.g. the description of --cache-sim=<yes|no>
> >
> > What is not clear is how to compute exact execution time from the
> > various stats (Ir, I1mr, Ilmr, Dr, D1mr, ...).
> > (or maybe rather than exact execution time, correct relative execution
> > time of each program piece).
>
> You would need a cycle-accurate machine model, which valgrind is not.

You may be interested into marss86 x86 cycle accurate simulator.

Cheers,

Francis

>
> --
>    -- Howard Chu
>    CTO, Symas Corp.           http://www.symas.com
>    Director, Highland Sun     http://highlandsun.com/hyc/
>    Chief Architect, OpenLDAP  http://www.openldap.org/project/
>
>
------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Complete precise profiling

[Howard C. <hy...@sy...>]

Philippe Waroquiers wrote:
> On Sun, 2014-08-17 at 02:47 -0700, Van Snyder wrote:
>> On Sun, 2014-08-17 at 09:48 +0200, Julian Seward wrote:
>>> On 08/16/2014 03:19 AM, Van Snyder wrote:
>>>> It seems that cachegrind could be extended to do complete precise
>>>> profiling.
>>>
>>> What do you mean by "complete precise profiling"?  Can you clarify?
>>
>> Trace execution of every instruction and account for its execution time,
>> including the analyses that cachegrind does to model caches.
>>
>> Produce two reports, one sorted in decreasing order of the time spent on
>> each line of source, and another sorted in decreasing order of the time
>> spent in each basic block, at last basic blocks as they are discovered
>> by tracing execution.
>>
>> I used such a tool to productive advantage thirty years ago.  It didn't
>> matter that the cost was eighty times the cost of running the program on
>> its own.
>>
>> Maybe cachegrind already does this, but the description isn't clear.
> See cachegrind user manual, indicating e.g.
>    "... I cache reads (Ir, which equals the number of instructions ..."
>   http://www.valgrind.org/docs/manual/cg-manual.html#cg-manual.overview
> For callgrind, see e.g. the description of --cache-sim=<yes|no>
>
> What is not clear is how to compute exact execution time from the
> various stats (Ir, I1mr, Ilmr, Dr, D1mr, ...).
> (or maybe rather than exact execution time, correct relative execution
> time of each program piece).

You would need a cycle-accurate machine model, which valgrind is not.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: [Valgrind-users] Complete precise profiling

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

On Sun, 2014-08-17 at 02:47 -0700, Van Snyder wrote:
> On Sun, 2014-08-17 at 09:48 +0200, Julian Seward wrote:
> > On 08/16/2014 03:19 AM, Van Snyder wrote:
> > > It seems that cachegrind could be extended to do complete precise
> > > profiling.
> > 
> > What do you mean by "complete precise profiling"?  Can you clarify?
> 
> Trace execution of every instruction and account for its execution time,
> including the analyses that cachegrind does to model caches.
> 
> Produce two reports, one sorted in decreasing order of the time spent on
> each line of source, and another sorted in decreasing order of the time
> spent in each basic block, at last basic blocks as they are discovered
> by tracing execution.
> 
> I used such a tool to productive advantage thirty years ago.  It didn't
> matter that the cost was eighty times the cost of running the program on
> its own.
> 
> Maybe cachegrind already does this, but the description isn't clear.
See cachegrind user manual, indicating e.g.
  "... I cache reads (Ir, which equals the number of instructions ..."
 http://www.valgrind.org/docs/manual/cg-manual.html#cg-manual.overview
For callgrind, see e.g. the description of --cache-sim=<yes|no>

What is not clear is how to compute exact execution time from the
various stats (Ir, I1mr, Ilmr, Dr, D1mr, ...).
(or maybe rather than exact execution time, correct relative execution
time of each program piece).

Philippe

Re: [Valgrind-users] Complete precise profiling

[Van S. <van...@jp...>]

On Sun, 2014-08-17 at 09:48 +0200, Julian Seward wrote:
> On 08/16/2014 03:19 AM, Van Snyder wrote:
> > It seems that cachegrind could be extended to do complete precise
> > profiling.
> 
> What do you mean by "complete precise profiling"?  Can you clarify?

Trace execution of every instruction and account for its execution time,
including the analyses that cachegrind does to model caches.

Produce two reports, one sorted in decreasing order of the time spent on
each line of source, and another sorted in decreasing order of the time
spent in each basic block, at last basic blocks as they are discovered
by tracing execution.

I used such a tool to productive advantage thirty years ago.  It didn't
matter that the cost was eighty times the cost of running the program on
its own.

Maybe cachegrind already does this, but the description isn't clear.

Statistical profilers such as gprof put random numbers into a timer, and
analyze where the interrupts occur.  This isn't usually as accurate.

Re: [Valgrind-users] Complete precise profiling

[Julian S. <js...@ac...>]

On 08/16/2014 03:19 AM, Van Snyder wrote:
> It seems that cachegrind could be extended to do complete precise
> profiling.

What do you mean by "complete precise profiling"?  Can you clarify?

J

Re: [Valgrind-users] Complete precise profiling

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

On Fri, 2014-08-15 at 18:19 -0700, Van Snyder wrote:
> It seems that cachegrind could be extended to do complete precise
> profiling.  This would be more accurate than the traditional statistical
> profiling.  Is it feasible?
cachegrind (and callgrind) are not statistical profilers.
They a.o. can count each instruction executed.

Philippe

[Valgrind-users] Complete precise profiling

[Van S. <Van...@jp...>]

It seems that cachegrind could be extended to do complete precise
profiling.  This would be more accurate than the traditional statistical
profiling.  Is it feasible?

I don't care if it's slower than watching paint dry.  I wouldn't be
doing it every day.

Re: [Valgrind-users] VEX : unhandled instruction bytes

[Chris J. <jo...@he...>]

Hi,

On 05/08/14 11:52, Tom Hughes wrote:
> On 05/08/14 10:08, Chris Jones wrote:
>
>> I have an application that is causing valgrind to seg. fault, but runs
>> just fine natively. The seg. fault is below. This is using the SVN trunk
>> build of valgrind as of an hour or so ago (revision 14231).
>>
>> The primary message to me seems to be
>>
>> vex amd64->IR: unhandled instruction bytes: 0xFF 0xFF 0xFF 0xFF 0xFF
>> 0xFF 0xFF 0xFF
>> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
>> vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
>> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
>>
>> http://valgrind.org/docs/manual/faq.html
>>
>> Seems to suggest this could be one of two things; an error in the
>> application (but then it runs fine outside valgrind) or an error in
>> valgrind. Does anyone have any insights into which one this is here ?
>
> Firstly that's not a seg fault.

yes, my mistake. The seg. fault I was referring to was from a test with 
valgrind 3.8.1. Moving to 3.9.x removed this, but I erroneously still 
mentioned it above.

  It's a valgrind error telling you it has
> been asked to execute code that it can't make sense of.

Yep, figured that much.

>
> That's not really surprising given that I'm pretty sure that a string of
> 0xff bytes is not a valid x86 instruction.

Struck me as odd as well.

>
> Fortunately valgrind has already told you exactly where the problem is:
>
>> ==23684== Jump to the invalid address stated on the next line
>> ==23684==    at 0x2F769650: ???
>> ==23684==    by 0xFFEFEFFEF: ???
>> ==23684==    by 0x13E72601: ???
>> ==23684==    by 0x1151A3FF: ???
>> ==23684==    by 0x12E89588: clang::Decl::getASTContext() const (in
>> /afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libCling.so)
>
> So you have jumped to an invalid address at 0x2f769650...
>
>> ==23684==  Address 0x2f769650 is 0 bytes inside a block of size 32 alloc'd
>> ==23684==    at 0x4A07FD5: operator new(unsigned long)
>> (vg_replace_malloc.c:326)
>> ==23684==    by 0x13E725DB: ???
>> ==23684==    by 0x125E3AE5: TClingCallFunc::exec(void*, void*) const (in
>> /afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libCling.so)
>
> ...and that address is in a block of dynamically allocated memory.

Yeah, I guess that was clear, I just didn't focus on them enough.

> Which means that you are presumably dealing with a program that
> generates code on the fly, and you will need to use --smc-check to tell
> valgrind where it should expect the find self modifying code like this.
>
> It defaults to only checking for it on the stack, so you will probably
> need to change it by using --smc-check=all-non-file so that it will
> check the heap as well. That will slow things down a bit but it should
> hopefully solve your problem.

Yes, this sounds very likely. Cling as I said is an interactive compiler 
environment and as such definitely will be doing this. We will try the 
option you suggest.

thanks for the help.

Chris

>
> Tom
>

Re: [Valgrind-users] VEX : unhandled instruction bytes

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

On 05/08/14 10:08, Chris Jones wrote:

> I have an application that is causing valgrind to seg. fault, but runs
> just fine natively. The seg. fault is below. This is using the SVN trunk
> build of valgrind as of an hour or so ago (revision 14231).
>
> The primary message to me seems to be
>
> vex amd64->IR: unhandled instruction bytes: 0xFF 0xFF 0xFF 0xFF 0xFF
> 0xFF 0xFF 0xFF
> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
> vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
>
> http://valgrind.org/docs/manual/faq.html
>
> Seems to suggest this could be one of two things; an error in the
> application (but then it runs fine outside valgrind) or an error in
> valgrind. Does anyone have any insights into which one this is here ?

Firstly that's not a seg fault. It's a valgrind error telling you it has 
been asked to execute code that it can't make sense of.

That's not really surprising given that I'm pretty sure that a string of 
0xff bytes is not a valid x86 instruction.

Fortunately valgrind has already told you exactly where the problem is:

> ==23684== Jump to the invalid address stated on the next line
> ==23684==    at 0x2F769650: ???
> ==23684==    by 0xFFEFEFFEF: ???
> ==23684==    by 0x13E72601: ???
> ==23684==    by 0x1151A3FF: ???
> ==23684==    by 0x12E89588: clang::Decl::getASTContext() const (in
> /afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libCling.so)

So you have jumped to an invalid address at 0x2f769650...

> ==23684==  Address 0x2f769650 is 0 bytes inside a block of size 32 alloc'd
> ==23684==    at 0x4A07FD5: operator new(unsigned long)
> (vg_replace_malloc.c:326)
> ==23684==    by 0x13E725DB: ???
> ==23684==    by 0x125E3AE5: TClingCallFunc::exec(void*, void*) const (in
> /afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libCling.so)

...and that address is in a block of dynamically allocated memory.

Which means that you are presumably dealing with a program that 
generates code on the fly, and you will need to use --smc-check to tell 
valgrind where it should expect the find self modifying code like this.

It defaults to only checking for it on the stack, so you will probably 
need to change it by using --smc-check=all-non-file so that it will 
check the heap as well. That will slow things down a bit but it should 
hopefully solve your problem.

Tom

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

[Valgrind-users] VEX : unhandled instruction bytes

[Chris J. <jo...@he...>]

Hi,

I have an application that is causing valgrind to seg. fault, but runs 
just fine natively. The seg. fault is below. This is using the SVN trunk 
build of valgrind as of an hour or so ago (revision 14231).

The primary message to me seems to be

vex amd64->IR: unhandled instruction bytes: 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0

http://valgrind.org/docs/manual/faq.html

Seems to suggest this could be one of two things; an error in the 
application (but then it runs fine outside valgrind) or an error in 
valgrind. Does anyone have any insights into which one this is here ?

cheers Chris

==23684== Jump to the invalid address stated on the next line
==23684==    at 0x2F769650: ???
==23684==    by 0xFFEFEFFEF: ???
==23684==    by 0x13E72601: ???
==23684==    by 0x1151A3FF: ???
==23684==    by 0x12E89588: clang::Decl::getASTContext() const (in 
/afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libCling.so)
==23684==    by 0xFFEFF047F: ???
==23684==    by 0xFFEFF0197: ???
==23684==    by 0x212E92D91: ???
==23684==  Address 0x2f769650 is 0 bytes inside a block of size 32 alloc'd
==23684==    at 0x4A07FD5: operator new(unsigned long) 
(vg_replace_malloc.c:326)
==23684==    by 0x13E725DB: ???
==23684==    by 0x125E3AE5: TClingCallFunc::exec(void*, void*) const (in 
/afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libCling.so)
==23684==    by 0x125E4E28: 
TClingCallFunc::exec_with_valref_return(void*, cling::Value*) const (in 
/afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libCling.so)
==23684==    by 0x125E7852: long TClingCallFunc::ExecT<long>(void*) (in 
/afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libCling.so)
==23684==    by 0xE98106F: PyROOT::TMethodHolder::CallSafe(void*, bool) 
(in 
/afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libPyROOT.so)
==23684==    by 0xE97EFAC: PyROOT::TMethodHolder::Execute(void*, bool) 
(in 
/afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libPyROOT.so)
==23684==    by 0xE99B1CF: 
PyROOT::TConstructorHolder::operator()(PyROOT::ObjectProxy*, _object*, 
_object*, long, bool) (in 
/afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libPyROOT.so)
==23684==    by 0xE9738E9: PyROOT::(anonymous 
namespace)::mp_call(PyROOT::MethodProxy*, _object*, _object*) (in 
/afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libPyROOT.so)
==23684==    by 0x4C637A2: PyObject_Call (abstract.c:2529)
==23684==    by 0x4CCEC7E: slot_tp_init (typeobject.c:5692)
==23684==    by 0x4CCD7FE: type_call (typeobject.c:745)
==23684==
vex amd64->IR: unhandled instruction bytes: 0xFF 0xFF 0xFF 0xFF 0xFF 
0xFF 0xFF 0xFF
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==23684== Invalid read of size 1
==23684==    at 0x2F76965D: ???
==23684==    by 0xFFEFEFFEF: ???
==23684==    by 0x13E72601: ???
==23684==    by 0x1151A3FF: ???
==23684==    by 0x12E89588: clang::Decl::getASTContext() const (in 
/afs/cern.ch/sw/lcg/releases/ROOT/6.00.02-1c3e2/x86_64-slc6-gcc48-opt/lib/libCling.so)
==23684==    by 0xFFEFF047F: ???
==23684==    by 0xFFEFF0197: ???
==23684==    by 0x212E92D91: ???
==23684==  Address 0x1151a4 is not stack'd, malloc'd or (recently) free'd
==23684==

  *** Break *** segmentation violation
#0  vgModuleLocal_do_syscall_for_client_WRK () at 
m_syswrap/syscall-amd64-linux.S:147
#1  0x0000000000000008 in ?? ()
#2  0x0000000802c9ddd0 in ?? ()
#3  0x0000000802c9dd90 in ?? ()
#4  0x0000000039c2b950 in vgPlain_threads ()
#5  0x000000000000003d in ?? ()
#6  0x0000000039c2b940 in vgPlain_threads ()
#7  0x000000003a0154c8 in syscallInfo ()
#8  0x00000000000000b8 in ?? ()
#9  0x000000000000003d in ?? ()
#10 0x0000000000000001 in ?? ()
#11 0x000000003a015438 in syscallInfo ()
#12 0x00000000380a4acb in vgPlain_client_syscall ()
#13 0x00000000380a1483 in handle_syscall ()
#14 0x00000000380a2cb7 in vgPlain_scheduler ()
#15 0x00000000380b20ed in run_a_thread_NORETURN () at 
m_syswrap/syswrap-linux.c:103
#16 0x0000000000000000 in ?? ()
==23684==
==23684== HEAP SUMMARY:
==23684==     in use at exit: 400,342,711 bytes in 324,405 blocks
==23684==   total heap usage: 1,706,725 allocs, 1,382,320 frees, 
1,290,641,013 bytes allocated
==23684==
==23684== LEAK SUMMARY:
==23684==    definitely lost: 16,272 bytes in 165 blocks
==23684==    indirectly lost: 74,905 bytes in 446 blocks
==23684==      possibly lost: 2,997,955 bytes in 40,606 blocks
==23684==    still reachable: 381,943,798 bytes in 264,556 blocks
==23684==         suppressed: 15,309,781 bytes in 18,632 blocks
==23684== Rerun with --leak-check=full to see details of leaked memory
==23684==
==23684== For counts of detected and suppressed errors, rerun with: -v
==23684== Use --track-origins=yes to see where uninitialised values come 
from
==23684== ERROR SUMMARY: 83 errors from 5 contexts (suppressed: 1440 
from 192)

p.s. libCling.so is an library based on the Clang 3.5 compiler that 
provides an interactive compiler environment.

Re: [Valgrind-users] valgrind && sprintf arguments

[Matthias A. <gu...@un...>]

El día Wednesday, July 30, 2014 a las 08:17:11AM +0200, Matthias Apitz escribió:
> 
> the big C-server (where strchrnul() is not replaced):
> 
> http://www.unixarea.de/valg1.txt
> 
> the small C-code above (where strchrnul() is replaced):
> 
> http://www.unixarea.de/valg2.txt
> 
> I'm not a valgrind expert and can not say what is causing the
> difference; let me know if you want me to file a bug report with the data.

I found the reason by reading and comparing both files line by line; the
problem is visible in valg1.txt:

ERROR: ld.so: object '/usr/local/lib/valgrind/vgpreload_core-x86-linux.so' from LD_PRELOAD
cannot be preloaded: ignored.

this was caused by a Linux problem; someone did an error and updated the
SuSE Linux to x86_64 while it should stay 32bit; valgrind was
was compiled on it; later the box was resetted to 32bit x86
but valgrind was not re-compiled again; I did this now and now all the
C-lib functions are redirected correctly.

Thread closed :-)

Thanks

	matthias
-- 
Matthias Apitz               |  /"\   ASCII Ribbon Campaign:
E-mail: gu...@un...     |  \ /   - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ |   X    - No proprietary attachments
phone: +49-170-4527211       |  / \   - Respect for open standards
                             | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign

Re: [Valgrind-users] valgrind && sprintf arguments

[Matthias A. <gu...@un...>]

El día Tuesday, July 29, 2014 a las 08:35:51PM +0200, Philippe Waroquiers escribió:

> On Tue, 2014-07-29 at 08:15 +0200, Matthias Apitz wrote:
> > El día Monday, July 28, 2014 a las 07:11:02AM -0700, John Reiser escribió:
> > 
> > > > ==17454== Conditional jump or move depends on uninitialised value(s)
> > > > ==17454==    at 0x5921F10: strchrnul (in /lib/libc-2.11.3.so)
> > > > ==17454==    by 0x58E55D6: vfprintf (in /lib/libc-2.11.3.so)
> ...
> > All was fine. Why is valgrind complaining?
> 
> Here is an hypothesis:
> 
> Looking at (in the SVN version) shared/vg_replace_strmem.c
> strchrnul should have been replaced by the implementation
> in vg_replace_strmem.c.
> 
> From the stacktrace above, it looks like strchrnul was not replaced.

This (your hypothesis) matches with the fact that I was not able to
reproduce the same problem with a small C-pgm doing exactly the same
sprintf() call:

#include <stdio.h>
#define MAX_SEL_LEN 1024

static int select_record();

main()
{

    select_record("SELECT rowid, sisisinst.* from sisisinst");

}

static int select_record (char *sel_anw)
{
  char  select_anw[MAX_SEL_LEN];
  char *name = "sisisinst";

  sprintf (select_anw, sel_anw, name, name);

}

in this case the valgrind does not complain with the sprintf() ...
strchrnul() stack trace; and in addition, the output shows the
replacement of strchrnul() to some valgrind' function implementation; I
have the output here:

the big C-server (where strchrnul() is not replaced):

http://www.unixarea.de/valg1.txt

the small C-code aboce (where strchrnul() is replaced):

http://www.unixarea.de/valg2.txt

I'm not a valgrind expert and can not say what is causing the
difference; let me know if you want me to file a bug report with the data.

> Often, the glibc implementations of the str* functions
> are highly optimised, and causes false positive
> (e.g. by assuming they can read a few more bytes than
> the end of the string).
> 
> That might be the case for you.
> 
> What you could do is to redo your GDB session, but using
> the valgrind gdbserver monitor command to check the definedness
> of the printf args at various momenets and
> just before the print call.
> 
> Note that using --track-origins=yes should indicate where
> this unitialised byte is coming from.
> 
> Would be nice to understand why strchrnul was not replaced
> (using e.g. -v -v -v --trace-redir=yes).

yes, would be nice; let me know if you need more data to understand this
problem of not replacing strchrnul()

Thx

	matthias

-- 
Matthias Apitz               |  /"\   ASCII Ribbon Campaign:
E-mail: gu...@un...     |  \ /   - No HTML/RTF in E-mail
WWW: http://www.unixarea.de/ |   X    - No proprietary attachments
phone: +49-170-4527211       |  / \   - Respect for open standards
                             | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign