valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Feature like add-symbol-file for Valgrind

[Jefferson C. <jef...@gm...>]

I'm debugging a mingw-compiled exe running under Wine, and I'm getting 
some invalid reads in chkstk.  Assuming I don't want to "skip past" them 
but detect and suppress them, the most natural thing to do would be to 
create and use a suppressions file.

However, the code that calls into chkstk is loaded outside of the normal 
"dlopen" code path, and neither Valgrind nor GDB loads symbols for it 
before it is jumped into.  With GDB I can use "add-symbol-file" to state 
where to find the symbols for it.  Does Valgrind have a similar option?

Thanks,
Jefferson

Re: [Valgrind-users] valgrind: Heap block lo/hi size mismatch when trying to debug a C++ program running inside Docker container

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

On Tue, 2019-11-12 at 20:18 -0800, Karthik Jayaraman wrote:
> 
> Thread 47: status = VgTs_Runnable (lwpid 1861)
> ==1747==    at 0x4C2922D: free (vg_replace_malloc.c:540)
> ==1747==    by 0x9A7CB7B: __libc_freeres (in /usr/lib64/libc-2.17.so)
> ==1747==    by 0x4A24739: _vgnU_freeres (vg_preloaded.c:77)
> 
> client 
> stack range: ??????? client SP: 0x289569C8
> 
> valgrind 
> stack range: [0x1009516000 0x1009615FFF] top usage: 5064 of 1048576
> 
> But the interesting fact is, it works wonderfully well when same binary is running outside the container (on a VM). If my source binary has a memory link (as per Valgrind FAQs) I am puzzled as to why I am not encountering the issue when not running in a container. 

You are using the massif tool. Massif does not detect leaks or errors,
it rather produces a report about the memory used (evolution, peak, ...).

The above seems to be a crash at the time your program terminates,
as the glibc __libc_freeres is called by valgrind function _vgnU_freeres
at exit.

If your program crashes at exit in __libc_freeres, it is recommended
to use --run-libc-freeres=no: the user manual indicates to use this
for buggy glibc. See user manual for more details.

The fact that it crashes inside a docker and not in another environment
might be explained by different glibc version or (as John said) because
of another layout of the memory.

Philippe
 
    

Re: [Valgrind-users] valgrind: Heap block lo/hi size mismatch when trying to debug a C++ program running inside Docker container

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

On 11/13/19 at 04:18 UTC, Karthik Jayaraman wrote:
> When trying to debug my C++ binary, I am running into the following issue.
> 
> valgrind: m_mallocfree.c:307 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
> 
> valgrind
> : Heap block lo/hi size mismatch: lo = 1, hi = 4294967295.
> This
>   is probably caused by your program erroneously writing past the
> end of a heap block and corrupting heap metadata
> .  If
>   you fix any
> invalid writes reported by
> Memcheck, this
>   assertion failure will
> probably go away
> .  Please try that before reporting this as a bug.
    <<snip>>


Which version of valgrind?  (Run "valgrind --version".)
Which hardware, operating system, and version?
Which C++ compiler and version?

Did memcheck report any invalid writes?  Did you fix them?


> But the interesting fact is, it works wonderfully well when same binary is running outside the container (on a VM). If my source binary has a memory link (as per Valgrind FAQs) I am puzzled as to why I am not encountering the issue when not running in a container.

If the operating system that runs inside the container does not layout
the address space of valgrind identically to the address space of valgrind
as laid out by the VM outside the container, then the results can differ.
(There might be a bug in memcheck, too.)

Re-run with "valgrind -v -v -v -d -d -d <<original arguments>>"
to get more information.  Copy+paste that info into an attachment
of a bug report; see the Bug Reports link on the page  http://valgrind.org .

[Valgrind-users] valgrind: Heap block lo/hi size mismatch when trying to debug a C++ program running inside Docker container

[Karthik J. <asw...@gm...>]

When trying to debug my C++ binary, I am running into the following issue.

valgrind: m_mallocfree.c:307 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.

valgrind
: Heap block lo/hi size mismatch: lo = 1, hi = 4294967295.
This
 is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata
.  If
 you fix any
invalid writes reported by 
Memcheck, this
 assertion failure will
probably go away
.  Please try that before reporting this as a bug.



host stacktrace
:
==1747==    at 0x58013284: ??? (in /usr/lib64/valgrind/massif-amd64-linux)
==1747==    by 0x58013397: ??? (in /usr/lib64/valgrind/massif-amd64-linux)
==1747==    by 0x58013531: ??? (in /usr/lib64/valgrind/massif-amd64-linux)
==1747==    by 0x5801BD6D: ??? (in /usr/lib64/valgrind/massif-amd64-linux)
==1747==    by 0x5800CDC1: ??? (in /usr/lib64/valgrind/massif-amd64-linux)
==1747==    by 0x580614A7: ??? (in /usr/lib64/valgrind/massif-amd64-linux)
==1747==    by 0x580737A7: ??? (in /usr/lib64/valgrind/massif-amd64-linux)
==1747==    by 0x580738DC: ??? (in /usr/lib64/valgrind/massif-amd64-linux)
==1747==    by 0x580C9561: ??? (in /usr/lib64/valgrind/massif-amd64-linux)
==1747==    by 0x580C96AA: ??? (in /usr/lib64/valgrind/massif-amd64-linux)
==1747==    by 0x580720CD: ??? (in /usr/lib64/valgrind/massif-amd64-linux)
==1747==    by 0xDEADBEEFDEADBEEE: ???
==1747==    by 0xDEADBEEFDEADBEEE: ???
==1747==    by 0xDEADBEEFDEADBEEE: ???


sched status
:

  running_tid
=47



Thread 47: status = VgTs_Runnable (lwpid 1861)
==1747==    at 0x4C2922D: free (vg_replace_malloc.c:540)
==1747==    by 0x9A7CB7B: __libc_freeres (in /usr/lib64/libc-2.17.so)
==1747==    by 0x4A24739: _vgnU_freeres (vg_preloaded.c:77)

client 
stack range: ??????? client SP: 0x289569C8

valgrind 
stack range: [0x1009516000 0x1009615FFF] top usage: 5064 of 1048576

But the interesting fact is, it works wonderfully well when same binary is running outside the container (on a VM). If my source binary has a memory link (as per Valgrind FAQs) I am puzzled as to why I am not encountering the issue when not running in a container. 

Any help appreciated.

-Karthik

[Valgrind-users] [FOSDEM] [CfP] Debugging Tools devroom 2020

[Mark W. <ma...@kl...>]

Debugging Tools developer room at FOSDEM 2020
(Brussels, Belgium, February 2).

  Talk/Discussion Submission deadline: Sunday        1 Dec 2019
  Devroom Schedule announcement:       Sunday       15 Dec 2019
  Devroom day:                         Sunday        2 Feb 2020

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 8000+ hackers from all
over the world.  It is held in the city of Brussels (Belgium).
https://fosdem.org/

FOSDEM 2020 will take place during the weekend of Saturday, February 1
and Sunday February 2 2020.  On Sunday we will have a devroom for
Debugging Tools, jointly organized by the Valgrind, GDB and strace
projects. 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 community embracing
debugging tools (valgrind, gdb, strace, etc.), executable and debugging
formats (ELF and DWARF) and debugging interfaces (ptrace, proc, bpf,
seccomp, etc.)

Please join us, regardless of whether you are a core hacker,
a plugin hacker, a user, a packager or a hacker on a project that
integrates, extends or complements debugging tools.

** 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
Sunday December 1st 2020, so we can make a list of activities during
the day.

Some possible topics for talks/discussions are:

- Recently added functional changes.
- Prototypes of new functionality in existing tools.
- Discuss release/bugfixing strategy/policy.
- Connecting debugging tools together.
- Latest DWARF extensions, going from binary back to source.
- Alternative symbol tables and unwinding data structures
  (ctf, btf, orc)
- Multi, multi, multi... threads, processes and targets.
- Debugging anything, everywhere. Dealing with complex systems.
- Dealing with the dynamic loader and the kernel.
- Intercepting and interposing functions and events.
- Adding GDB features, such as designing GDB python scripts for your
  data structures.
- Advances in gdbserver and the GDB remote serial protocol.
- Adding Valgrind features (adding syscalls for a platform or VEX
  instructions for an architecture port).
- Infrastructure changes to the Valgrind JIT framework.
- Use of new linux kernel interfaces (ptrace, proc, BPF).
- Your interesting use case with a debugging tool.

** How to Submit

Please use the FOSDEM 'pentabarf' tool to submit your proposal:
https://penta.fosdem.org/submission/FOSDEM20

- If necessary, create a Pentabarf account and activate it.
  Please reuse your account from previous years if you have
  already created 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 "Debugging Tools 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

** Recording of Talks

As usually 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).

** Code of Conduct

In order to keep FOSDEM a fun, interesting and positive experience
for everybody, we expect participants to follow our guidelines:
https://fosdem.org/2020/practical/conduct/

** Important dates

  Talk/Discussion Submission deadline: Sunday        1 Dec 2019
  Devroom Schedule announcement:       Sunday       15 Dec 2019
  Devroom day:                         Sunday        2 Feb 2020

Hope to see you all at FOSDEM 2020 in the joint Debugging Tools
devroom. Brussels (Belgium), Sunday February 2 2020.

[Valgrind-users] Syscall param ioctl(generic) points to uninitialised byte(s)

[<st...@tu...>]

Dear Valgrind users list,
I 'found' an unknown (to Valgrind) ioctl in the libdrm Linux package.
More details here, including a link to a simple program which can reproduce the result :
https://bugs.freedesktop.org/show_bug.cgi?id=112201 <https://bugs.freedesktop.org/show_bug.cgi?id=112201>
I see the general issue of unknown ioctl's arises frequently in bug reports, also that I could suppress this output if required, but perhaps it may be helpful to point out this additional ioctl.
Valgrind worked well and was very helpful in eliminating concerns about memory issues, thank you.

[Valgrind-users] Working with c++11 features and helgrind

[Aldag M. <Ald...@ro...>]

Hello,

I’m trying to use helgrind to debug thread race conditions in our software. We’re using std::thread(), std::atomic() and conditional variables.
Currently, I’m facing the following difficulties:
*  Std::thread() work fairly ok using http://www.valgrind.org/docs/manual/drd-manual.html#drd-manual.C++11
*  Std::thread() doen’t show thread names in valgrind output when being set by pthread_setname_np(handle, threadName.c_str());
    Thread names are seen in gdb-debugger though
*  Using the Client-request interface by

    ANNOTATE_THREAD_NAME(threadName_.c_str());
    std::thread::id tid=thread_.get_id();
    unsigned Valgrindid = DRD_GET_VALGRIND_THREADID;
    unsigned Helgrindid = DRD_GET_DRD_THREADID;
    std::cout << "ID: " << tid << " Valgrind_ID: " << Valgrindid << " Helgrind_ID: " << Helgrindid << " WT-Name: "<< threadName_ << std::endl;

    Doesn't print out good stuff. It prints the system-Thread ID, but Valgrind and Helgrind IDs are 0. ThreadName_ is the correct user defined name.
*  std::atomic() are treated as racy
*  conditional variables are treated as racy
*  std::future is racy ?

I'm calling the program via
     valgrind \
     --tool=helgrind \
     --log-socket=172.17.17.1 \
     -v \
    ./Application.elf

==1614== ---Thread-Announcement------------------------------------------
==1614==
==1614== Thread #21 was created
==1614==    at 0x4E016F6: clone (clone.S:56)
==1614==    by 0x486B9FB: create_thread (createthread.c:100)
==1614==    by 0x486D4E7: pthread_create@@GLIBC_2.4 (pthread_create.c:822)
==1614==    by 0x484E9F3: ??? (in /usr/lib/valgrind/vgpreload_helgrind-arm-linux.so)
==1614==
[...]
==1614==  Lock at 0x7D9D47BC was first observed
==1614==    at 0x484C6B0: ??? (in /usr/lib/valgrind/vgpreload_helgrind-arm-linux.so)
==1614==  Address 0x7d9d47bc is on thread #1's stack
==1614==
==1614==  Lock at 0x4EAD5E4 was first observed
==1614==    at 0x484C6B0: ??? (in /usr/lib/valgrind/vgpreload_helgrind-arm-linux.so)
==1614==  Address 0x4ead5e4 is 244 bytes inside a block of size 328 alloc'd
==1614==    at 0x4849368: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_helgrind-arm-linux.so)
==1614==  Block was alloc'd by thread #1
==1614==
==1614== Possible data race during read of size 4 at 0x4EB3968 by thread #1
==1614== Locks held: 1, at address 0x7D9D47BC
==1614==    at 0x17186C: _M_ptr (unique_ptr.h:147)
==1614==    by 0x17186C: get (unique_ptr.h:337)
==1614==    by 0x17186C: operator* (unique_ptr.h:323)
==1614==    by 0x17186C: wait (future:338)
==1614==    by 0x17186C: _M_get_result (future:717)
==1614==    by 0x17186C: get (future:796)

Is there any help to get this working?


Thanks,
Mario
-------------------------------------------------------------------
Röders GmbH

Sitz Soltau, Amtsgericht Lüneburg HRB 101247
Geschäftsführer: Dipl.-Ing. Jürgen Röders

Diese Nachricht und die mit ihr übermittelten Dateien sind vertraulich. Wenn Sie nicht der Empfänger sein sollten, für den die Nachricht bestimmt ist, bitte lesen oder kopieren Sie die Nachricht nicht und stellen Sie sie nicht anderen zur Verfügung. Bitte benachrichtigen Sie mich durch Beantwortung dieser E-Mail und löschen Sie sie anschließend. Vielen Dank.

This email and any files transmitted with it are confidential and intended for the individuals or entities named above. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others; also please notify the sender by replying to this message and then delete it from your system. Thank you.

Re: [Valgrind-users] Building and Installing vlagrind 3.15.0 in an embedded Linux cross-compile environment

[John K. <Joh...@be...>]

Thanks Pat for this info.  I hadn't read the README_DEVELOPERS file... I guess I should have!

John

-----Original Message-----
From: Patrick J. LoPresti <lop...@gm...>
Sent: Tuesday, October 15, 2019 6:12 PM
To: John Knight <Joh...@be...>
Cc: val...@li...
Subject: Re: [Valgrind-users] Building and Installing vlagrind 3.15.0 in an embedded Linux cross-compile environment

> If I run strings against the valgrind binary, I see the full pathname to valgrinds library …/output/debug/valgrind/install/lib/valgrind which of course is not right, it needs to be /lib/valgrind.

FWIW, I have had no problem relocating a Valgrind installation tree and then setting the VALGRIND_LIB environment variable so it can find its support files.

This is (sort of) documented in the README_DEVELOPERS file in the distribution.

 - Pat

__________________________________________________________________ Confidential This e-mail and any files transmitted with it are the property of Belkin International, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Pour la version française: http://www.belkin.com/email-notice/French.html Für die deutsche Übersetzung: http://www.belkin.com/email-notice/German.html __________________________________________________________________

Re: [Valgrind-users] Building and Installing vlagrind 3.15.0 in an embedded Linux cross-compile environment

[Patrick J. L. <lop...@gm...>]

> If I run strings against the valgrind binary, I see the full pathname to valgrinds library …/output/debug/valgrind/install/lib/valgrind which of course is not right, it needs to be /lib/valgrind.

FWIW, I have had no problem relocating a Valgrind installation tree
and then setting the VALGRIND_LIB environment variable so it can find
its support files.

This is (sort of) documented in the README_DEVELOPERS file in the distribution.

 - Pat

Re: [Valgrind-users] Building and Installing vlagrind 3.15.0 in an embedded Linux cross-compile environment

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

> I am having some issues with the valgrind 3.15.0 build and install in a cross-compile environment where the resultant code is to run on a router which is embedded Linux.

You must create an absolute path name (starts with '/') that is the same
(as a character string) on the machine which does the cross-compiling
as on the target embedded environment.  Use that as --prefix= for ./configure .

On both machines that path will be a symlink ("ln -s").  On the cross-
compiling machine, set the symlink to be some directory that you can write;
such as:
     mkdir $HOME/cross-valgrind-output
     ln -s $HOME/cross-valgrind-output /common/absolute/pathname
and check via
     ls -l /common/absolute/pathname  # on the cross-compiling machine
           /common/absolute/pathname -> $HOME/cross-valgrind-output

In the image being created for the target embedded environment,
set the symlink to be some directory such as:
     ln -s /opt/valgrind /common/absolute/pathname
and check via
     ls -l /common/absolute/pathname  # in the target embedded environment
           /common/absolute/pathname -> /opt/valgrind
As part of building the target embedded image, then copy the directory tree(s)
from $HOME/cross-valgrind-output/* to the image directory /opt/valgrind/ .


[Notice that this would be simpler if "--prefix=/opt/valgrind".
If you do not have permissions to "mkdir /opt/valgrind" on the cross-compiling
machine, then procure a second-hand x86_64 box, install your favorite
linux distribution on it, and use that box to do the cross-compiling.]

[Valgrind-users] Building and Installing vlagrind 3.15.0 in an embedded Linux cross-compile environment

[John K. <Joh...@be...>]

Hi all,

I am having some issues with the valgrind 3.15.0 build and install in a cross-compile environment where the resultant code is to run on a router which is embedded Linux.

In this environment, the build tools are cross compiled… meaning that the target CPU is an arm v7 processor, which differs from the Linux PC processor that is compiling the code.  The buildtools are arm-openwrt-linux.  When I try to build the code, the configure script errors out with the message “checking for a supported CPU… no (arm)” followed by “confiure: error: Unsupported host architecture. Sorry”.  Looking and configure, there is a case statement based on “$host-cpu” and it is specifically looking for armv7*, not arm.  If I edit the configure script and change the armv7 to arm it will build OK, so I can in fact work around this… but I will need to patch this to apply my workaround.  The build tools we use have been used for armv7 processors for some time now, and we cannot change the name to accommodate valgrind.

The second issue I am having I do not have a workaround, so I am hoping someone can help.  When I run configure, normally we would provide a –prefix parameter that would tell where to put the output for the install.  Being an imbedded product, we do not put the output in a directory that contains the native Linux PC build tools which are PC 386 processor based.  Instead, the installation directory is a temporary directory to contain all of the output from the build… then when building the image, they are relocated to the final install location.  For valgrind for example, valgrind executable would be stored at …/output/debug/valgrind/install/bin directory and its library would be stored at …/output/debug/valgrind/install/lib directory.  Now in the README file, I see at the bottom of it… “Important!  Do not move the valgrind installation into a place different from that specified by –prefix at build time.  This will cause things to break in subtle ways, mostly when valgrind handles fork/exec files.”  So, in the routers image, if I specify the prefix needed to build the image so that the build system can correctly collect the binaries, I specify –prefix as …/output/debug/valgrind/install, but it appears that valgrind binary will use this as the pathname to find its library and of course, there is no …/output/debug/valgrind/install/lib directory on the router… the target directory needs to be /lib on the router.  If I run strings against the valgrind binary, I see the full pathname to valgrinds library …/output/debug/valgrind/install/lib/valgrind which of course is not right, it needs to be /lib/valgrind.

I have noticed if I do ./configure –help, it spits out help for other commands to be used as refinement for install directories instead of –prefix.  However, if I specify –libdir=$(PACKAGE_INSTALL)/lib, where PACKAGE_INSTALL is my …/output/debug/valgrind/install directory, I get the same results as I would get had I set –prefix=$(PACKAGE_INSTALL).  The strings valgrind tells the story.

So, it looks to me that the install mechanism is very inflexible when it comes to cross-compile environment.  If I do not specify –prefix, make install will fail with the error:  /bin/mkdir -p ‘/usr/local/lib/valgrind’ /bin/mkdir: cannot create directory ‘/usr/local/lib/valgrind’: Permission denied.  The build environment will not work properly if the files are stored outside of the build workspace.  This would also pollute my cross-compile build tools.

As it is now, I cannot integrate valgrind into the embedded Linux image.  Not sure how to overcome this issue. Does anyone have a suggestion for working around this issue?

Thanks for any and all help.

Regards,
John


__________________________________________________________________ Confidential This e-mail and any files transmitted with it are the property of Belkin International, Inc. and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. Pour la version française: http://www.belkin.com/email-notice/French.html Für die deutsche Übersetzung: http://www.belkin.com/email-notice/German.html __________________________________________________________________

[Valgrind-users] [FOSDEM] [CfP] Debugging Tools devroom 2020

[Mark W. <ma...@kl...>]

Debugging Tools developer room at FOSDEM 2020
(Brussels, Belgium, February 2).

  Talk/Discussion Submission deadline: Sunday        1 Dec 2019
  Devroom Schedule announcement:       Sunday       15 Dec 2019
  Devroom day:                         Sunday        3 Feb 2020

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 8000+ hackers from all
over the world.  It is held in the city of Brussels (Belgium).
https://fosdem.org/

FOSDEM 2020 will take place during the weekend of Saturday, February 1
and Sunday February 2 2020.  On Sunday we will have a devroom for
Debugging Tools, jointly organized by the Valgrind, GDB and strace
projects. 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 community embracing
debugging tools (valgrind, gdb, strace, etc.), executable and debugging
formats (ELF and DWARF) and debugging interfaces (ptrace, proc, bpf,
seccomp, etc.)

Please join us, regardless of whether you are a core hacker,
a plugin hacker, a user, a packager or a hacker on a project that
integrates, extends or complements debugging tools.

** 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
Sunday December 1st 2020, so we can make a list of activities during
the day.

Some possible topics for talks/discussions are:

- Recently added functional changes.
- Prototypes of new functionality in existing tools.
- Discuss release/bugfixing strategy/policy.
- Connecting debugging tools together.
- Latest DWARF extensions, going from binary back to source.
- Alternative symbol tables and unwinding data structures
  (ctf, btf, orc)
- Multi, multi, multi... threads, processes and targets.
- Debugging anything, everywhere. Dealing with complex systems.
- Dealing with the dynamic loader and the kernel.
- Intercepting and interposing functions and events.
- Adding GDB features, such as designing GDB python scripts for your
  data structures.
- Advances in gdbserver and the GDB remote serial protocol.
- Adding Valgrind features (adding syscalls for a platform or VEX
  instructions for an architecture port).
- Infrastructure changes to the Valgrind JIT framework.
- Use of new linux kernel interfaces (ptrace, proc, BPF).
- Your interesting use case with a debugging tool.

** How to Submit

Please use the FOSDEM 'pentabarf' tool to submit your proposal:
https://penta.fosdem.org/submission/FOSDEM20

- If necessary, create a Pentabarf account and activate it.
  Please reuse your account from previous years if you have
  already created 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 "Debugging Tools 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

** Recording of Talks

As usually 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).

** Code of Conduct

In order to keep FOSDEM a fun, interesting and positive experience
for everybody, we expect participants to follow our guidelines:
https://fosdem.org/2020/practical/conduct/

** Important dates

  Talk/Discussion Submission deadline: Sunday        1 Dec 2019
  Devroom Schedule announcement:       Sunday       15 Dec 2019
  Devroom day:                         Sunday        3 Feb 2020

Hope to see you all at FOSDEM 2020 in the joint Debugging Tools
devroom. Brussels (Belgium), Sunday February 2 2020.
_______________________________________________
FOSDEM mailing list
FO...@li...
https://lists.fosdem.org/listinfo/fosdem

Re: [Valgrind-users] Issues installing valgrind 3.15.0

[Salman A. <sal...@gm...>]

HI guys,

thanks for your help... compiling didnt work so I just downloaded and
installed a deb package of valgrind 3.15 and its working fine

On Mon, Sep 30, 2019 at 4:34 PM Alan Corey <ala...@gm...> wrote:

> In Debian I'm just using the Valgrind that's in the debs (packages):
>
> dpkg-query -l | grep -i valgrind
> ii  valgrind                               1:3.12.0~svn20160714-1+b1
>              arm64        instrumentation framework for building
> dynamic analysis tools
> ii  valgrind-dbg                           1:3.12.0~svn20160714-1+b1
>              arm64        instrumentation framework for building
> dynamic analysis tools (debug)
> ii  valkyrie                               2.0.0-1+b1
>              arm64        open-source graphical user interface for the
> Valgrind
>
>
> On 9/30/19, Alan Corey <ala...@gm...> wrote:
> > I'm not sure which of those you'd want, but you can try
> > CFLAGS="-I<some path>" ./configure
> >
> > Or if it uses cmake it would be a -D define and poke around in your cache
> >
> > -I will add a directory, -i (lowercase) will add a specific file, and
> > yes it's stuff that's going to make.  Not for arch, just for finding
> > stuff
> >
> > On 9/30/19, Salman Ahmed <sal...@gm...> wrote:
> >> on my machine I have
> >> /usr/arm-linux-gnueabi/include/asm/types.h
> >> /usr/include/x86_64-linux-gnu/asm/types.h
> >>
> >> and a  lot of dirs inside -> /usr/src/linux-headers-4.15.0-24/arch/
> >>
> >> e.g.) /usr/src/linux-headers-4.15.0-24/arch/alpha/include/asm/types.h
> >> /usr/src/linux-headers-4.15.0-24/arch/alpha/include/uapi/asm/types.h
> >> /usr/src/linux-headers-4.15.0-24/arch/arm/include/uapi/asm/types.h
> >> etc
> >>
> >> Do I need to make with some special "make ARCH="? I thought running
> >> ./configure would set that up
> >>
> >>
> >>
> >>
> >> On Mon, Sep 30, 2019 at 6:37 PM Salman Ahmed <sal...@gm...>
> >> wrote:
> >>
> >>> on my machine I have
> >>>
> >>>
> >>> On Mon, Sep 30, 2019 at 6:31 PM João M. S. Silva <
> >>> joa...@gm...> wrote:
> >>>
> >>>> I just used a Linux Mint VM:
> >>>>
> >>>> Other than Linux headers I only get this:
> >>>>
> >>>> $ dpkg -S /usr/include/x86_64-linux-gnu/asm/types.h
> >>>> linux-libc-dev:amd64: /usr/include/x86_64-linux-gnu/asm/types.h
> >>>>
> >>>> Should be package linux-libc-dev.
> >>>>
> >>>> João M. S. Silva
> >>>>
> >>>> On Mon, Sep 30, 2019 at 2:18 PM Alan Corey <ala...@gm...>
> wrote:
> >>>> >
> >>>> > You're missing asm/types.h
> >>>> >
> >>>> > Not sure what it's part of because there are 1 or 2 other types.h
> >>>> > files too. Somewhere in build-essentials or kernel building stuff I
> >>>> > picked it up.  Try your kernel headers package I see:
> >>>> >
> >>>> > locate asm/types.h
> >>>> > /usr/include/aarch64-linux-gnu/asm/types.h
> >>>> > /usr/src/linux-headers-4.9.177+/arch/arm/include/asm/types.h
> >>>> >
> /usr/src/linux-headers-4.9.177+/arch/arm64/include/generated/asm/types.h
> >>>> > /usr/src/linux-headers-4.9.177+/include/asm/types.h
> >>>> >
> >>>> >
> >>>> > On 9/30/19, Salman Ahmed <sal...@gm...> wrote:
> >>>> > > Hello,
> >>>> > >
> >>>> > > I am getting the following error when I try to install valgrind on
> >>>> > > my
> >>>> > > machine (ubuntu 16.04)
> >>>> > > 1) ./configure
> >>>> > > 2) make
> >>>> > >   In file included from /usr/include/linux/prctl.h:4:0,
> >>>> > >                  from /usr/include/sys/prctl.h:22,
> >>>> > >                  from m_gdbserver/remote-utils.c:34:
> >>>> > > /usr/include/linux/types.h:4:23: fatal error: asm/types.h: No such
> >>>> file or
> >>>> > > directory
> >>>> > > compilation terminated.
> >>>> > > Makefile:7078: recipe for target
> >>>> > > 'm_gdbserver/libcoregrind_x86_linux_a-remote-utils.o' failed
> >>>> > >
> >>>> > > I tried to google anything related to this error but havnt been
> >>>> > > able
> >>>> to fix
> >>>> > > the issue.
> >>>> > >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > -------------
> >>>> > No, I won't  call it "climate change", do you have a "reality
> >>>> > problem"?
> >>>> - AB1JX
> >>>> > Cities are cages built to contain excess people and keep them from
> >>>> > cluttering up nature.
> >>>> > Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
> >>>> > Impeach
> >>>> >
> >>>> >
> >>>> > _______________________________________________
> >>>> > Valgrind-users mailing list
> >>>> > Val...@li...
> >>>> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >>>>
> >>>
> >>
> >
> >
> > --
> > -------------
> > No, I won't  call it "climate change", do you have a "reality problem"? -
> > AB1JX
> > Cities are cages built to contain excess people and keep them from
> > cluttering up nature.
> > Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
> >
>
>
> --
> -------------
> No, I won't  call it "climate change", do you have a "reality problem"? -
> AB1JX
> Cities are cages built to contain excess people and keep them from
> cluttering up nature.
> Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
>

Re: [Valgrind-users] Issues installing valgrind 3.15.0

[Alan C. <ala...@gm...>]

In Debian I'm just using the Valgrind that's in the debs (packages):

dpkg-query -l | grep -i valgrind
ii  valgrind                               1:3.12.0~svn20160714-1+b1
             arm64        instrumentation framework for building
dynamic analysis tools
ii  valgrind-dbg                           1:3.12.0~svn20160714-1+b1
             arm64        instrumentation framework for building
dynamic analysis tools (debug)
ii  valkyrie                               2.0.0-1+b1
             arm64        open-source graphical user interface for the
Valgrind


On 9/30/19, Alan Corey <ala...@gm...> wrote:
> I'm not sure which of those you'd want, but you can try
> CFLAGS="-I<some path>" ./configure
>
> Or if it uses cmake it would be a -D define and poke around in your cache
>
> -I will add a directory, -i (lowercase) will add a specific file, and
> yes it's stuff that's going to make.  Not for arch, just for finding
> stuff
>
> On 9/30/19, Salman Ahmed <sal...@gm...> wrote:
>> on my machine I have
>> /usr/arm-linux-gnueabi/include/asm/types.h
>> /usr/include/x86_64-linux-gnu/asm/types.h
>>
>> and a  lot of dirs inside -> /usr/src/linux-headers-4.15.0-24/arch/
>>
>> e.g.) /usr/src/linux-headers-4.15.0-24/arch/alpha/include/asm/types.h
>> /usr/src/linux-headers-4.15.0-24/arch/alpha/include/uapi/asm/types.h
>> /usr/src/linux-headers-4.15.0-24/arch/arm/include/uapi/asm/types.h
>> etc
>>
>> Do I need to make with some special "make ARCH="? I thought running
>> ./configure would set that up
>>
>>
>>
>>
>> On Mon, Sep 30, 2019 at 6:37 PM Salman Ahmed <sal...@gm...>
>> wrote:
>>
>>> on my machine I have
>>>
>>>
>>> On Mon, Sep 30, 2019 at 6:31 PM João M. S. Silva <
>>> joa...@gm...> wrote:
>>>
>>>> I just used a Linux Mint VM:
>>>>
>>>> Other than Linux headers I only get this:
>>>>
>>>> $ dpkg -S /usr/include/x86_64-linux-gnu/asm/types.h
>>>> linux-libc-dev:amd64: /usr/include/x86_64-linux-gnu/asm/types.h
>>>>
>>>> Should be package linux-libc-dev.
>>>>
>>>> João M. S. Silva
>>>>
>>>> On Mon, Sep 30, 2019 at 2:18 PM Alan Corey <ala...@gm...> wrote:
>>>> >
>>>> > You're missing asm/types.h
>>>> >
>>>> > Not sure what it's part of because there are 1 or 2 other types.h
>>>> > files too. Somewhere in build-essentials or kernel building stuff I
>>>> > picked it up.  Try your kernel headers package I see:
>>>> >
>>>> > locate asm/types.h
>>>> > /usr/include/aarch64-linux-gnu/asm/types.h
>>>> > /usr/src/linux-headers-4.9.177+/arch/arm/include/asm/types.h
>>>> > /usr/src/linux-headers-4.9.177+/arch/arm64/include/generated/asm/types.h
>>>> > /usr/src/linux-headers-4.9.177+/include/asm/types.h
>>>> >
>>>> >
>>>> > On 9/30/19, Salman Ahmed <sal...@gm...> wrote:
>>>> > > Hello,
>>>> > >
>>>> > > I am getting the following error when I try to install valgrind on
>>>> > > my
>>>> > > machine (ubuntu 16.04)
>>>> > > 1) ./configure
>>>> > > 2) make
>>>> > >   In file included from /usr/include/linux/prctl.h:4:0,
>>>> > >                  from /usr/include/sys/prctl.h:22,
>>>> > >                  from m_gdbserver/remote-utils.c:34:
>>>> > > /usr/include/linux/types.h:4:23: fatal error: asm/types.h: No such
>>>> file or
>>>> > > directory
>>>> > > compilation terminated.
>>>> > > Makefile:7078: recipe for target
>>>> > > 'm_gdbserver/libcoregrind_x86_linux_a-remote-utils.o' failed
>>>> > >
>>>> > > I tried to google anything related to this error but havnt been
>>>> > > able
>>>> to fix
>>>> > > the issue.
>>>> > >
>>>> >
>>>> >
>>>> > --
>>>> > -------------
>>>> > No, I won't  call it "climate change", do you have a "reality
>>>> > problem"?
>>>> - AB1JX
>>>> > Cities are cages built to contain excess people and keep them from
>>>> > cluttering up nature.
>>>> > Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
>>>> > Impeach
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Valgrind-users mailing list
>>>> > Val...@li...
>>>> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>>>
>>>
>>
>
>
> --
> -------------
> No, I won't  call it "climate change", do you have a "reality problem"? -
> AB1JX
> Cities are cages built to contain excess people and keep them from
> cluttering up nature.
> Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: [Valgrind-users] Issues installing valgrind 3.15.0

[Alan C. <ala...@gm...>]

I'm not sure which of those you'd want, but you can try
CFLAGS="-I<some path>" ./configure

Or if it uses cmake it would be a -D define and poke around in your cache

-I will add a directory, -i (lowercase) will add a specific file, and
yes it's stuff that's going to make.  Not for arch, just for finding
stuff

On 9/30/19, Salman Ahmed <sal...@gm...> wrote:
> on my machine I have
> /usr/arm-linux-gnueabi/include/asm/types.h
> /usr/include/x86_64-linux-gnu/asm/types.h
>
> and a  lot of dirs inside -> /usr/src/linux-headers-4.15.0-24/arch/
>
> e.g.) /usr/src/linux-headers-4.15.0-24/arch/alpha/include/asm/types.h
> /usr/src/linux-headers-4.15.0-24/arch/alpha/include/uapi/asm/types.h
> /usr/src/linux-headers-4.15.0-24/arch/arm/include/uapi/asm/types.h
> etc
>
> Do I need to make with some special "make ARCH="? I thought running
> ./configure would set that up
>
>
>
>
> On Mon, Sep 30, 2019 at 6:37 PM Salman Ahmed <sal...@gm...> wrote:
>
>> on my machine I have
>>
>>
>> On Mon, Sep 30, 2019 at 6:31 PM João M. S. Silva <
>> joa...@gm...> wrote:
>>
>>> I just used a Linux Mint VM:
>>>
>>> Other than Linux headers I only get this:
>>>
>>> $ dpkg -S /usr/include/x86_64-linux-gnu/asm/types.h
>>> linux-libc-dev:amd64: /usr/include/x86_64-linux-gnu/asm/types.h
>>>
>>> Should be package linux-libc-dev.
>>>
>>> João M. S. Silva
>>>
>>> On Mon, Sep 30, 2019 at 2:18 PM Alan Corey <ala...@gm...> wrote:
>>> >
>>> > You're missing asm/types.h
>>> >
>>> > Not sure what it's part of because there are 1 or 2 other types.h
>>> > files too. Somewhere in build-essentials or kernel building stuff I
>>> > picked it up.  Try your kernel headers package I see:
>>> >
>>> > locate asm/types.h
>>> > /usr/include/aarch64-linux-gnu/asm/types.h
>>> > /usr/src/linux-headers-4.9.177+/arch/arm/include/asm/types.h
>>> > /usr/src/linux-headers-4.9.177+/arch/arm64/include/generated/asm/types.h
>>> > /usr/src/linux-headers-4.9.177+/include/asm/types.h
>>> >
>>> >
>>> > On 9/30/19, Salman Ahmed <sal...@gm...> wrote:
>>> > > Hello,
>>> > >
>>> > > I am getting the following error when I try to install valgrind on
>>> > > my
>>> > > machine (ubuntu 16.04)
>>> > > 1) ./configure
>>> > > 2) make
>>> > >   In file included from /usr/include/linux/prctl.h:4:0,
>>> > >                  from /usr/include/sys/prctl.h:22,
>>> > >                  from m_gdbserver/remote-utils.c:34:
>>> > > /usr/include/linux/types.h:4:23: fatal error: asm/types.h: No such
>>> file or
>>> > > directory
>>> > > compilation terminated.
>>> > > Makefile:7078: recipe for target
>>> > > 'm_gdbserver/libcoregrind_x86_linux_a-remote-utils.o' failed
>>> > >
>>> > > I tried to google anything related to this error but havnt been able
>>> to fix
>>> > > the issue.
>>> > >
>>> >
>>> >
>>> > --
>>> > -------------
>>> > No, I won't  call it "climate change", do you have a "reality
>>> > problem"?
>>> - AB1JX
>>> > Cities are cages built to contain excess people and keep them from
>>> > cluttering up nature.
>>> > Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
>>> >
>>> >
>>> > _______________________________________________
>>> > Valgrind-users mailing list
>>> > Val...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>>
>>
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: [Valgrind-users] Issues installing valgrind 3.15.0

[Salman A. <sal...@gm...>]

on my machine I have
/usr/arm-linux-gnueabi/include/asm/types.h
/usr/include/x86_64-linux-gnu/asm/types.h

and a  lot of dirs inside -> /usr/src/linux-headers-4.15.0-24/arch/

e.g.) /usr/src/linux-headers-4.15.0-24/arch/alpha/include/asm/types.h
/usr/src/linux-headers-4.15.0-24/arch/alpha/include/uapi/asm/types.h
/usr/src/linux-headers-4.15.0-24/arch/arm/include/uapi/asm/types.h
etc

Do I need to make with some special "make ARCH="? I thought running
./configure would set that up




On Mon, Sep 30, 2019 at 6:37 PM Salman Ahmed <sal...@gm...> wrote:

> on my machine I have
>
>
> On Mon, Sep 30, 2019 at 6:31 PM João M. S. Silva <
> joa...@gm...> wrote:
>
>> I just used a Linux Mint VM:
>>
>> Other than Linux headers I only get this:
>>
>> $ dpkg -S /usr/include/x86_64-linux-gnu/asm/types.h
>> linux-libc-dev:amd64: /usr/include/x86_64-linux-gnu/asm/types.h
>>
>> Should be package linux-libc-dev.
>>
>> João M. S. Silva
>>
>> On Mon, Sep 30, 2019 at 2:18 PM Alan Corey <ala...@gm...> wrote:
>> >
>> > You're missing asm/types.h
>> >
>> > Not sure what it's part of because there are 1 or 2 other types.h
>> > files too. Somewhere in build-essentials or kernel building stuff I
>> > picked it up.  Try your kernel headers package I see:
>> >
>> > locate asm/types.h
>> > /usr/include/aarch64-linux-gnu/asm/types.h
>> > /usr/src/linux-headers-4.9.177+/arch/arm/include/asm/types.h
>> > /usr/src/linux-headers-4.9.177+/arch/arm64/include/generated/asm/types.h
>> > /usr/src/linux-headers-4.9.177+/include/asm/types.h
>> >
>> >
>> > On 9/30/19, Salman Ahmed <sal...@gm...> wrote:
>> > > Hello,
>> > >
>> > > I am getting the following error when I try to install valgrind on my
>> > > machine (ubuntu 16.04)
>> > > 1) ./configure
>> > > 2) make
>> > >   In file included from /usr/include/linux/prctl.h:4:0,
>> > >                  from /usr/include/sys/prctl.h:22,
>> > >                  from m_gdbserver/remote-utils.c:34:
>> > > /usr/include/linux/types.h:4:23: fatal error: asm/types.h: No such
>> file or
>> > > directory
>> > > compilation terminated.
>> > > Makefile:7078: recipe for target
>> > > 'm_gdbserver/libcoregrind_x86_linux_a-remote-utils.o' failed
>> > >
>> > > I tried to google anything related to this error but havnt been able
>> to fix
>> > > the issue.
>> > >
>> >
>> >
>> > --
>> > -------------
>> > No, I won't  call it "climate change", do you have a "reality problem"?
>> - AB1JX
>> > Cities are cages built to contain excess people and keep them from
>> > cluttering up nature.
>> > Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
>> >
>> >
>> > _______________________________________________
>> > Valgrind-users mailing list
>> > Val...@li...
>> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>

Re: [Valgrind-users] Issues installing valgrind 3.15.0

[Salman A. <sal...@gm...>]

on my machine I have


On Mon, Sep 30, 2019 at 6:31 PM João M. S. Silva <
joa...@gm...> wrote:

> I just used a Linux Mint VM:
>
> Other than Linux headers I only get this:
>
> $ dpkg -S /usr/include/x86_64-linux-gnu/asm/types.h
> linux-libc-dev:amd64: /usr/include/x86_64-linux-gnu/asm/types.h
>
> Should be package linux-libc-dev.
>
> João M. S. Silva
>
> On Mon, Sep 30, 2019 at 2:18 PM Alan Corey <ala...@gm...> wrote:
> >
> > You're missing asm/types.h
> >
> > Not sure what it's part of because there are 1 or 2 other types.h
> > files too. Somewhere in build-essentials or kernel building stuff I
> > picked it up.  Try your kernel headers package I see:
> >
> > locate asm/types.h
> > /usr/include/aarch64-linux-gnu/asm/types.h
> > /usr/src/linux-headers-4.9.177+/arch/arm/include/asm/types.h
> > /usr/src/linux-headers-4.9.177+/arch/arm64/include/generated/asm/types.h
> > /usr/src/linux-headers-4.9.177+/include/asm/types.h
> >
> >
> > On 9/30/19, Salman Ahmed <sal...@gm...> wrote:
> > > Hello,
> > >
> > > I am getting the following error when I try to install valgrind on my
> > > machine (ubuntu 16.04)
> > > 1) ./configure
> > > 2) make
> > >   In file included from /usr/include/linux/prctl.h:4:0,
> > >                  from /usr/include/sys/prctl.h:22,
> > >                  from m_gdbserver/remote-utils.c:34:
> > > /usr/include/linux/types.h:4:23: fatal error: asm/types.h: No such
> file or
> > > directory
> > > compilation terminated.
> > > Makefile:7078: recipe for target
> > > 'm_gdbserver/libcoregrind_x86_linux_a-remote-utils.o' failed
> > >
> > > I tried to google anything related to this error but havnt been able
> to fix
> > > the issue.
> > >
> >
> >
> > --
> > -------------
> > No, I won't  call it "climate change", do you have a "reality problem"?
> - AB1JX
> > Cities are cages built to contain excess people and keep them from
> > cluttering up nature.
> > Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
> >
> >
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] Issues installing valgrind 3.15.0

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

I just used a Linux Mint VM:

Other than Linux headers I only get this:

$ dpkg -S /usr/include/x86_64-linux-gnu/asm/types.h
linux-libc-dev:amd64: /usr/include/x86_64-linux-gnu/asm/types.h

Should be package linux-libc-dev.

João M. S. Silva

On Mon, Sep 30, 2019 at 2:18 PM Alan Corey <ala...@gm...> wrote:
>
> You're missing asm/types.h
>
> Not sure what it's part of because there are 1 or 2 other types.h
> files too. Somewhere in build-essentials or kernel building stuff I
> picked it up.  Try your kernel headers package I see:
>
> locate asm/types.h
> /usr/include/aarch64-linux-gnu/asm/types.h
> /usr/src/linux-headers-4.9.177+/arch/arm/include/asm/types.h
> /usr/src/linux-headers-4.9.177+/arch/arm64/include/generated/asm/types.h
> /usr/src/linux-headers-4.9.177+/include/asm/types.h
>
>
> On 9/30/19, Salman Ahmed <sal...@gm...> wrote:
> > Hello,
> >
> > I am getting the following error when I try to install valgrind on my
> > machine (ubuntu 16.04)
> > 1) ./configure
> > 2) make
> >   In file included from /usr/include/linux/prctl.h:4:0,
> >                  from /usr/include/sys/prctl.h:22,
> >                  from m_gdbserver/remote-utils.c:34:
> > /usr/include/linux/types.h:4:23: fatal error: asm/types.h: No such file or
> > directory
> > compilation terminated.
> > Makefile:7078: recipe for target
> > 'm_gdbserver/libcoregrind_x86_linux_a-remote-utils.o' failed
> >
> > I tried to google anything related to this error but havnt been able to fix
> > the issue.
> >
>
>
> --
> -------------
> No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
> Cities are cages built to contain excess people and keep them from
> cluttering up nature.
> Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Issues installing valgrind 3.15.0

[Alan C. <ala...@gm...>]

You're missing asm/types.h

Not sure what it's part of because there are 1 or 2 other types.h
files too. Somewhere in build-essentials or kernel building stuff I
picked it up.  Try your kernel headers package I see:

locate asm/types.h
/usr/include/aarch64-linux-gnu/asm/types.h
/usr/src/linux-headers-4.9.177+/arch/arm/include/asm/types.h
/usr/src/linux-headers-4.9.177+/arch/arm64/include/generated/asm/types.h
/usr/src/linux-headers-4.9.177+/include/asm/types.h


On 9/30/19, Salman Ahmed <sal...@gm...> wrote:
> Hello,
>
> I am getting the following error when I try to install valgrind on my
> machine (ubuntu 16.04)
> 1) ./configure
> 2) make
>   In file included from /usr/include/linux/prctl.h:4:0,
>                  from /usr/include/sys/prctl.h:22,
>                  from m_gdbserver/remote-utils.c:34:
> /usr/include/linux/types.h:4:23: fatal error: asm/types.h: No such file or
> directory
> compilation terminated.
> Makefile:7078: recipe for target
> 'm_gdbserver/libcoregrind_x86_linux_a-remote-utils.o' failed
>
> I tried to google anything related to this error but havnt been able to fix
> the issue.
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

[Valgrind-users] Issues installing valgrind 3.15.0

[Salman A. <sal...@gm...>]

Hello,

I am getting the following error when I try to install valgrind on my
machine (ubuntu 16.04)
1) ./configure
2) make
  In file included from /usr/include/linux/prctl.h:4:0,
                 from /usr/include/sys/prctl.h:22,
                 from m_gdbserver/remote-utils.c:34:
/usr/include/linux/types.h:4:23: fatal error: asm/types.h: No such file or
directory
compilation terminated.
Makefile:7078: recipe for target
'm_gdbserver/libcoregrind_x86_linux_a-remote-utils.o' failed

I tried to google anything related to this error but havnt been able to fix
the issue.

Re: [Valgrind-users] No Git tag for v3.15.0

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

Hi Mark,

 > Julian would you mind creating a signed tag for this commit?
 > Using the same pgp key you used to sign the release tar ball?
 >
 > git tag -s -m "valgrind 3.15.0 release" VALGRIND_3_15_0 \
 >      608cb11914e5f23d0fc12c61dad29c5c7952a1de
 > git push --tags

Done!

J

Re: [Valgrind-users] seemingly bogus error reports

[Fred S. <fs...@co...>]

John, thanks for the reply!

Actually, that was run with track-origins. I seem to recall a few years ago it gave more detail than it is now. This is 3.15, latest released version.

I wish I could debug into those Oracle libraries, it would make it a lot easier to track what it's complaining about.


I asked about bogus error messages because I saw a comment in the user doc about sometimes Valgrind produces erroneous messages, and I was hoping to find out if this might be one of them, given the difficulty of tracking down whatever the complaint is about. ☹

Fred

> -----Original Message-----
> From: John Reiser <jr...@bi...>
> Sent: Saturday, September 14, 2019 11:20 PM
> To: val...@li...
> Subject: Re: [Valgrind-users] seemingly bogus error reports
>
> >> ==00:00:00:11.329 1533== Conditional jump or move depends on
> >> uninitialised value(s)
> >> ==00:00:00:11.329 1533==    at 0x7B0BCC2: ttci2n (in
> >> /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
>      [[snip]]
> >> ==00:00:00:11.329 1533==  Uninitialised value was created by a stack
> >> allocation
> >> ==00:00:00:11.329 1533==    at 0x407C67: HS_send2HS
> >> (HS_thr_out.c:231)
>
> >> The problem with that report is that line 231 contains no explicit code:
> >> static HS_IF_STATE HS_send2HS (HS_out_thread * myoutthr,
>      [[snip]]
> >> { ç line 231
>
> >> I can’t find anything that’s allocated in that function that would be
> >> un-initialized later in the program,
>
> As David Chapman replied earlier, then line 231 is the place where the
> compiler constructed the stack frame.
>
> Some local variable might be the destination of an assignment or copy from
> an uninit variable.  In order to help find this, then re-run with the valgrind
> command-line option
>      --track-origins=yes
> which should give more information about the provenance of the uninit
> value.
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.
> sourceforge.net%2Flists%2Flistinfo%2Fvalgrind-
> users&amp;data=01%7C01%7Cfsmith%40computrition.com%7C22bc32ce525
> d4d77a75508d7398bd996%7C3b4088f40055447db060d8040059e8f9%7C0&am
> p;sdata=nptwy1yjpQIBttwRW4kryi0m38saSmFNQi3i2lY7UAI%3D&amp;reserv
> ed=0
CONFIDENTIALITY NOTICE: This message and attachments included are intended only for the addressee (s). The information contained in this message is confidential and may constitute proprietary or non-public information under international, federal, and/or state laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee(s), please promptly delete this message and notify the sender of the delivery error by e-mail.

Re: [Valgrind-users] seemingly bogus error reports

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

>> ==00:00:00:11.329 1533== Conditional jump or move depends on uninitialised value(s)
>> ==00:00:00:11.329 1533==    at 0x7B0BCC2: ttci2n (in /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
     [[snip]]
>> ==00:00:00:11.329 1533==  Uninitialised value was created by a stack allocation
>> ==00:00:00:11.329 1533==    at 0x407C67: HS_send2HS (HS_thr_out.c:231)

>> The problem with that report is that line 231 contains no explicit code:
>> static HS_IF_STATE HS_send2HS (HS_out_thread * myoutthr,
     [[snip]]
>> { ç line 231

>> I can’t find anything that’s allocated in that function that would be un-initialized later in the program,

As David Chapman replied earlier, then line 231 is the place where the compiler
constructed the stack frame.

Some local variable might be the destination of an assignment or copy from an
uninit variable.  In order to help find this, then re-run with the valgrind
command-line option
     --track-origins=yes
which should give more information about the provenance of the uninit value.

Re: [Valgrind-users] seemingly bogus error reports

[David C. <dcc...@ac...>]

On 9/14/2019 12:11 PM, Fred Smith wrote:
>
> Hi all!
>
> I’m new to this list, but have used Valgrind many times in the past.
>
> Today I’m making a serious effort to clean up a non-trivial body of 
> code, and have run into a number of error reports like this one:
>
> ==00:00:00:11.329 1533== Conditional jump or move depends on 
> uninitialised value(s)
>
> ==00:00:00:11.329 1533==    at 0x7B0BCC2: ttci2n (in 
> /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
>
> ==00:00:00:11.329 1533==    by 0x7B20DF5: ttcacs (in 
> /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
>
> ==00:00:00:11.329 1533==    by 0x7AF2503: ttcdrv (in 
> /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
>
> ==00:00:00:11.329 1533==    by 0x7AE14C8: nioqwa (in 
> /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
>
> ==00:00:00:11.329 1533==    by 0x7AC35CB: upirtrc (in 
> /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
>
> ==00:00:00:11.329 1533==    by 0x7ACDDE5: kpurcsc (in 
> /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
>
> ==00:00:00:11.329 1533==    by 0x7AC710D: kpuexec (in 
> /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
>
> ==00:00:00:11.329 1533==    by 0x7AC3F78: OCIStmtExecute (in 
> /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
>
> ==00:00:00:11.329 1533==    by 0x45078D: HS_do_OCI_stuff (HS_oci.c:1460)
>
> ==00:00:00:11.329 1533==    by 0x407DA0: HS_send2HS (HS_thr_out.c:261)
>
> ==00:00:00:11.329 1533==    by 0x4083BB: HS_convertandsend 
> (HS_thr_out.c:468)
>
> ==00:00:00:11.329 1533==    by 0x40884E: HS_out_msg (HS_thr_out.c:629)
>
> ==00:00:00:11.329 1533==    by 0x40913C: HS_out_main (HS_thr_out.c:933)
>
> ==00:00:00:11.329 1533==    by 0x409797: HS_main_out (HS_thr_out.c:1172)
>
> ==00:00:00:11.329 1533==    by 0x9C50DD4: start_thread 
> (pthread_create.c:307)
>
> ==00:00:00:11.329 1533==  Uninitialised value was created by a stack 
> allocation
>
> ==00:00:00:11.329 1533==    at 0x407C67: HS_send2HS (HS_thr_out.c:231)
>
> ==00:00:00:11.329 1533==
>
> The problem with that report is that line 231 contains no explicit code:
>
> static HS_IF_STATE HS_send2HS (HS_out_thread * myoutthr,
>
>                                 HS_MSGBUF * msgbuf,
>
>                                 HS_IF_PARMS * ifparms,
>
>                                 xmlChar * xmlbufptr,
>
>                                 char * HS_resp,
>
>                                 HS_patdat * patdat,
>
>                                 char * databuf)
>
> { ç line 231
>
>                 HS_IF_STATE status = OK;
>
>                 int success, warnings;
>
>                 int numtries = 0
>
> I can’t find anything that’s allocated in that function that would be 
> un-initialized later in the program, and I don’t know what it thinks 
> is on line 231.
>
> Advice will be appreciated, thanks in advance!
>

The allocation is probably in the function's stack frame, which would be 
set up at function entry.  The compiler probably assigned line 231 to 
that task.  I see line 261 in your call stack; what local variables does 
it use?

-- 
     David Chapman      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     EDA Software Developer, Expert Witness
     www.chapman-consulting-sj.com
     2018-2019 Chair, IEEE Consultants' Network of Silicon Valley

[Valgrind-users] seemingly bogus error reports

[Fred S. <fs...@co...>]

Hi all!

I'm new to this list, but have used Valgrind many times in the past.

Today I'm making a serious effort to clean up a non-trivial body of code, and have run into a number of error reports like this one:

==00:00:00:11.329 1533== Conditional jump or move depends on uninitialised value(s)
==00:00:00:11.329 1533==    at 0x7B0BCC2: ttci2n (in /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
==00:00:00:11.329 1533==    by 0x7B20DF5: ttcacs (in /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
==00:00:00:11.329 1533==    by 0x7AF2503: ttcdrv (in /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
==00:00:00:11.329 1533==    by 0x7AE14C8: nioqwa (in /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
==00:00:00:11.329 1533==    by 0x7AC35CB: upirtrc (in /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
==00:00:00:11.329 1533==    by 0x7ACDDE5: kpurcsc (in /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
==00:00:00:11.329 1533==    by 0x7AC710D: kpuexec (in /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
==00:00:00:11.329 1533==    by 0x7AC3F78: OCIStmtExecute (in /home/interface/interface/oralib-12/lib/libclntsh.so.12.1)
==00:00:00:11.329 1533==    by 0x45078D: HS_do_OCI_stuff (HS_oci.c:1460)
==00:00:00:11.329 1533==    by 0x407DA0: HS_send2HS (HS_thr_out.c:261)
==00:00:00:11.329 1533==    by 0x4083BB: HS_convertandsend (HS_thr_out.c:468)
==00:00:00:11.329 1533==    by 0x40884E: HS_out_msg (HS_thr_out.c:629)
==00:00:00:11.329 1533==    by 0x40913C: HS_out_main (HS_thr_out.c:933)
==00:00:00:11.329 1533==    by 0x409797: HS_main_out (HS_thr_out.c:1172)
==00:00:00:11.329 1533==    by 0x9C50DD4: start_thread (pthread_create.c:307)
==00:00:00:11.329 1533==  Uninitialised value was created by a stack allocation
==00:00:00:11.329 1533==    at 0x407C67: HS_send2HS (HS_thr_out.c:231)
==00:00:00:11.329 1533==

The problem with that report is that line 231 contains no explicit code:

static HS_IF_STATE HS_send2HS (HS_out_thread * myoutthr,
                                HS_MSGBUF * msgbuf,
                                HS_IF_PARMS * ifparms,
                                xmlChar * xmlbufptr,
                                char * HS_resp,
                                HS_patdat * patdat,
                                char * databuf)
                {                                                              <== line 231
                HS_IF_STATE status = OK;
                int success, warnings;
                int numtries = 0

I can't find anything that's allocated in that function that would be un-initialized later in the program, and I don't know what it thinks is on line 231.

Advice will be appreciated, thanks in advance!

Fred


CONFIDENTIALITY NOTICE: This message and attachments included are intended only for the addressee (s). The information contained in this message is confidential and may constitute proprietary or non-public information under international, federal, and/or state laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee(s), please promptly delete this message and notify the sender of the delivery error by e-mail.