valgrind-users — General discussion list for Valgrind users

[Valgrind-users] [hello] Could sgcheck run in aarch64?

[Wuweijia <wuw...@hu...>]

Hi:
In valgrind 3.12, I run sgcheck in aarch64. It show me the message "SGCheck doesn't work on ARM yet, sorry." why sgcheck not support in aarch64?  What about sgcheck in valgrind 3.13?


BR
Owen

Re: [Valgrind-users] [hello] I am debugging the new sub-tool for valgrind.

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

> 
>           There are some bug in the sub-tool for valgrind.  I want to debug it via printing log, but there is a lot of log and run slowly I can not stand it .
> 
> And is there any tools like gdb , I can the debug the sub-tool for vaglrind at some point in my test program.


As Philippe says in another thread, see README_DEVELOPERS.

Beyond that, there are the usual low-level debugging hints:
1. strace -f -o strace.out -e trace=execve -v -s 300 valgrind /bin/date
Then in strace.out:
    execve("/usr/lib64/valgrind/memcheck-amd64-linux", ["valgrind", ...],
      ..., "VALGRIND_LAUNCHER=/usr/bin/valgrind"])
and that last environment variable is important, as well as the pathname
in the first argument to execve().  Everything must correspond; mixing
components will cause confusion and/or errors.

2. When all else fails, then insert a deliberate infinite loop at
(or just before) the point of interest::
	write(2, "\n\nHELP!\n\n", 9);  /* reminder to developer */
	for (;;) ;  /* deliberate infinite loop */
Invoke your tool normally (not using any debugger), and watch the CPU utilization
using /usr/bin/top in another window.  When the CPU utilization reaches 100%
and/or the HELP! message appears, then attach gdb to the process:
	gdb path_to_program_name -p PID   ## PID is the process ID
Now you can look around in gdb.

You may have to add symbol tables manually.  In a command-line shell, invoke
"cat /proc/PID/maps" to get the layout of the address space, such as:
  =====
  555be56ae000-555be56ba000 r-xp 00000000 08:03 524616                     /usr/bin/cat
  555be58b9000-555be58ba000 r--p 0000b000 08:03 524616                     /usr/bin/cat
  555be58ba000-555be58bb000 rw-p 0000c000 08:03 524616                     /usr/bin/cat
  555be5baa000-555be5bcb000 rw-p 00000000 00:00 0                          [heap]
  7efd424dd000-7efd4907c000 r--p 00000000 08:03 544504                     /usr/lib/locale/locale-archive
  7efd4907c000-7efd49238000 r-xp 00000000 08:03 532794                     /usr/lib64/libc-2.24.so
    [[snip]
  =====

Then for each program or shared library file:
	$ objdump --section-headers path_to_file  |  grep text
  12 .text         00007729  0000000000001bc0  0000000000001bc0  00001bc0  2**4
	$ gdb  # another gdb
	(gdb) print 0x555be56ae000 + 0x00001bc0
	$1 = 0x555be56afbc0

Go back to the gdb that was invoked with -p, and add the symbols using:
	(gdb) add-symbol-file path_to_file 0x555be56afbc0

[Caution: short infinite loops cause the CPU chip to become very hot, quickly.
Avoid executing such a loop for more than a few seconds at a time.]

-- 

Re: [Valgrind-users] [hello] I am debugging the new sub-tool for valgrind.

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

On Tue, 2017-07-04 at 10:48 +0000, Wuweijia wrote:
> Hi:
>          There are some bug in the sub-tool for valgrind.  I want to
> debug it via printing log, but there is a lot of log and run slowly I
> can not stand it . 
> And is there any tools like gdb , I can the debug the sub-tool for
> vaglrind at some point in my test program.

If what you want to do is to debug valgrind itself,
then see README_DEVELOPERS.
There is a section 'Debugging Valgrind with GDB'.
I am using the second way (the 'possibly easier way")
as I find it easier :).

If the above is not the answer to your question, please rephrase
your question.

Thanks

Philippe

[Valgrind-users] [hello] I am debugging the new sub-tool for valgrind.

[Wuweijia <wuw...@hu...>]

Hi:
         There are some bug in the sub-tool for valgrind.  I want to debug it via printing log, but there is a lot of log and run slowly I can not stand it .
And is there any tools like gdb , I can the debug the sub-tool for vaglrind at some point in my test program.


BR
Owen

Re: [Valgrind-users] How to build additional function wrappers

[Serhei M. <ser...@gm...>]

The errors occurred because I included libreplacemalloc in my tool,
which calls VG_USERREQ__GET_MALLOCFUNCS (getting a table full of NULL
function values), and then tries to call those functions instead of
malloc(). In hindsight, the "memory exhausted" error was a clue
pointing to this.

Removing the dependencies on LIBREPLACEMALLOC in Makefile.am solved the problem.

All the best,
      Serguei Makarov

On Mon, Jun 26, 2017 at 5:41 PM, Serhei Makarov <ser...@gm...> wrote:
> Hello all,
>
> I'm writing a Valgrind tool that makes use of function wrapping. From
> what I understand, wrappers need to run on the simulated CPU. I wrote
> a simple example which imitates the way Memcheck uses
> mc_replace_strmem.c to generate a preloaded .so that contains my own
> wrappers. A simplified version of my code is attached; I've been
> having some problems with it.
>
> After compiling and running the tool (using the 3.12.0 codebase on
> Linux), the instrumented programs crash in odd ways:
>
> $ inst/bin/valgrind --tool=simplewrap ls
> ==1201== SimpleWrap, do only basic function wrapping
> ==1201== basic example for mailing list
> ==1201== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
> ==1201== Command: ls
> ==1201==
> --1201-- VG_USERREQ__CLIENT_CALL1: func=0x0
> --1201-- VG_USERREQ__CLIENT_CALL1: func=0x0
> --1201-- VG_USERREQ__CLIENT_CALL1: func=0x0
> --1201-- VG_USERREQ__CLIENT_CALL1: func=0x0
> --1201-- VG_USERREQ__CLIENT_CALL1: func=0x0
> --1201-- VG_USERREQ__CLIENT_CALL1: func=0x0
> --1201-- VG_USERREQ__CLIENT_CALL1: func=0x0
> ls: memory exhausted
> ==1201==
>
> $ ./vg-in-place --tool=wrapsimple gcc --help
>
> ==1215== SimpleWrap, do only basic function wrapping
> ==1215== basic example for mailing list
> ==1215== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
> ==1215== Command: gcc --help
> ==1215==
> --1215-- VG_USERREQ__CLIENT_CALL1: func=0x0
> --1215-- VG_USERREQ__CLIENT_CALL1: func=0x0
> terminate called without an active exception
> ==1215==
> ==1215== Process terminating with default action of signal 6 (SIGABRT)
> ==1215==    at 0x516F91F: raise (raise.c:58)
> ==1215==    by 0x5171519: abort (abort.c:89)
> ==1215==    by 0x47347C: ??? (in /usr/bin/gcc)
> ==1215==    by 0x472F05: ??? (in /usr/bin/gcc)
> ==1215==    by 0x472F50: ??? (in /usr/bin/gcc)
> ==1215==    by 0x471C51: ??? (in /usr/bin/gcc)
> ==1215==    by 0x4717A7: ??? (in /usr/bin/gcc)
> ==1215==    by 0x4657B6: ??? (in /usr/bin/gcc)
> ==1215==    by 0x441FED: ??? (in /usr/bin/gcc)
> ==1215==    by 0x481AAC: ??? (in /usr/bin/gcc)
> ==1215==    by 0x515A38F: (below main) (libc-start.c:245)
> ==1215==
> Aborted (core dumped)
>
> These crashes also happen if I comment out the wrapper function and
> compile the tool with an 'empty' sw_wrap.c, so the cause appears to
> relate to something I'm (not) doing with the build system to set up
> the preloaded .so, rather than the way the wrapper itself is written.
> Does anyone have a suggestion for how to properly add function
> wrappers to a Valgrind tool?
>
> All the best,
>    Serguei Makarov

Re: [Valgrind-users] How to calculate the amount (in bytes) of cache misses

[Xiang Li <lx...@qt...>]

Hi John,

One thing to confirm. For LLd reading misses (data only) in bytes, it is DLmr * lineSize, correct? (suppose bus width is the same as that of LLd for a simple case).

Thanks, Xiang


-----Original Message-----
From: John Reiser [mailto:jr...@bi...] 
Sent: Monday, June 26, 2017 10:49 AM
To: val...@li...
Subject: Re: [Valgrind-users] How to calculate the amount (in bytes) of cache misses

> I am using Cachegrind to study the cache miss behavior of our program. I need to collect the last level cache misses in bytes. According to the online manual http://valgrind.org/docs/manual/cg-manual.html (related parts are copied at the end for reference), Cachegrind outputs the number of misses. 
> To my understanding, the amount in bytes can be calculated as follows
> 
> Misses in bytes = (the number of misses) * (line size of the cache)
> 
> where the line size can be configured with option such as |--LL=<size>,<associativity>,<line size>. |Is my understanding correct? If not, could you tell me how to calculate the misses in bytes?

That product is the total bytes of traffic that are caused by misses.
But it ignores the width of the bus, which determines the duration
of the transfers.   Most desktop computers have a 64-bit data bus
(72 bits if ECC) to DDR3 or DDR4 SDRAM.  Some embedded devices have a 32-bit bus (or even narrower).  Desktop video graphic display cards usually have 32, 64, 128, 192, 256, or 384 bits [and no cache :-)]  The bus width to L1 and L2 caches can be wider.
It's 128 or 256 bits on PowerPC chips, for instance.
(Yes: the icache fetches 4 or 8 32-bit instructions at a time, and all can be decoded and executed in parallel except for dataflow constraints.  Aligning branch destinations to 32-byte boundaries might make a big difference in execution speed.)

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] about VGDB

[Ivo R. <iv...@iv...>]

2017-06-28 4:40 GMT+02:00 Alberthus <alb...@pr...>:
> Yes, that's the idea.
> It is a problem i had quite often in the beginning, I searched on the
> internet and also could'n find a solution. I ended up finding it by chance
> when I was searching for something else.
> When I first read about vgdb I thought, "what an awesome idea, get valgrind
> and gdb to work together, I gotta learn it". There are still many things
> that could be improved, one of those would be this small detail on the
> documentation. Another thing that I think that is a idea worth working on is
> to create a option that works simillar to break on gdb, but instead of
> having a point where its supposed to stop it stops the execution at a memory
> leak. The execution could be much slower, but it could save hours of work
> searching for memory leaks for it would point pretty close to the root
> cause. I don't know how valgrind works, but if could be done it would be a
> life saver.


If you can propose a patch for the documentation bit mentioned above,
that would be awesome.
Source file for the relevant piece of documentation is found here:
docs/xml/manual-core-adv.xml
You can obtain Valgrind sources as described at
http://valgrind.org/downloads/repository.html.


Your other point was "instant" memory leak detection under gdb.
However that is not how Memcheck (the default Valgrind analysis tool) works [1].
It searches for leaks at the end of the program run.
It is however possible to perform incremental memory leak analysis
under gdb+vgdb,
see http://valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands,
gdb monitor command "leak_check".

Once upon a time there was also an experimental tool called "omega" [2] [3]
However I have no idea if it is still buildable with current Valgrind
release and usable.
It had also a design flaw which prohibited its reliable operation.

I.

[1] http://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks
[2] http://www.brainmurders.eclipse.co.uk/omega.html
[3] https://stackoverflow.com/questions/22517082/valgrind-how-to-understand-exactly-when-i-lose-control-of-a-pointer-to-a-memory




>
> -------- Original Message --------
> Subject: Re: [Valgrind-users] about VGDB
> Local Time: June 20, 2017 2:03 AM
> UTC Time: June 20, 2017 5:03 AM
> From: iv...@iv...
> To: Alberthus <alb...@pr...>
> val...@li... <val...@li...>
>
> 2017-06-09 21:55 GMT+02:00 Alberthus via Valgrind-users
> <val...@li...>:
>> Hello,
>> I"m new to programing and have been learning how to debug my program with
>> gdb and find leaks with valgrind, and have been trying to do them both
>> together using the instructions described in section 3.2 of
>> http://valgrind.org/docs/manual/manual-core-adv.html
>> I have been having problems finishing the valgrind session, the suggestion
>> given by the answer at
>>
>> https://stackoverflow.com/questions/37731497/quit-valgrind-cleanly-when-debugging-with-gdb,
>> works but is not always, is this the way it is expected we quit valgrind?
>> Later on I also found by typing on gdb:
>> (gdb)monitor help
>> and I found the command v.kill that also worked for me.
>>
>> I suggest that you change the manual so that it will also teach a way to
>> quit vgdb somewhere near where you teach how to use it, will be usefull in
>> a
>> documentation
>
> Hello Alberthus,
>
> So if I understand it correctly, you would like to see command
> "monitor v.kill" listed in a subsection
> of section "3.2. Debugging your program using Valgrind gdbserver and GDB"?
> For example a new subsection called "3.2.5 Disconnecting GDB from
> Valgrind gdbserver"?
>
> Let me know,
> I.
>
>

[Valgrind-users] How to build additional function wrappers

[Serhei M. <ser...@gm...>]

Hello all,

I'm writing a Valgrind tool that makes use of function wrapping. From
what I understand, wrappers need to run on the simulated CPU. I wrote
a simple example which imitates the way Memcheck uses
mc_replace_strmem.c to generate a preloaded .so that contains my own
wrappers. A simplified version of my code is attached; I've been
having some problems with it.

After compiling and running the tool (using the 3.12.0 codebase on
Linux), the instrumented programs crash in odd ways:

$ inst/bin/valgrind --tool=simplewrap ls
==1201== SimpleWrap, do only basic function wrapping
==1201== basic example for mailing list
==1201== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==1201== Command: ls
==1201==
--1201-- VG_USERREQ__CLIENT_CALL1: func=0x0
--1201-- VG_USERREQ__CLIENT_CALL1: func=0x0
--1201-- VG_USERREQ__CLIENT_CALL1: func=0x0
--1201-- VG_USERREQ__CLIENT_CALL1: func=0x0
--1201-- VG_USERREQ__CLIENT_CALL1: func=0x0
--1201-- VG_USERREQ__CLIENT_CALL1: func=0x0
--1201-- VG_USERREQ__CLIENT_CALL1: func=0x0
ls: memory exhausted
==1201==

$ ./vg-in-place --tool=wrapsimple gcc --help

==1215== SimpleWrap, do only basic function wrapping
==1215== basic example for mailing list
==1215== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==1215== Command: gcc --help
==1215==
--1215-- VG_USERREQ__CLIENT_CALL1: func=0x0
--1215-- VG_USERREQ__CLIENT_CALL1: func=0x0
terminate called without an active exception
==1215==
==1215== Process terminating with default action of signal 6 (SIGABRT)
==1215==    at 0x516F91F: raise (raise.c:58)
==1215==    by 0x5171519: abort (abort.c:89)
==1215==    by 0x47347C: ??? (in /usr/bin/gcc)
==1215==    by 0x472F05: ??? (in /usr/bin/gcc)
==1215==    by 0x472F50: ??? (in /usr/bin/gcc)
==1215==    by 0x471C51: ??? (in /usr/bin/gcc)
==1215==    by 0x4717A7: ??? (in /usr/bin/gcc)
==1215==    by 0x4657B6: ??? (in /usr/bin/gcc)
==1215==    by 0x441FED: ??? (in /usr/bin/gcc)
==1215==    by 0x481AAC: ??? (in /usr/bin/gcc)
==1215==    by 0x515A38F: (below main) (libc-start.c:245)
==1215==
Aborted (core dumped)

These crashes also happen if I comment out the wrapper function and
compile the tool with an 'empty' sw_wrap.c, so the cause appears to
relate to something I'm (not) doing with the build system to set up
the preloaded .so, rather than the way the wrapper itself is written.
Does anyone have a suggestion for how to properly add function
wrappers to a Valgrind tool?

All the best,
   Serguei Makarov

Re: [Valgrind-users] How to calculate the amount (in bytes) of cache misses

[Xiang Li <lx...@qt...>]

Hi John,

Thanks for your prompt reply. I got your point.

BR, Xiang

-----Original Message-----
From: John Reiser [mailto:jr...@bi...] 
Sent: Monday, June 26, 2017 10:49 AM
To: val...@li...
Subject: Re: [Valgrind-users] How to calculate the amount (in bytes) of cache misses

> I am using Cachegrind to study the cache miss behavior of our program. I need to collect the last level cache misses in bytes. According to the online manual http://valgrind.org/docs/manual/cg-manual.html (related parts are copied at the end for reference), Cachegrind outputs the number of misses. 
> To my understanding, the amount in bytes can be calculated as follows
> 
> Misses in bytes = (the number of misses) * (line size of the cache)
> 
> where the line size can be configured with option such as |--LL=<size>,<associativity>,<line size>. |Is my understanding correct? If not, could you tell me how to calculate the misses in bytes?

That product is the total bytes of traffic that are caused by misses.
But it ignores the width of the bus, which determines the duration
of the transfers.   Most desktop computers have a 64-bit data bus
(72 bits if ECC) to DDR3 or DDR4 SDRAM.  Some embedded devices have a 32-bit bus (or even narrower).  Desktop video graphic display cards usually have 32, 64, 128, 192, 256, or 384 bits [and no cache :-)]  The bus width to L1 and L2 caches can be wider.
It's 128 or 256 bits on PowerPC chips, for instance.
(Yes: the icache fetches 4 or 8 32-bit instructions at a time, and all can be decoded and executed in parallel except for dataflow constraints.  Aligning branch destinations to 32-byte boundaries might make a big difference in execution speed.)

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] How to calculate the amount (in bytes) of cache misses

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

> I am using Cachegrind to study the cache miss behavior of our program. I need to collect the last level cache misses in bytes. According to the online manual http://valgrind.org/docs/manual/cg-manual.html (related parts are copied at the end for reference), Cachegrind outputs the number of misses. 
> To my understanding, the amount in bytes can be calculated as follows
> 
> Misses in bytes = (the number of misses) * (line size of the cache)
> 
> where the line size can be configured with option such as |--LL=<size>,<associativity>,<line size>. |Is my understanding correct? If not, could you tell me how to calculate the misses in bytes?

That product is the total bytes of traffic that are caused by misses.
But it ignores the width of the bus, which determines the duration
of the transfers.   Most desktop computers have a 64-bit data bus
(72 bits if ECC) to DDR3 or DDR4 SDRAM.  Some embedded devices
have a 32-bit bus (or even narrower).  Desktop video graphic
display cards usually have 32, 64, 128, 192, 256, or 384 bits
[and no cache :-)]  The bus width to L1 and L2 caches can be wider.
It's 128 or 256 bits on PowerPC chips, for instance.
(Yes: the icache fetches 4 or 8 32-bit instructions at a time,
and all can be decoded and executed in parallel except for
dataflow constraints.  Aligning branch destinations to 32-byte
boundaries might make a big difference in execution speed.)

[Valgrind-users] How to calculate the amount (in bytes) of cache misses

[Xiang Li <lx...@qt...>]

Dear Valgrind users,

I am using Cachegrind to study the cache miss behavior of our program. I need to collect the last level cache misses in bytes. According to the online manual http://valgrind.org/docs/manual/cg-manual.html (related parts are copied at the end for reference), Cachegrind outputs the number of misses. To my understanding, the amount in bytes can be calculated as follows
Misses in bytes = (the number of misses) * (line size of the cache)

where the line size can be configured with option such as --LL=<size>,<associativity>,<line size>. Is my understanding correct? If not, could you tell me how to calculate the misses in bytes?

Copied from the manual:
Cache accesses for instruction fetches are summarised first, giving the number of fetches made (this is the number of instructions executed, which can be useful to know in its own right), the number of I1 misses, and the number of LL instruction (LLi) misses.
Cache accesses for data follow. The information is similar to that of the instruction fetches, except that the values are also shown split between reads and writes (note each row's rd and wr values add up to the row's total).

Thanks and regards,

Xiang

[Valgrind-users] Configure Valgrind with mpi

[Castellana M. <Mic...@cu...>]

Dear Valgrind users, 
I would like to debug an Mpi program with Valgrind, but I am having trouble configuring Valgrind with with Mpi. I found the path /opt/intel///impi/5.0.2.044/intel64/bin/ where mpicc is located, and configured Valgrind with

$./configure --prefix=/obs/username/valgrind/ --with-mpicc=/opt/intel///impi/5.0.2.044/intel64/bin/

but I get the following output

…
checking for mpicc... /opt/intel///impi/5.0.2.044/intel64/bin/mpicc
checking primary target for usable MPI2-compliant C compiler and mpi.h... no
checking secondary target for usable MPI2-compliant C compiler and mpi.h… no
…

I see that mpi.h is located in the /include directory of the path above

$ ls /opt/intel///impi/5.0.2.044/intel64/include/
gfortran  i_malloc.h  mpi.h  mpi.mod  mpi_base.mod  mpi_constants.mod  mpi_sizeofs.mod  mpicxx.h  mpif.h  mpio.h  mpiof.h

Do you know how this could be fixed? 

Thank you for your help. 

Best,

Re: [Valgrind-users] hi, there is an unknown instruction in arm32 mode. Does valgrind not support strmi instr?

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

> disInstr(thumb): unhandled instruction: 0x450B 0xD104      0x450B 0xD104 => strmi  Does valgrind not support strmi instr?
> 
> ==23313== valgrind: Unrecognised instruction at address 0x4108187.

The complaint says "(thumb)", and the address 0x4108187 is odd, so this looks like
Thumb mode, which is 16-bit instructions.  There is no "strmi" opcode in the Thumb
instruction set.  "strmi" would be a 32-bit instruction which is a conditional
"STore Register to memory if condition code is MInus (N bit (negative) set)".

Assembling and dis-assembling the program
===== foo.S
		.short 0x450B, 0xD104
=====
$ gcc -c foo.S
$ gdb foo.o
(gdb) x/2i 1   ###  1: odd pc ==> thumb mode (16-bit instructions)
    0x1:	cmp	r3, r1
    0x3:	bne.n	0xe

(gdb) x/i 0   ### 0: even pc ==> ARM mode (32-bit instructions)
    0x0:	tstle	r4, r11, lsl #10

(gdb)

shows that "0x450B 0xD104" is not a 'strmi'.

Please use a debugger or other tool to inspect the instruction stream.
Show the surrounding bytes (16 bytes before, 16 bytes after)
in both hex and decoded instructions.

-- 

Re: [Valgrind-users] How to debug program that has linux Capabilities

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

> Create a hello world binary.
> 
> Give it linux capabilities e.g. with setcap command.
> 
> valgrind the binary with caps.
> 
> It will fail.:
     [snip]]
> 
> Afair I tried also giving SUID flags, and all CAPs to valgrind* and it's /lib/ binaries and all, but nothing worked.


The capabilities are attached to the process by the Linux kernel
from the file in the filesystem when the kernel performs the
syscall execve(filename,,).  Neither valgrind nor its tools
perform execve(target_filename,,).

If a capability is inheritable, then attaching it to the filename
of some valgrind execve() in the dynamic chain of execve()s (see
"strace -e trace=execve valgrind ...") should work.
Otherwise, investigate prctl(PR_CAP_AMBIENT_RAISE,) etc.
Logically you want valgrind to prctl(PR_CAP_SET_ATTACH,)
but that apparently does not exist.

-- 

[Valgrind-users] How to debug program that has linux Capabilities

[quazpick <qua...@on...>]

Create a hello world binary.

Give it linux capabilities e.g. with setcap command.

valgrind the binary with caps.

It will fail.:

#include <stdio.h>
int main() { printf("Hello.\n"); return 0; }

user@devuan:~/test3$ gcc main.c 
user@devuan:~/test3$ sudo su
root@devuan:/home/user/test3# setcap "cap_net_admin+eip" ./a.out 
root@devuan:/home/user/test3# exit
exit

user@devuan:~/test3$ valgrind ./a.out 
==19376== 
==19376== Warning: Can't execute setuid/setgid/setcap executable: ./a.out
==19376== Possible workaround: remove --trace-children=yes, if in effect
==19376== 
valgrind: ./a.out: Permission denied

Even root can't valgrind it:

user@devuan:~/test3$ sudo valgrind ./a.out 
==19385== 
==19385== Warning: Can't execute setuid/setgid/setcap executable: ./a.out
==19385== Possible workaround: remove --trace-children=yes, if in effect
==19385== 
valgrind: ./a.out: Permission denied


So how to?

Afair I tried also giving SUID flags, and all CAPs to valgrind* and it's /lib/ binaries and all, but nothing worked.


Is it required to hack the kernel to remove this restriction?
What is the root cause?

Re: [Valgrind-users] 答复: Please check the dhat could run in the ELF32 mode in x86-64.

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

This looks like a bug related to running libc free resource hooks.

You can bypass the problem by giving the parameters:

--run-libc-freeres=no --run-cxx-freeres=no

Please file a bug on bugzilla.

Thanks

Philippe

On Sat, 2017-06-24 at 09:35 +0000, Wuweijia wrote:
> Any guy focus on this bug? There is still no answer now.
> 
>  
> 
> 发件人: Wuweijia 
> 发送时间: 2017年6月23日 16:54
> 收件人: 'val...@li...'
> <val...@li...>
> 抄送: Fanbohao <fan...@hu...>
> 主题: 答复: Please check the dhat could run in the ELF32 mode in
> x86-64.
> 
> 
>  
> 
> Hi, there are some progress I analyzed.
> 
>      1:  If function main is empty, it also failed. The code as below.
> 
>     #include    <stdio.h>
> 
> #include    <stdlib.h>
> 
> #include    <string.h>
> 
> #include    <fcntl.h>
> 
> #include    <unistd.h>
> 
> #include    <sys/mman.h>
> 
> #include    <sys/types.h>
> 
> #include    <sys/stat.h>
> 
>  
> 
> int main(int argc, char *argv[])
> 
> {
> 
> Return 0;
> 
> }
> 
>    
> 
> The compile cmd: gcc -g -O0 -m32main.c
> 
>  
> 
>  
> 
> 2:  This static void final_tidyup(ThreadId tid) send the
> Vg_CoreClientReq cmd, and dh_handle_noninsn_write  go the default
> branch. But In x86_64 mode,  it never go the default branch.
> 
>  
> 
> It is very urgent now. Can you show me how to resolve it .
> 
>  
> 
> BR
> 
> Owen
> 
>  
> 
>  
> 
>  
> 
> 发件人: Wuweijia 
> 发送时间: 2017年6月23日 11:20
> 收件人: val...@li...
> 抄送: Fanbohao <fan...@hu...>
> 主题: Please check the dhat could run in the ELF32 mode in x86-64.
> 
> 
>  
> 
> Hi: I compile the code in x86-64 machine, and run dhat . it is ok.
> 
> The compile cmd: gcc -g -O0  main.c
> 
> The dhat cmd valgrind –tool=exp-dhat ./a.out
> 
>  
> 
>  
> 
> But I compile the same code in the same machine, but another compile
> cmd,  and run dhat. It failed.
> 
> The compile cmd: gcc -g -O0 -m32main.c
> 
> The dhat cmd valgrind –tool=exp-dhat ./a.out
> 
>  
> 
> I just compile same code into ELF32 mode.
> 
>  
> 
>  
> 
> The output as below:
> 
> DHAT: dh_main.c:756 (dh_handle_noninsn_write): the 'impossible'
> happened.
> 
>  
> 
> host stacktrace:
> 
> ==84382==    at 0x3800C886: show_sched_status_wrk (m_libcassert.c:343)
> 
> ==84382==    by 0x3800C9C6: report_and_quit (m_libcassert.c:419)
> 
> ==84382==    by 0x3800CAEB: vgPlain_assert_fail (m_libcassert.c:485)
> 
> ==84382==    by 0x38008623: dh_handle_noninsn_write (dh_main.c:756)
> 
> ==84382==    by 0x38010558: final_tidyup (m_main.c:2798)
> 
> ==84382==    by 0x38010A54: shutdown_actions_NORETURN (m_main.c:2564)
> 
> ==84382==    by 0x38078E90: run_a_thread_NORETURN
> (syswrap-linux.c:199)
> 
>  
> 
> sched status:
> 
>   running_tid=1
> 
>  
> 
> Thread 1: status = VgTs_Runnable (lwpid 84382)
> 
> ==84382==    at 0x402452B: _vgnU_freeres (vg_preloaded.c:59)
> 
> ==84382==    by 0x2: ???
> 
>  
> 
>  
> 
> The valgrind version is 3.12.0
> 
>  
> 
> root@SZV1000161574:/usr1/code/source/test# gcc --version
> 
> gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
> 
> Copyright (C) 2013 Free Software Foundation, Inc.
> 
> This is free software; see the source for copying conditions.  There
> is
> 
>  
> 
>  
> 
> Does dhat support elf32 mode?
> 
>  
> 
> BR
> 
> Owen
> 
>  
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] 答复: Please check the dhat could run in the ELF32 mode in x86-64.

[Wuweijia <wuw...@hu...>]

Any guy focus on this bug? There is still no answer now.

发件人: Wuweijia
发送时间: 2017年6月23日 16:54
收件人: 'val...@li...' <val...@li...>
抄送: Fanbohao <fan...@hu...>
主题: 答复: Please check the dhat could run in the ELF32 mode in x86-64.

Hi, there are some progress I analyzed.
     1:  If function main is empty, it also failed. The code as below.
    #include    <stdio.h>
#include    <stdlib.h>
#include    <string.h>
#include    <fcntl.h>
#include    <unistd.h>
#include    <sys/mman.h>
#include    <sys/types.h>
#include    <sys/stat.h>

int main(int argc, char *argv[])
{
Return 0;
}

The compile cmd: gcc -g -O0 -m32 main.c


2:  This static void final_tidyup(ThreadId tid) send the Vg_CoreClientReq cmd, and dh_handle_noninsn_write  go the default branch. But In x86_64 mode,  it never go the default branch.

It is very urgent now. Can you show me how to resolve it .

BR
Owen



发件人: Wuweijia
发送时间: 2017年6月23日 11:20
收件人: val...@li...<mailto:val...@li...>
抄送: Fanbohao <fan...@hu...<mailto:fan...@hu...>>
主题: Please check the dhat could run in the ELF32 mode in x86-64.

Hi: I compile the code in x86-64 machine, and run dhat . it is ok.
The compile cmd: gcc -g -O0  main.c
The dhat cmd valgrind tool=exp-dhat ./a.out


But I compile the same code in the same machine, but another compile cmd,  and run dhat. It failed.
The compile cmd: gcc -g -O0 -m32 main.c
The dhat cmd valgrind tool=exp-dhat ./a.out

I just compile same code into ELF32 mode.


The output as below:
DHAT: dh_main.c:756 (dh_handle_noninsn_write): the 'impossible' happened.

host stacktrace:
==84382==    at 0x3800C886: show_sched_status_wrk (m_libcassert.c:343)
==84382==    by 0x3800C9C6: report_and_quit (m_libcassert.c:419)
==84382==    by 0x3800CAEB: vgPlain_assert_fail (m_libcassert.c:485)
==84382==    by 0x38008623: dh_handle_noninsn_write (dh_main.c:756)
==84382==    by 0x38010558: final_tidyup (m_main.c:2798)
==84382==    by 0x38010A54: shutdown_actions_NORETURN (m_main.c:2564)
==84382==    by 0x38078E90: run_a_thread_NORETURN (syswrap-linux.c:199)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 84382)
==84382==    at 0x402452B: _vgnU_freeres (vg_preloaded.c:59)
==84382==    by 0x2: ???


The valgrind version is 3.12.0

root@SZV1000161574:/usr1/code/source/test# gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is


Does dhat support elf32 mode?

BR
Owen

[Valgrind-users] hi, there is an unknown instruction in arm32 mode. Does valgrind not support strmi instr?

[Wuweijia <wuw...@hu...>]

localhost:/system/bin # ./valgrind -v ./testDhat32
==23313== Memcheck, a memory error detector
==23313== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==23313== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==23313== Command: ./testDhat32
==23313==
--23313-- Valgrind options:
--23313--    -v
--23313-- Contents of /proc/version:
--23313--   Linux version 4.4.7+ (root@baixin-HP-Compaq-8200-Elite-MT-PC) (gcc version 4.9.3 20151223 (prerelease) (SDK V100R005C00SPC030B080) ) #1 SMP PREEMPT Fri Sep 9 14:57:05 CST 2016
--23313--
--23313-- Arch and hwcaps: ARM, LittleEndian, ARMv8-neon-vfp
--23313-- Page sizes: currently 4096, max supported 4096
--23313-- Valgrind library directory: /system/lib64/valgrind
--23313-- Reading syms from /system_O/bin/testDhat32
--23313-- Reading syms from /system_O/bin/linker
--23313-- Reading syms from /system_O/lib64/valgrind/memcheck-arm-linux
--23313--    object doesn't have a dynamic symbol table
--23313-- Scheduler: using generic scheduler lock implementation.
--23313-- Reading suppressions file: /system/lib64/valgrind/default.supp
disInstr(thumb): unhandled instruction: 0x450B 0xD104      0x450B 0xD104 => strmi  Does valgrind not support strmi instr?
==23313== valgrind: Unrecognised instruction at address 0x4108187.
==23313==    at 0x4108186: __pthread_normal_mutex_trylock (pthread_mutex.cpp:281)
==23313==    by 0x4108186: __dl_pthread_mutex_lock (pthread_mutex.cpp:520)
==23313==    by 0x407C6A9: __libcpp_mutex_lock (__threading_support:251)
==23313==    by 0x407C6A9: __dl___cxa_guard_acquire (cxa_guard.cpp:176)
==23313==    by 0x41136EF: __dl__Z39__libc_arc4random_has_unlimited_entropyv (bionic_arc4random.cpp:42)
==23313==    by 0x4113759: __dl__Z26__libc_safe_arc4random_bufPvjR19KernelArgumentBlock (bionic_arc4random.cpp:49)
==23313==    by 0x4109831: __dl__Z34__libc_init_global_stack_chk_guardR19KernelArgumentBlock (__libc_init_main_thread.cpp:45)
==23313==    by 0x41098A5: __dl__Z23__libc_init_main_threadR19KernelArgumentBlock (__libc_init_main_thread.cpp:94)
==23313==    by 0x402F63B: __dl___linker_init (linker_main.cpp:525)
==23313==    by 0x403EA63: _start (begin.S:33)
==23313==    by 0x403EA63: _start (begin.S:33)
==23313==    by 0x403EA63: _start (begin.S:33)
==23313==    by 0x403EA63: _start (begin.S:33)
==23313==    by 0x403EA63: _start (begin.S:33)
==23313== Your program just tried to execute an instruction that Valgrind
==23313== did not recognise.  There are two possible reasons for this.
==23313== 1. Your program has a bug and erroneously jumped to a non-code
==23313==    location.  If you are running Memcheck and you just saw a
==23313==    warning about a bad jump, it's probably your program's fault.
==23313== 2. The instruction is legitimate but Valgrind doesn't handle it,
==23313==    i.e. it's Valgrind's fault.  If you think this is the case or
==23313==    you are not sure, please let us know and we'll try to fix it.
==23313== Either way, Valgrind will now raise a SIGILL signal which will
==23313== probably kill your program.


Env: Android O version
CPU Aarch64
EABI:  5  (I compile it in arm32 mode)

The source file as below:
int main(int argc, char *argv[])
{
   Return 0;
}

Re: [Valgrind-users] [Valgrind-developers] Migrating Valgrind sources from SVN to GIT

[Ivo R. <iv...@iv...>]

2017-06-21 18:51 GMT+02:00 Bart Van Assche <bar...@gm...>:
> Regarding the workflow of kernel maintainers: some use mutt as e-mail
> client. Others use a GUI e-mail client and use patchwork for managing
> patches. Patchwork is a server that picks up patches and patch series
> from Linux kernel related mailing lists. But I agree that from a
> maintainer point-of-view github and gitlab are far easier to use than
> the tools used by kernel developers and maintainers. See also
> https://patchwork.kernel.org/.

I had a look at Patchwork system and it looks quite nice!
Surprisingly, there is a patchwork instance running at sourceware.org:
https://patchwork.sourceware.org/

So if the community agrees, we can start using patchwork to track our patches.
However this is really orthogonal to what SCM Valgrind uses.

I.

Re: [Valgrind-users] hi, I compile the valgrind with ndk(platform-24), but ndk does not provide the interface pthread_barrier_t and pthread_spinlock_t . how you compile it ?

[Ivo R. <iv...@iv...>]

2017-06-23 9:50 GMT+02:00 Wuweijia <wuw...@hu...>:
> hg_intercepts.c:97:61: note: in definition of macro 'PTH_FUNC'
>
>     ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args); \
>
>                                                              ^
>
> hg_intercepts.c:1644:10: error: unknown type name 'pthread_barrierattr_t'
>
>           pthread_barrierattr_t* attr, unsigned long count)
>

Check config.h.
HAVE_PTHREAD_BARRIER_INIT, and HAVE_PTHREAD_SPIN_LOCK should be #undef'ined.
If they are defined then check config.log and try to determined why
they are enabled
even if ndk does not supposedly provide them.

I.

[Valgrind-users] 答复: Please check the dhat could run in the ELF32 mode in x86-64.

[Wuweijia <wuw...@hu...>]

Hi, there are some progress I analyzed.
     1:  If function main is empty, it also failed. The code as below.
    #include    <stdio.h>
#include    <stdlib.h>
#include    <string.h>
#include    <fcntl.h>
#include    <unistd.h>
#include    <sys/mman.h>
#include    <sys/types.h>
#include    <sys/stat.h>

int main(int argc, char *argv[])
{
Return 0;
}

The compile cmd: gcc -g -O0 -m32 main.c


2:  This static void final_tidyup(ThreadId tid) send the Vg_CoreClientReq cmd, and dh_handle_noninsn_write  go the default branch. But In x86_64 mode,  it never go the default branch.

It is very urgent now. Can you show me how to resolve it .

BR
Owen



发件人: Wuweijia
发送时间: 2017年6月23日 11:20
收件人: val...@li...
抄送: Fanbohao <fan...@hu...>
主题: Please check the dhat could run in the ELF32 mode in x86-64.

Hi: I compile the code in x86-64 machine, and run dhat . it is ok.
The compile cmd: gcc -g -O0  main.c
The dhat cmd valgrind tool=exp-dhat ./a.out


But I compile the same code in the same machine, but another compile cmd,  and run dhat. It failed.
The compile cmd: gcc -g -O0 -m32 main.c
The dhat cmd valgrind tool=exp-dhat ./a.out

I just compile same code into ELF32 mode.


The output as below:
DHAT: dh_main.c:756 (dh_handle_noninsn_write): the 'impossible' happened.

host stacktrace:
==84382==    at 0x3800C886: show_sched_status_wrk (m_libcassert.c:343)
==84382==    by 0x3800C9C6: report_and_quit (m_libcassert.c:419)
==84382==    by 0x3800CAEB: vgPlain_assert_fail (m_libcassert.c:485)
==84382==    by 0x38008623: dh_handle_noninsn_write (dh_main.c:756)
==84382==    by 0x38010558: final_tidyup (m_main.c:2798)
==84382==    by 0x38010A54: shutdown_actions_NORETURN (m_main.c:2564)
==84382==    by 0x38078E90: run_a_thread_NORETURN (syswrap-linux.c:199)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 84382)
==84382==    at 0x402452B: _vgnU_freeres (vg_preloaded.c:59)
==84382==    by 0x2: ???


The valgrind version is 3.12.0

root@SZV1000161574:/usr1/code/source/test# gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is


Does dhat support elf32 mode?

BR
Owen

[Valgrind-users] hi, I compile the valgrind with ndk(platform-24), but ndk does not provide the interface pthread_barrier_t and pthread_spinlock_t . how you compile it ?

[Wuweijia <wuw...@hu...>]

hg_intercepts.c:97:61: note: in definition of macro 'PTH_FUNC'
    ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args); \
                                                             ^
hg_intercepts.c:1644:10: error: unknown type name 'pthread_barrierattr_t'
          pthread_barrierattr_t* attr, unsigned long count)
          ^
hg_intercepts.c:97:61: note: in definition of macro 'PTH_FUNC'
    ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args); \
                                                             ^
hg_intercepts.c:1643:10: error: unknown type name 'pthread_barrier_t'
          pthread_barrier_t* bar,
          ^
hg_intercepts.c:98:61: note: in definition of macro 'PTH_FUNC'
    ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args)
                                                             ^
hg_intercepts.c:1644:10: error: unknown type name 'pthread_barrierattr_t'
          pthread_barrierattr_t* attr, unsigned long count)
          ^
hg_intercepts.c:98:61: note: in definition of macro 'PTH_FUNC'
    ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args)
                                                             ^
hg_intercepts.c:1680:15: error: unknown type name 'pthread_barrier_t'
               pthread_barrier_t* bar)
              ^
hg_intercepts.c:97:61: note: in definition of macro 'PTH_FUNC'
    ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args); \
                                                             ^

[Valgrind-users] Please check the dhat could run in the ELF32 mode in x86-64.

[Wuweijia <wuw...@hu...>]

Hi: I compile the code in x86-64 machine, and run dhat . it is ok.
The compile cmd: gcc -g -O0  main.c
The dhat cmd valgrind -tool=exp-dhat ./a.out


But I compile the same code in the same machine, but another compile cmd,  and run dhat. It failed.
The compile cmd: gcc -g -O0 -m32 main.c
The dhat cmd valgrind -tool=exp-dhat ./a.out

I just compile same code into ELF32 mode.


The output as below:
DHAT: dh_main.c:756 (dh_handle_noninsn_write): the 'impossible' happened.

host stacktrace:
==84382==    at 0x3800C886: show_sched_status_wrk (m_libcassert.c:343)
==84382==    by 0x3800C9C6: report_and_quit (m_libcassert.c:419)
==84382==    by 0x3800CAEB: vgPlain_assert_fail (m_libcassert.c:485)
==84382==    by 0x38008623: dh_handle_noninsn_write (dh_main.c:756)
==84382==    by 0x38010558: final_tidyup (m_main.c:2798)
==84382==    by 0x38010A54: shutdown_actions_NORETURN (m_main.c:2564)
==84382==    by 0x38078E90: run_a_thread_NORETURN (syswrap-linux.c:199)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 84382)
==84382==    at 0x402452B: _vgnU_freeres (vg_preloaded.c:59)
==84382==    by 0x2: ???


The valgrind version is 3.12.0

root@SZV1000161574:/usr1/code/source/test# gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is


Does dhat support elf32 mode?

BR
Owen

Re: [Valgrind-users] Callgrind not detecting threads

[Mike L. <mik...@gm...>]

The implementation in helgrind looks like a good way to go about this. This
is what I'm looking for.

Thanks!
Mike

On Thu, Jun 22, 2017 at 3:49 PM Philippe Waroquiers <
phi...@sk...> wrote:

> Helgrind maintains a unique thread nr by intercepting pthread_create,
> as e.g. helgrind needs to speak about terminated threads
> and so, cannot use the tid, as the tid is re-used : a new thread uses
> the lowest free tid value.
>
> See hg_main.c evh__pre_thread_ll_create, hooked up with
>  VG_(track_pre_thread_ll_create)( evh__pre_thread_ll_create );
>
> so, with this, your tool might maintain an array indexed by tid
> mapping to a unique thread nr for every created thread (even if
> it died since then).
>
> Philippe
>
>
> On Thu, 2017-06-22 at 18:58 +0000, Mike Lui wrote:
> > Hi John, I appreciate you taking the time to comment. I agree with
> > your assessments and wanted to comment on a few points.
> >
> >
> >
> > > C'mon.  The tools re-use thread IDs because that is the easiest
> >
> > > and most efficient way to track the running threads.
> > > If no re-use, then the next easiest way is to increment forever.
> > > Then the threadID cannot be an 'unsigned short', and there must be
> > > an adaptive hash table (or other non-trivial lookup mechanism)
> > > from threadID to internal thread structure, and the hash table
> > > must allow frequent deletions.
> >
> >
> > To clarify, I am not suggesting a change to make every thread hash to
> > a unique ID.
> > I was asking if there were any best-known-methods for detecting a new
> > thread in the Valgrind scheduler. For example, it looks like tools
> > such as Callgrind, rely on calling VG_(get_running_tid)() every basic
> > block to detect different threads. Using this method can produce
> > misleading information by conflating metadata from different threads.
> >
> >
> > Notably, Linux approaches PID generation by incrementing until the max
> > ID is reached, and then wrapping around and reusing any available IDs.
> > Although I don't know the internals of how the kernel achieves this,
> > this can be naively tracked with a 8KB bit vector for a 16-bit thread
> > ID, .
> > I'm unaware of how Valgrind currently tracks thread IDs.
> >
> >
> > > Modify the source to suit yourself.  You will see how
> > > un-worthwhile the modifications are for the existing use cases.
> >
> >
> > Again, I'm not contending for Valgrind internal changes.  I would
> > contend, however, that being able to reliably detect when a thread
> > starts/stops within instrumented code is valuable.
> >
> > I've seen the track_{start,stop}_client_code callbacks suggested, but
> > I've also seen that VG_(get_running_tid)() is supposed to be more
> > reliable. e.g.
> >
> http://www.mail-archive.com/val...@li.../msg03441.html
> >
> >
> > Thank you again,
> > Mike
> >
> ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________ Valgrind-users mailing
> list Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>

Re: [Valgrind-users] Callgrind not detecting threads

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

Helgrind maintains a unique thread nr by intercepting pthread_create,
as e.g. helgrind needs to speak about terminated threads
and so, cannot use the tid, as the tid is re-used : a new thread uses
the lowest free tid value.

See hg_main.c evh__pre_thread_ll_create, hooked up with
 VG_(track_pre_thread_ll_create)( evh__pre_thread_ll_create );

so, with this, your tool might maintain an array indexed by tid
mapping to a unique thread nr for every created thread (even if
it died since then).

Philippe


On Thu, 2017-06-22 at 18:58 +0000, Mike Lui wrote:
> Hi John, I appreciate you taking the time to comment. I agree with
> your assessments and wanted to comment on a few points. 
> 
> 
> 
> > C'mon.  The tools re-use thread IDs because that is the easiest
> 
> > and most efficient way to track the running threads.
> > If no re-use, then the next easiest way is to increment forever.
> > Then the threadID cannot be an 'unsigned short', and there must be
> > an adaptive hash table (or other non-trivial lookup mechanism)
> > from threadID to internal thread structure, and the hash table
> > must allow frequent deletions.
> 
> 
> To clarify, I am not suggesting a change to make every thread hash to
> a unique ID.
> I was asking if there were any best-known-methods for detecting a new
> thread in the Valgrind scheduler. For example, it looks like tools
> such as Callgrind, rely on calling VG_(get_running_tid)() every basic
> block to detect different threads. Using this method can produce
> misleading information by conflating metadata from different threads.
> 
> 
> Notably, Linux approaches PID generation by incrementing until the max
> ID is reached, and then wrapping around and reusing any available IDs.
> Although I don't know the internals of how the kernel achieves this,
> this can be naively tracked with a 8KB bit vector for a 16-bit thread
> ID, .
> I'm unaware of how Valgrind currently tracks thread IDs.
> 
> 
> > Modify the source to suit yourself.  You will see how
> > un-worthwhile the modifications are for the existing use cases.
> 
> 
> Again, I'm not contending for Valgrind internal changes.  I would
> contend, however, that being able to reliably detect when a thread
> starts/stops within instrumented code is valuable.
> 
> I've seen the track_{start,stop}_client_code callbacks suggested, but
> I've also seen that VG_(get_running_tid)() is supposed to be more
> reliable. e.g.
> http://www.mail-archive.com/val...@li.../msg03441.html 
> 
> 
> Thank you again,
> Mike
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users