valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.20.0.RC1 is available for testing

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

On Sun, 2022-10-23 at 00:11 +0200, Mark Wielaard wrote:
> Hi Philippe,
> 
> On Sat, Oct 22, 2022 at 02:58:28PM +0200, Philippe Waroquiers wrote:
> > I have started running valgrind on valgrind (outer/inner setup).
> > Results should be available tomorrow evening or so ...
> > For the first few tests, seems ok.
> > 
> > Just one strange thing:
> > The outer valgrind crashes on the below test (while the native run of this test is ok).
> > (this is on gcc farm gcc186).
> > 
> > Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode,
> > but would not be ok when the same valgrind runs as an outer.
> > In any case, this is not blocking.
> > 
> > More complete results will follow ...
> 
> Thanks. I have no theory for the outer valgrind crash. But it doesn't
> seem blocking indeed. I am also still running some tests. Please let
> me know of further results. And do the actual release on Monday
> (unless some regression blocker turns up).
> 
> Cheers,
> 
> Mark
> 

For the crash of the outer valgrind: there is in fact some debug info really
missing on gcc186 (also for the inner) for the 32 bits version.

I have looked at the results of this outer/inner setup and found nothing that
seems problematic.

Note that analysis the outer logs is always painful, as the outer reports as "bugs"
the fact the inner uses e.g. some invalid memory because the guest
program run by the inner is designed to test the usage of such invalid memory.

Thanks
Philippe

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.20.0.RC1 is available for testing

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

Hi Philippe,

On Sat, Oct 22, 2022 at 02:58:28PM +0200, Philippe Waroquiers wrote:
> I have started running valgrind on valgrind (outer/inner setup).
> Results should be available tomorrow evening or so ...
> For the first few tests, seems ok.
> 
> Just one strange thing:
> The outer valgrind crashes on the below test (while the native run of this test is ok).
> (this is on gcc farm gcc186).
> 
> Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode,
> but would not be ok when the same valgrind runs as an outer.
> In any case, this is not blocking.
> 
> More complete results will follow ...

Thanks. I have no theory for the outer valgrind crash. But it doesn't
seem blocking indeed. I am also still running some tests. Please let
me know of further results. And do the actual release on Monday
(unless some regression blocker turns up).

Cheers,

Mark

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.20.0.RC1 is available for testing

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

Hi,

On Thu, Oct 20, 2022 at 01:25:44PM -0700, Carl Love wrote:
> The only issue noted, as discussed on #valgrind-dev channel, is the
> addition of four post errors for the 3.20RC tree on all of the Power
> platforms.  Specifically:
> 
> cachegrind/tests/ann1                    (post)
> cachegrind/tests/ann2                    (post)
> callgrind/tests/ann1                     (post)
> callgrind/tests/ann2                     (post)
> 
> The output from  cachegrind/tests/ann1.post.diff is:
> 
> --- ann1.post.exp	2021-01-21 09:09:33.000000000 -0600
> +++ ann1.post.out	2022-10-20 14:07:33.272141328 -0500
> @@ -33,6 +33,13 @@
>  --------------------------------------------------------------------
> -----------
> -
>  -- Auto-annotated source: a.c
>  --------------------------------------------------------------------
> -----------
> -
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +@@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@
> WARNING @@
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +@ Source file 'a.c' is more recent than input file 'cgout-test'.
> +@ Annotations may not be correct.
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +
>  Ir        I1mr ILmr 
>  
>          2    0    0  int main(void) {
> 
> As discussed on the #valgrind-dev channel, this appears to be a
> timestamp issue.  Doing a touch * in directory cachegrind/tests seems
> to fix all four post errors.
> 
> No other issues were noted.  I would vote to do the touch * command and
> go ahead with the release.

I added the touch to the testcases as attached. That makes sure the
cgout-test file is always newer.

Cheers,

Mark

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.20.0.RC1 is available for testing

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

I have started running valgrind on valgrind (outer/inner setup).
Results should be available tomorrow evening or so ...
For the first few tests, seems ok.

Just one strange thing:
The outer valgrind crashes on the below test (while the native run of this test is ok).
(this is on gcc farm gcc186).

Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode,
but would not be ok when the same valgrind runs as an outer.
In any case, this is not blocking.

More complete results will follow ...

Philippe

cachegrind/tests/x86/fpu-28-108.outer.log:10:valgrind:  Fatal error at startup: a function redirection
cachegrind/tests/x86/fpu-28-108.outer.log:11:valgrind:  which is mandatory for this platform-tool combination
cachegrind/tests/x86/fpu-28-108.outer.log:12:valgrind:  cannot be set up.  Details of the redirection are:
cachegrind/tests/x86/fpu-28-108.outer.log:13:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:14:valgrind:  A must-be-redirected function
cachegrind/tests/x86/fpu-28-108.outer.log:15:valgrind:  whose name matches the pattern:      strlen
cachegrind/tests/x86/fpu-28-108.outer.log:16:valgrind:  in an object with soname matching:   ld-linux.so.2
cachegrind/tests/x86/fpu-28-108.outer.log:17:valgrind:  was not found whilst processing
cachegrind/tests/x86/fpu-28-108.outer.log:18:valgrind:  symbols from the object with soname: ld-linux.so.2
cachegrind/tests/x86/fpu-28-108.outer.log:19:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:20:valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
cachegrind/tests/x86/fpu-28-108.outer.log:21:valgrind:  package on this machine.  (2, longer term): ask the packagers
cachegrind/tests/x86/fpu-28-108.outer.log:22:valgrind:  for your Linux distribution to please in future ship a non-
cachegrind/tests/x86/fpu-28-108.outer.log:23:valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
cachegrind/tests/x86/fpu-28-108.outer.log:24:valgrind:  that exports the above-named function using the standard
cachegrind/tests/x86/fpu-28-108.outer.log:25:valgrind:  calling conventions for this platform.  The package you need
cachegrind/tests/x86/fpu-28-108.outer.log:26:valgrind:  to install for fix (1) is called
cachegrind/tests/x86/fpu-28-108.outer.log:27:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:28:valgrind:    On Debian, Ubuntu:                 libc6-dbg
cachegrind/tests/x86/fpu-28-108.outer.log:29:valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
cachegrind/tests/x86/fpu-28-108.outer.log:30:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:31:valgrind:  Note that if you are debugging a 32 bit process on a
cachegrind/tests/x86/fpu-28-108.outer.log:32:valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
cachegrind/tests/x86/fpu-28-108.outer.log:33:valgrind:  package (e.g. libc6-dbg:i386).
cachegrind/tests/x86/fpu-28-108.outer.log:34:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:35:valgrind:  Cannot continue -- exiting now.  Sorry.

On Thu, 2022-10-20 at 01:52 +0200, Mark Wielaard wrote:
> Greetings.
> 
> A first release candidate for 3.20.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
> (md5 = 981b9276536843090700c1268549186e)
> 
> Please give it a try on platforms that are important for you.  If no
> serious issues are reported, the 3.20.0 final release will happen on
> 22 October.
> 
> 
> 
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers

Re: [Valgrind-users] Valgrind-3.20.0.RC1 is available for testing

[Mathieu M. <ma...@de...>]

Hi there,

On Thu, Oct 20, 2022 at 9:16 PM Paul Floyd <pj...@wa...> wrote:
>
>
>
> On 10/20/22 01:52, Mark Wielaard wrote:
> > Greetings.
> >
> > A first release candidate for 3.20.0 is available at
> > https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
> > (md5 = 981b9276536843090700c1268549186e)
> >
> > Please give it a try on platforms that are important for you.  If no
> > serious issues are reported, the 3.20.0 final release will happen on
> > 22 October.
>

Could someone apply the following patch:

sed -i -e 's/cortex-a8/generic-armv7-a/g' Makefile.all.am

ref:
https://bugs.kde.org/show_bug.cgi?id=456200

Thanks & Regards

Re: [Valgrind-users] Valgrind-3.20.0.RC1 is available for testing

[Paul F. <pj...@wa...>]

On 10/20/22 01:52, Mark Wielaard wrote:
> Greetings.
> 
> A first release candidate for 3.20.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
> (md5 = 981b9276536843090700c1268549186e)
> 
> Please give it a try on platforms that are important for you.  If no
> serious issues are reported, the 3.20.0 final release will happen on
> 22 October.

Hi

And finally, macOS. On my old macbook (10.7) there was a build error 
that I corrected last night.

Otherwise no real change since 3.19
- two regtests fail to build
- 236 regtest failures out of 671 with 1 hang

A+
Paul

Re: [Valgrind-users] Valgrind-3.20.0.RC1 is available for testing

[Paul F. <pj...@wa...>]

On 10/20/22 01:52, Mark Wielaard wrote:
> Greetings.
> 
> A first release candidate for 3.20.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
> (md5 = 981b9276536843090700c1268549186e)
> 
> Please give it a try on platforms that are important for you.  If no
> serious issues are reported, the 3.20.0 final release will happen on
> 22 October.


FreeBSD 13.1

LGTM

One slight oddity.

I had a couple of failures (the ann1 and ann2 callgrind and cachegrind 
tests) after doing

autogen && configure && make && make check && make regtest


That seems to be because the timestamp of cgout-test is older than a.c 
causing


+@@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ 
WARNING @@
+@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
+@ Source file 'a.c' is more recent than input file 
'../../cachegrind/tests/cgout-test'.
+@ Annotations may not be correct.
+@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
+


A+
Paul

[Valgrind-users] Valgrind-3.20.0.RC1 is available for testing

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

Greetings.

A first release candidate for 3.20.0 is available at
https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
(md5 = 981b9276536843090700c1268549186e)

Please give it a try on platforms that are important for you.  If no
serious issues are reported, the 3.20.0 final release will happen on
22 October.

Re: [Valgrind-users] callgrind.out file size is zero

[Floyd, P. <pj...@wa...>]

On 18/10/2022 14:54, Mahin Pandya wrote:
>
> Hi All,
>
> I am tying to use Valgrind to generate code profiling, generated 
> callgrind.out.2199511 file is of zero size. After enabling the debug 
> log below message is displayed:
>
> ...
>
> ==== SB 2759 (evchecks 30598) [tid 1] 0x415b170 execve 
> /usr/lib/x86_64-linux-gnu/libc-2.31.so+0xe3170
>
> --1314389:1: syswrap Exec of /devsrc/wineinst/bin/wine64-preloader
>
> --1314389:1: gdbsrv remote_finish (reason orderly_finish) 1030 -1
>
> --1314389:1: gdbsrv 1314389 (creator 1314389) maybe unlinking
>
> ...
>
> Any idea why it does not generate profiling data? I am new to 
> Valgrind, so not sure may have missed obvious things. Any 
> pointers/suggestion are welcome.
>
> Thanking you.
>
> regards,
>
> Mahin
>

Hi

My guess is that your process is doing a fork/exec (or maybe just an exec).

Try with --trace-children=yes

I'd also recommend that you start with --tool=none before moving on to 
callgrind.

A+

Paul

Re: [Valgrind-users] callgrind.out file size is zero

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

As a wild guess: looks like your application is doing fork and exec.
You might try to add then  --trace-children=yes 
  (and possibly if needed you should use --trace-children-skip=...... if tracing
   all children is too much).

Otherwise, try first with a very simple standalone program
e.g. something like:
   for (int i = 0; i < 1000; i++)
	printf ("hello world %d\n", i);

see if that works, and compare the debug trace of the very simple working
case with the more complex non working case.

Philippe


On Tue, 2022-10-18 at 12:54 +0000, Mahin Pandya wrote:
> Hi All,
>  
> I am tying to use Valgrind to generate code profiling, generated callgrind.out.2199511
> file is of zero size. After enabling the debug log below message is displayed:
>  
> ...
> ==== SB 2759 (evchecks 30598) [tid 1] 0x415b170 execve /usr/lib/x86_64-linux-gnu/libc-
> 2.31.so+0xe3170
> --1314389:1: syswrap Exec of /devsrc/wineinst/bin/wine64-preloader
> --1314389:1:  gdbsrv remote_finish (reason orderly_finish) 1030 -1
> --1314389:1:  gdbsrv 1314389 (creator 1314389) maybe unlinking
> ...
>  
> Any idea why it does not generate profiling data? I am new to Valgrind, so not sure may
> have missed obvious things. Any pointers/suggestion are welcome.
> Thanking you.
>  
> regards,
> Mahin
>  
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] callgrind.out file size is zero

[Mahin P. <mah...@ac...>]

Hi All,

I am tying to use Valgrind to generate code profiling, generated callgrind.out.2199511 file is of zero size. After enabling the debug log below message is displayed:

...
==== SB 2759 (evchecks 30598) [tid 1] 0x415b170 execve /usr/lib/x86_64-linux-gnu/libc-2.31.so+0xe3170
--1314389:1: syswrap Exec of /devsrc/wineinst/bin/wine64-preloader
--1314389:1:  gdbsrv remote_finish (reason orderly_finish) 1030 -1
--1314389:1:  gdbsrv 1314389 (creator 1314389) maybe unlinking
...

Any idea why it does not generate profiling data? I am new to Valgrind, so not sure may have missed obvious things. Any pointers/suggestion are welcome.
Thanking you.

regards,
Mahin

Re: [Valgrind-users] bug report: bugzilla refused to accept this saying it contains spam. But it doesn't.

[ISHIKAWA,chiaki <ish...@yk...>]

Still No Go.

If anyone reading this e-mail is involved in bugs.kde.org bugzilla 
management, please let the "sysadmin" know there is a perplexed
developer why on earth the following is deemed a spam, and being blocked 
to the bugzilla web.

Oh, yes, please also ask whoever is responsible to list the sysadmin 
address so that it would be much easier for someone to reach them.
That way, I don't have to bother the mailing list.

I have removed the stack trace with timestamp into a separate file in 
the hope that submission now works. It does not.


---- when I tried to submit bugzilla entry.

Your comment has been automatically blocked as it is believed to contain 
spam. Please contact Sysadmin if you believe this to be incorrect.

Please press Back and try again.

I tried a few times, removing a few strings, changing @ to AT and 
removing the URL reference to the e-mail exchange at the sourceforge 
archive.
To no avail...

--- begin quote ---

SUMMARY

valgrind 3.20GIT crashes due to SIGFPE while trying to run Thunderbird 
mail client.

I wrote this message initially on September 22.
So "one week ago", etc. are relative to that epoch origin.

I am trying to run thunderbird mail client (TB for short) under valgrind.
TB is created from the so-called comm-central source tree.
My local source was synced with the public source tree about a week ago.

Well, I could run TB under valgrind on August 15.
Also, I believe I could run it about 10 days ago.
However, in the last few days, when I tried to run TB under valgrind, 
valgrind crashed.

I suspect something has changed in the TB's binary toolchain in the last 
10 days or so.

Valgrind version
Valgrind-3.20.0.GIT-90763ca763-20220522X and LibVEX

OS:
Linux version 5.18.0-4-amd64 (debian-kerne AT lists.debian.org) (gcc-11 
(Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 
2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 (2022-08-10)

It seems the binary toolchain for TB seemed to have generated debug 
information that valgrind could not grok (?)

I am uploading the relvant part of the log from the test run when the 
fatal error occurred.

When valgrind failed, TB was created using ordinary -g flag of gcc-10.

On a hunch, I re-created TB using -gsplit-dwarf flag to gcc..
Then, with the newly created version of TB, valgrind did not crash 
although it did print
"### unhandled dwarf2 ..." warnings.

So something in the debug information in the libxul.so (about 120MB) is 
not quite right when ordinary non-split dwarf information is in the object..

STEPS TO REPRODUCE
1. run valgrind to check the memory usage of thunderbird mail client 
when it runs a test.
     The command line is dumped in the attached log.
2. Wait for the completion of a test run.
3. valgrind crashes.

OBSERVED RESULT
SIGFPE crash.
VALGRIND INTERNAL ERROR: Valgrind received a signal 8 (SIGFPE) - exiting
See the attachment.

EXPECTED RESULT
valgrind ought to finish the execution of TB running its test successfully.

SOFTWARE/OS VERSIONS
Debian GNU/Linux.
Linux version 5.18.0-4-amd64 (deb...@li...) (gcc-11 
(Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 
2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 (2022-08-10)

Linux/KDE Plasma:
(available in About System) <--- not sure about this. My Debian XFCE4 
desltop does not ahve "About System" anywhere.
I don't believe the GUI middleware has anything to do with the bug 
reported here.
KDE Plasma Version:
KDE Frameworks Version:
Qt Version:

ADDITIONAL INFORMATION

As I noted above, if I recompile TB using -gsplit-dwarf flag to gcc-10, 
then valgrind prints warnings about
unknown dwarf2 symbol, but it runs TB running its test to its completion.
I pass "-gdwarf-4 " to gcc.
So if something is generating dwarf2 info, it is not gcc, I think.
Maybe rust compiler being used?
  rustc --version
  rustc 1.63.0 (4b91a6ea7 2022-08-08)

In a discussion about this issue in valgrind-users mailing list, John 
Reiser suggested a following simple work-around:
(But I think we need to do something about the "unhandled dwarf2 abbrev 
code 0x25" in the long run.)

--- begin quote
 >  O think valgrind experienced a division by zero.
 >
 > readdwarf.c:
 >
 >        if (op_code >= info.li_opcode_base) {
 >           op_code -= info.li_opcode_base;
 >           Word adv = (op_code / info.li_line_range) <--- line 831
 >                         * info.li_min_insn_length;
 >           Int advAddr = adv;
 >           state_machine_regs.address += adv;

If you can re-build valgrind, then a quick-and-dirty work-around
might be

 >           Word adv = (op_code / (info.li_line_range ?: 1))
 >                         * info.li_min_insn_length;

where "x ?: y" is a deprecated-but-useful slang for "x ? x : y".
--- end quote


TIA

PS: BTW, initially, I could not post this bug report to the kde bugzilla 
due to the following error message.

==========
Your comment has been automatically blocked as it is believed to contain 
spam. Please contact Sysadmin if you believe this to be incorrect.
==========

Well, it does not, and the bugzilla web does not list sysadmin address.

It was suggested in the valgrind-users mailing list that I
should move the stacktrace dump from thunderbird test suite framework
to an attachment since the timestamp string attached by the test suite
may confuse the bugzilla system, and this is what I am doing now.

--- end quote ---

Re: [Valgrind-users] bug report: bugzilla refused to accept this saying it contains spam. But it doesn't.

[ISHIKAWA,chiaki <ish...@yk...>]

On 2022/09/23 9:11, John Reiser wrote:
>> I think valgrind experienced a division by zero.
>>
>> readdwarf.c:
>>
>>        if (op_code >= info.li_opcode_base) {
>>           op_code -= info.li_opcode_base;
>>           Word adv = (op_code / info.li_line_range)    <--- line 831
>>                         * info.li_min_insn_length;
>>           Int advAddr = adv;
>>           state_machine_regs.address += adv;
>
> If you can re-build valgrind, then a quick-and-dirty work-around
> might be
>
> >           Word adv = (op_code / (info.li_line_range ?: 1))
> >                         * info.li_min_insn_length;
>
> where "x ?: y" is a deprecated-but-useful slang for "x ? x : y".
>
> Also, one probable reason for the bug reporting system rejecting
> your first submission is the many consecutive lines that begin with
> "00:08.54 GECKO(319869) ".  The work-around for this is to put
> the text of the valgrind complaint into an attachment, and say
> "See the attachment for the full text of the valgrind complaint."



Thank you for the comment.


I will try to re-submit the bugzilla entry.

I didn't realize the lines starting with timestamp string such as 
""00:08.54 GECKO(319869) " causing the problem.
I thought there were no URLs, and so no spam. :-)

Sorry, somehow I overlooked your e-mail and thus this very tardy response.

TIA

Chiaki

[Valgrind-users] [Android] Warning linker with memcheck library

[$<ri...@nt...>]

Dear Valgrind Users,

I am trying to use valgrind on an Android device running version 12 to
debug some issue in the application. I am facing two issues here.

1. Valgrind reporting below warnings. Does this mean no track of
malloc/free etc..?

WARNING: linker: Warning:
"/data/local/tmp/Inst/libexec/valgrind/vgpreload_core-arm64-linux.so" has
unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
WARNING: linker: Warning:
"/data/local/tmp/Inst/libexec/valgrind/vgpreload_memcheck-arm64-linux.so"
has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)

2. How to launch an android application through valgrind. I am getting
command used `/data/local/tmp/Inst/bin/valgrind --tool=memcheck
--leak-check=full am start -a android.intent.action.MAIN -n
org.codeaurora.dialer/com.android.dialer.main.impl.MainActivity`
/system/bin/am[9]: /system/bin/cmd: Bad address

Please advise anyone who come across this issue and how to resolve this
issue.
-- 
Thanks & Regards,
M.Srikanth Kumar.

Re: [Valgrind-users] Valgrind not finding issue with writing/reading past array?

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

This is in fact documented in the FAQ here:

https://valgrind.org/docs/manual/faq.html#faq.overruns

The fact it's an array is not actually important - there is no
overrun detection for any global or stack variables.

The reason is that because valgrind is operating on an existing
binary there is no way to insert guards between variables because
the compiler has already fixed the layout - for the heap valgrind
can replace the allocate with one that adds guards around each
allocated block.

The tool Philippe refers to tried to use debug information where
possible to spot out of bounds writes but it wasn't very successful.

Better is to use address sanitizer, which requires recompilation
but because of that it is able to add guards around variables.

Tom

On 26/09/2022 21:20, Philippe Waroquiers wrote:
> Valgrind does not check out of bound write in arrays, unless these arrays are malloc-ed
> (and so valgrind can detect the write out of the limit of the malloc-ed block).
> 
> Valgrind used to contain an experimental tool (sgcheck) that did such stack array checks,
> but it had several limitations and problems, and was removed.
> 
> Thanks
> Philippe
> 
> On Mon, 2022-09-26 at 14:13 -0600, Grant Schoep wrote:
>> So I noticed something in my code that looked wrong to me, but valgrind didn't report
>> anything. I made a small example of it, and still no findings. I'm sure this code is
>> reading/writing past its array. But valgind doesn't say anything.
>>
>> I'm I not understanding something or is this a bug.
>>
>> Using:
>>   valgrind-3.19.0, gcc 4.8.5, CentOS 7
>>
>> I also tried
>> valgrind-3.19.0, gcc 7.3.1, Amazon Linux 2
>>
>> Here is the code.
>> ------
>> #include <string.h>
>> #include <stdio.h>
>>
>> int main()
>> {
>>     char retStr[32];
>>     
>>     // this is bad right? 40 bytes when above was 32?
>>     memset(retStr, 'F', 40);
>>        
>>     // These are "writing"  past the allocated memory?
>>     retStr[32] = 'A';
>>     retStr[33] = 'B';
>>     
>>     // These should be fine
>>     printf("***********  retStr is %c\n", retStr[30]);
>>     printf("***********  retStr is %c\n", retStr[31]);
>>     
>>     // These are reading past allocated memory?
>>     printf("***********  retStr is %c\n", retStr[32]);
>>     printf("***********  retStr is %c\n", retStr[33]);
>>
>>     return 0;
>> }
>> ---
>>
>>
>> Compiled:
>> "gcc filename.cxx"
>>
>> Ran via this command
>> "valgrind ./a.out"
>>
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

Re: [Valgrind-users] Valgrind not finding issue with writing/reading past array?

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

Valgrind does not check out of bound write in arrays, unless these arrays are malloc-ed
(and so valgrind can detect the write out of the limit of the malloc-ed block).

Valgrind used to contain an experimental tool (sgcheck) that did such stack array checks,
but it had several limitations and problems, and was removed.

Thanks
Philippe

On Mon, 2022-09-26 at 14:13 -0600, Grant Schoep wrote:
> So I noticed something in my code that looked wrong to me, but valgrind didn't report
> anything. I made a small example of it, and still no findings. I'm sure this code is
> reading/writing past its array. But valgind doesn't say anything. 
> 
> I'm I not understanding something or is this a bug.
> 
> Using:
>  valgrind-3.19.0, gcc 4.8.5, CentOS 7
> 
> I also tried
> valgrind-3.19.0, gcc 7.3.1, Amazon Linux 2
> 
> Here is the code.
> ------
> #include <string.h>
> #include <stdio.h>
> 
> int main()
> {
>    char retStr[32];
>    
>    // this is bad right? 40 bytes when above was 32?
>    memset(retStr, 'F', 40);
>       
>    // These are "writing"  past the allocated memory?
>    retStr[32] = 'A';
>    retStr[33] = 'B';
>    
>    // These should be fine
>    printf("***********  retStr is %c\n", retStr[30]);
>    printf("***********  retStr is %c\n", retStr[31]);
>    
>    // These are reading past allocated memory?
>    printf("***********  retStr is %c\n", retStr[32]);
>    printf("***********  retStr is %c\n", retStr[33]);
> 
>    return 0;
> }
> ---
> 
> 
> Compiled:
> "gcc filename.cxx"
> 
> Ran via this command
> "valgrind ./a.out"
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Valgrind not finding issue with writing/reading past array?

[Grant S. <mat...@gm...>]

So I noticed something in my code that looked wrong to me, but valgrind
didn't report anything. I made a small example of it, and still no
findings. I'm sure this code is reading/writing past its array. But valgind
doesn't say anything.

I'm I not understanding something or is this a bug.

Using:
valgrind-3.19.0, gcc 4.8.5, CentOS 7

I also tried
valgrind-3.19.0, gcc 7.3.1, Amazon Linux 2

Here is the code.
------
#include <string.h>
#include <stdio.h>

int main()
{
   char retStr[32];

   // this is bad right? 40 bytes when above was 32?
   memset(retStr, 'F', 40);

   // These are "writing"  past the allocated memory?
   retStr[32] = 'A';
   retStr[33] = 'B';

   // These should be fine
   printf("***********  retStr is %c\n", retStr[30]);
   printf("***********  retStr is %c\n", retStr[31]);

   // These are reading past allocated memory?
   printf("***********  retStr is %c\n", retStr[32]);
   printf("***********  retStr is %c\n", retStr[33]);

   return 0;
}
---


Compiled:
"gcc filename.cxx"

Ran via this command
"valgrind ./a.out"

Re: [Valgrind-users] bug report: bugzilla refused to accept this saying it contains spam. But it doesn't.

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

> I think valgrind experienced a division by zero.
> 
> readdwarf.c:
> 
>        if (op_code >= info.li_opcode_base) {
>           op_code -= info.li_opcode_base;
>           Word adv = (op_code / info.li_line_range)    <--- line 831
>                         * info.li_min_insn_length;
>           Int advAddr = adv;
>           state_machine_regs.address += adv;

If you can re-build valgrind, then a quick-and-dirty work-around
might be

 >           Word adv = (op_code / (info.li_line_range ?: 1))
 >                         * info.li_min_insn_length;

where "x ?: y" is a deprecated-but-useful slang for "x ? x : y".

Also, one probable reason for the bug reporting system rejecting
your first submission is the many consecutive lines that begin with
"00:08.54 GECKO(319869) ".  The work-around for this is to put
the text of the valgrind complaint into an attachment, and say
"See the attachment for the full text of the valgrind complaint."

Re: [Valgrind-users] bug report: bugzilla refused to accept this saying it contains spam. But it doesn't.

[ISHIKAWA,chiaki <ish...@yk...>]

Hi,

I thought SIGFPE is a bit odd.
But now I know why.
I think valgrind experienced a division by zero.

readdwarf.c:

       if (op_code >= info.li_opcode_base) {
          op_code -= info.li_opcode_base;
          Word adv = (op_code / info.li_line_range)    <--- line 831
                        * info.li_min_insn_length;
          Int advAddr = adv;
          state_machine_regs.address += adv;

On 2022/09/22 13:39, ISHIKAWA,chiaki wrote:
> Hi,
> I could not post this bug report to the kde bugzilla due to the 
> following error message.
>
> ==========
> Your comment has been automatically blocked as it is believed to 
> contain spam. Please contact Sysadmin if you believe this to be 
> incorrect.
> ==========
>
> Well, it does not, and the bugzilla web does not list sysadmin address.
>
> So here it is.
>
> I can send the full log on request.
> Also, libxul.so when zipped is about 120MB.
> I can send it via webtransfer or something to the interested party.
>
> I forgot to mention, I recreated TB each day after a minor fix, and so 
> the change in the binary toolchain is likely the culprit.
>
> Thank you for making the great package available to programming community.
>
> Chiaki
>
>
>
> =======================
> valgrind 3.20GIT crashes while trying to run Thunderbird mail client.
> ------------------------
>
> SUMMARY
>
> I am trying to run thunderbird mail client (TB for short) under valgrind.
> TB is created from the so-called comm-central source tree.
> My local source was synced with the public source tree about a week
> ago.
>
> Well, I could run TB under valgrind on August 15.
> Also, I believe I could run it about 10 days ago.
> However, in the last few days, when I tried to run TB under valgrind,
> valgrind crashed.
>
> valgrind said:
> 00:08.54 GECKO(319869) --319873-- WARNING: Serious error when reading 
> debug info
> 00:08.54 GECKO(319869) --319873-- When reading debug info from 
> /NEW-SSD/moz-obj-dir/objdir-tb3/toolkit/library/build/libxul.so:
> 00:08.54 GECKO(319869) --319873-- Only DWARF version 2, 3, 4 and 5 
> line info is currently supported.
> 00:08.54 GECKO(319869) ### unhandled dwarf2 abbrev form code 0x25
> 00:08.54 GECKO(319869) ### unhandled dwarf2 abbrev form code 0x25
> 00:08.54 GECKO(319869) ### unhandled dwarf2 abbrev form code 0x25
> 00:08.54 GECKO(319869) ### unhandled dwarf2 abbrev form code 0x1b
> 00:08.54 GECKO(319869) --319873-- VALGRIND INTERNAL ERROR: Valgrind 
> received a signal 8 (SIGFPE) - exiting
> 00:08.54 GECKO(319869) --319873-- si_code=1;  Faulting address: 
> 0x580C4519;  sp: 0x100307c820
> 00:08.54 GECKO(319869) valgrind: the 'impossible' happened:
> 00:08.54 GECKO(319869)    Killed by fatal signal
> 00:08.54 GECKO(319869) host stacktrace:
> 00:08.54 GECKO(319869) ==319873==    at 0x580C4519: 
> read_dwarf2_lineblock (readdwarf.c:831)
> 00:08.54 GECKO(319869) ==319873==    by 0x580C770F: 
> vgModuleLocal_read_debuginfo_dwarf3 (readdwarf.c:1380)
> 00:08.54 GECKO(319869) ==319873==    by 0x58081053: 
> vgModuleLocal_read_elf_debug_info (readelf.c:3489)
> 00:08.54 GECKO(319869) ==319873==    by 0x5806F0DB: 
> di_notify_ACHIEVE_ACCEPT_STATE (debuginfo.c:969)
> 00:08.54 GECKO(319869) ==319873==    by 0x5806F0DB: 
> vgPlain_di_notify_mmap (debuginfo.c:1326)
> 00:08.54 GECKO(319869) ==319873==    by 0x5809EDBF: 
> vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2466)
> 00:08.54 GECKO(319869) ==319873==    by 0x580AA5FF: 
> vgSysWrap_amd64_linux_sys_mmap_before (syswrap-amd64-linux.c:413)
> 00:08.54 GECKO(319869) ==319873==    by 0x5809B275: 
> vgPlain_client_syscall (syswrap-main.c:2234)
> 00:08.54 GECKO(319869) ==319873==    by 0x58096D5A: handle_syscall 
> (scheduler.c:1211)
> 00:08.54 GECKO(319869) ==319873==    by 0x58098D67: vgPlain_scheduler 
> (scheduler.c:1529)
> 00:08.54 GECKO(319869) ==319873==    by 0x580E170C: thread_wrapper 
> (syswrap-linux.c:101)
> 00:08.54 GECKO(319869) ==319873==    by 0x580E170C: 
> run_a_thread_NORETURN (syswrap-linux.c:154)
> 00:08.54 GECKO(319869) sched status:
> 00:08.54 GECKO(319869)   running_tid=1
> 00:08.54 GECKO(319869) Thread 1: status = VgTs_Runnable syscall 9 
> (lwpid 319873)
> 00:08.54 GECKO(319869) ==319873==    at 0x4020B82: __mmap64 (mmap64.c:59)
> 00:08.54 GECKO(319869) ==319873==    by 0x4020B82: mmap (mmap64.c:47)
> 00:08.54 GECKO(319869) ==319873==    by 0x400615B: _dl_map_segments 
> (dl-map-segments.h:94)
> 00:08.54 GECKO(319869) ==319873==    by 0x400615B: 
> _dl_map_object_from_fd (dl-load.c:1250)
> 00:08.55 GECKO(319869) ==319873==    by 0x40074E6: _dl_map_object 
> (dl-load.c:2301)
> 00:08.55 GECKO(319869) ==319873==    by 0x400BB57: 
> dl_open_worker_begin (dl-open.c:533)
> 00:08.55 GECKO(319869) ==319873==    by 0x4BFF09F: _dl_catch_exception 
> (dl-error-skeleton.c:208)
> 00:08.55 GECKO(319869) ==319873==    by 0x400B325: dl_open_worker 
> (dl-open.c:777)
> 00:08.55 GECKO(319869) ==319873==    by 0x4BFF09F: _dl_catch_exception 
> (dl-error-skeleton.c:208)
> 00:08.55 GECKO(319869) ==319873==    by 0x400B70A: _dl_open 
> (dl-open.c:878)
> 00:08.55 GECKO(319869) ==319873==    by 0x4B32D77: dlopen_doit 
> (dlopen.c:56)
> 00:08.55 GECKO(319869) ==319873==    by 0x4BFF09F: _dl_catch_exception 
> (dl-error-skeleton.c:208)
> 00:08.55 GECKO(319869) ==319873==    by 0x4BFF15E: _dl_catch_error 
> (dl-error-skeleton.c:227)
> 00:08.55 GECKO(319869) ==319873==    by 0x4B32855: _dlerror_run 
> (dlerror.c:138)
> 00:08.55 GECKO(319869) ==319873==    by 0x4B32E30: 
> dlopen_implementation (dlopen.c:71)
> 00:08.55 GECKO(319869) ==319873==    by 0x4B32E30: dlopen@@GLIBC_2.34 
> (dlopen.c:81)
> 00:08.55 GECKO(319869) ==319873==    by 0x118474: GetLibHandle(char 
> const*) (nsXPCOMGlue.cpp:89)
> 00:08.55 GECKO(319869) ==319873==    by 0x1185F5: ReadDependentCB(char 
> const*, mozilla::LibLoadingStrategy) (nsXPCOMGlue.cpp:144)
> 00:08.55 GECKO(319869) ==319873==    by 0x119252: XPCOMGlueLoad(char 
> const*, mozilla::LibLoadingStrategy) (nsXPCOMGlue.cpp:323)
> 00:08.55 GECKO(319869) ==319873==    by 0x1193D4: 
> mozilla::GetBootstrap(char const*, mozilla::LibLoadingStrategy) 
> (nsXPCOMGlue.cpp:405)
> 00:08.55 GECKO(319869) ==319873==    by 0x115D9B: 
> InitXPCOMGlue(mozilla::LibLoadingStrategy) (nsMailApp.cpp:244)
> 00:08.55 GECKO(319869) ==319873==    by 0x11682F: main (nsMailApp.cpp:375)
> 00:08.55 GECKO(319869) client stack range: [0x1FFEFFA000 0x1FFF000FFF] 
> client SP: 0x1FFEFFB768
> 00:08.55 GECKO(319869) valgrind stack range: [0x1002F7E000 
> 0x100307DFFF] top usage: 18984 of 1048576
> 00:08.55 GECKO(319869) Note: see also the FAQ in the source distribution.
> 00:08.55 GECKO(319869) It contains workarounds to several common problems.
> 00:08.55 GECKO(319869) In particular, if Valgrind aborted or crashed after
> 00:08.55 GECKO(319869) identifying problems in your program, there's a 
> good chance
> 00:08.55 GECKO(319869) that fixing those problems will prevent 
> Valgrind aborting or
> 00:08.55 GECKO(319869) crashing, especially if it happened in 
> m_mallocfree.c.
> 00:08.55 GECKO(319869) If that doesn't help, please report this bug 
> to: www.valgrind.org
> 00:08.55 GECKO(319869) In the bug report, send all the above text, the 
> valgrind
> 00:08.55 GECKO(319869) version, and what OS and version you are 
> using.  Thanks.
>
>
> I suspect something has changed in the TB's binary toolchain in the 
> last 10 days or so.
>
> Valgrind version
> Valgrind-3.20.0.GIT-90763ca763-20220522X and LibVEX
>
> OS:
> Linux version 5.18.0-4-amd64 (deb...@li...) (gcc-11 
> (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 
> 2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 (2022-08-10)
>
> It seems the binary toolchain for TB seemed to have generated debug 
> information that
> valgrind could not grok (?)
>
> I am uploading the relvant part of the log from the test run when the
> fatal error occurred.
>
> When valgrind failed, TB was created using ordinary -g flag of gcc-10.
>
> On a hunch, I re-created TB using -gsplit-dwarf flag to gcc..
> Then, with the newly created version of TB, valgrind did not crash 
> although it did print
> "### unhandled dwarf2 ..." warnings.
>
> So something in the debug information in the libxul.so is not quite
> right when ordinary non-split dwarf information is in the object..
>
> (I will attching the gzipped libxul if that big file is accepted.)
>
>
>
> STEPS TO REPRODUCE
> 1. run valgrind to check the memory usage of thunderbird mail client 
> when it runs a test.
>     The command line is dumped in the attached log.
> 2. Wait for the completion of a test run.
> 3. valgrind crashes.
>
> OBSERVED RESULT
> 00:08.54 GECKO(319869) --319873-- VALGRIND INTERNAL ERROR: Valgrind 
> received a signal 8 (SIGFPE) - exiting
> 00:08.54 GECKO(319869) --319873-- si_code=1;  Faulting address: 
> 0x580C4519;  sp: 0x100307c820
> 00:08.54 GECKO(319869) valgrind: the 'impossible' happened:
> 00:08.54 GECKO(319869)    Killed by fatal signal
> 00:08.54 GECKO(319869) host stacktrace:
>
>
> EXPECTED RESULT
> valgrind ought to finish the execution of TB running its test 
> successfully.
>
> SOFTWARE/OS VERSIONS
> Debian GNU/Linux.
> Linux version 5.18.0-4-amd64 (deb...@li...) (gcc-11 
> (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 
> 2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 (2022-08-10)
>
> Linux/KDE Plasma:
> (available in About System) <--- not sure about this. My Debian XFCE4 
> desltop does not ahve "About System" anywhere.
> I don't believe the GUI middleware has anything to do with the bug 
> reported here.
> KDE Plasma Version:
> KDE Frameworks Version:
> Qt Version:
>
> ADDITIONAL INFORMATION
> As I noted above, if I recompile TB using -gsplit-dwarf flag to 
> gcc-10, then valgrind prints warnings about
> unknown dwarf2 symbol, but it runs TB running its test to its completion.
> I pass "-gdwarf-4 " to gcc.
> So if something is generating dwarf2 info, it is not gcc, I think.
> Maybe rust compiler being used?
>  rustc --version
>  rustc 1.63.0 (4b91a6ea7 2022-08-08)
>
> [end of memo]
>

[Valgrind-users] bug report: bugzilla refused to accept this saying it contains spam. But it doesn't.

[ISHIKAWA,chiaki <ish...@yk...>]

Hi,
I could not post this bug report to the kde bugzilla due to the 
following error message.

==========
Your comment has been automatically blocked as it is believed to contain 
spam. Please contact Sysadmin if you believe this to be incorrect.
==========

Well, it does not, and the bugzilla web does not list sysadmin address.

So here it is.

I can send the full log on request.
Also, libxul.so when zipped is about 120MB.
I can send it via webtransfer or something to the interested party.

I forgot to mention, I recreated TB each day after a minor fix, and so 
the change in the binary toolchain is likely the culprit.

Thank you for making the great package available to programming community.

Chiaki



=======================
valgrind 3.20GIT crashes while trying to run Thunderbird mail client.
------------------------

SUMMARY

I am trying to run thunderbird mail client (TB for short) under valgrind.
TB is created from the so-called comm-central source tree.
My local source was synced with the public source tree about a week
ago.

Well, I could run TB under valgrind on August 15.
Also, I believe I could run it about 10 days ago.
However, in the last few days, when I tried to run TB under valgrind,
valgrind crashed.

valgrind said:
00:08.54 GECKO(319869) --319873-- WARNING: Serious error when reading 
debug info
00:08.54 GECKO(319869) --319873-- When reading debug info from 
/NEW-SSD/moz-obj-dir/objdir-tb3/toolkit/library/build/libxul.so:
00:08.54 GECKO(319869) --319873-- Only DWARF version 2, 3, 4 and 5 line 
info is currently supported.
00:08.54 GECKO(319869) ### unhandled dwarf2 abbrev form code 0x25
00:08.54 GECKO(319869) ### unhandled dwarf2 abbrev form code 0x25
00:08.54 GECKO(319869) ### unhandled dwarf2 abbrev form code 0x25
00:08.54 GECKO(319869) ### unhandled dwarf2 abbrev form code 0x1b
00:08.54 GECKO(319869) --319873-- VALGRIND INTERNAL ERROR: Valgrind 
received a signal 8 (SIGFPE) - exiting
00:08.54 GECKO(319869) --319873-- si_code=1;  Faulting address: 
0x580C4519;  sp: 0x100307c820
00:08.54 GECKO(319869) valgrind: the 'impossible' happened:
00:08.54 GECKO(319869)    Killed by fatal signal
00:08.54 GECKO(319869) host stacktrace:
00:08.54 GECKO(319869) ==319873==    at 0x580C4519: 
read_dwarf2_lineblock (readdwarf.c:831)
00:08.54 GECKO(319869) ==319873==    by 0x580C770F: 
vgModuleLocal_read_debuginfo_dwarf3 (readdwarf.c:1380)
00:08.54 GECKO(319869) ==319873==    by 0x58081053: 
vgModuleLocal_read_elf_debug_info (readelf.c:3489)
00:08.54 GECKO(319869) ==319873==    by 0x5806F0DB: 
di_notify_ACHIEVE_ACCEPT_STATE (debuginfo.c:969)
00:08.54 GECKO(319869) ==319873==    by 0x5806F0DB: 
vgPlain_di_notify_mmap (debuginfo.c:1326)
00:08.54 GECKO(319869) ==319873==    by 0x5809EDBF: 
vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2466)
00:08.54 GECKO(319869) ==319873==    by 0x580AA5FF: 
vgSysWrap_amd64_linux_sys_mmap_before (syswrap-amd64-linux.c:413)
00:08.54 GECKO(319869) ==319873==    by 0x5809B275: 
vgPlain_client_syscall (syswrap-main.c:2234)
00:08.54 GECKO(319869) ==319873==    by 0x58096D5A: handle_syscall 
(scheduler.c:1211)
00:08.54 GECKO(319869) ==319873==    by 0x58098D67: vgPlain_scheduler 
(scheduler.c:1529)
00:08.54 GECKO(319869) ==319873==    by 0x580E170C: thread_wrapper 
(syswrap-linux.c:101)
00:08.54 GECKO(319869) ==319873==    by 0x580E170C: 
run_a_thread_NORETURN (syswrap-linux.c:154)
00:08.54 GECKO(319869) sched status:
00:08.54 GECKO(319869)   running_tid=1
00:08.54 GECKO(319869) Thread 1: status = VgTs_Runnable syscall 9 (lwpid 
319873)
00:08.54 GECKO(319869) ==319873==    at 0x4020B82: __mmap64 (mmap64.c:59)
00:08.54 GECKO(319869) ==319873==    by 0x4020B82: mmap (mmap64.c:47)
00:08.54 GECKO(319869) ==319873==    by 0x400615B: _dl_map_segments 
(dl-map-segments.h:94)
00:08.54 GECKO(319869) ==319873==    by 0x400615B: 
_dl_map_object_from_fd (dl-load.c:1250)
00:08.55 GECKO(319869) ==319873==    by 0x40074E6: _dl_map_object 
(dl-load.c:2301)
00:08.55 GECKO(319869) ==319873==    by 0x400BB57: dl_open_worker_begin 
(dl-open.c:533)
00:08.55 GECKO(319869) ==319873==    by 0x4BFF09F: _dl_catch_exception 
(dl-error-skeleton.c:208)
00:08.55 GECKO(319869) ==319873==    by 0x400B325: dl_open_worker 
(dl-open.c:777)
00:08.55 GECKO(319869) ==319873==    by 0x4BFF09F: _dl_catch_exception 
(dl-error-skeleton.c:208)
00:08.55 GECKO(319869) ==319873==    by 0x400B70A: _dl_open (dl-open.c:878)
00:08.55 GECKO(319869) ==319873==    by 0x4B32D77: dlopen_doit (dlopen.c:56)
00:08.55 GECKO(319869) ==319873==    by 0x4BFF09F: _dl_catch_exception 
(dl-error-skeleton.c:208)
00:08.55 GECKO(319869) ==319873==    by 0x4BFF15E: _dl_catch_error 
(dl-error-skeleton.c:227)
00:08.55 GECKO(319869) ==319873==    by 0x4B32855: _dlerror_run 
(dlerror.c:138)
00:08.55 GECKO(319869) ==319873==    by 0x4B32E30: dlopen_implementation 
(dlopen.c:71)
00:08.55 GECKO(319869) ==319873==    by 0x4B32E30: dlopen@@GLIBC_2.34 
(dlopen.c:81)
00:08.55 GECKO(319869) ==319873==    by 0x118474: GetLibHandle(char 
const*) (nsXPCOMGlue.cpp:89)
00:08.55 GECKO(319869) ==319873==    by 0x1185F5: ReadDependentCB(char 
const*, mozilla::LibLoadingStrategy) (nsXPCOMGlue.cpp:144)
00:08.55 GECKO(319869) ==319873==    by 0x119252: XPCOMGlueLoad(char 
const*, mozilla::LibLoadingStrategy) (nsXPCOMGlue.cpp:323)
00:08.55 GECKO(319869) ==319873==    by 0x1193D4: 
mozilla::GetBootstrap(char const*, mozilla::LibLoadingStrategy) 
(nsXPCOMGlue.cpp:405)
00:08.55 GECKO(319869) ==319873==    by 0x115D9B: 
InitXPCOMGlue(mozilla::LibLoadingStrategy) (nsMailApp.cpp:244)
00:08.55 GECKO(319869) ==319873==    by 0x11682F: main (nsMailApp.cpp:375)
00:08.55 GECKO(319869) client stack range: [0x1FFEFFA000 0x1FFF000FFF] 
client SP: 0x1FFEFFB768
00:08.55 GECKO(319869) valgrind stack range: [0x1002F7E000 0x100307DFFF] 
top usage: 18984 of 1048576
00:08.55 GECKO(319869) Note: see also the FAQ in the source distribution.
00:08.55 GECKO(319869) It contains workarounds to several common problems.
00:08.55 GECKO(319869) In particular, if Valgrind aborted or crashed after
00:08.55 GECKO(319869) identifying problems in your program, there's a 
good chance
00:08.55 GECKO(319869) that fixing those problems will prevent Valgrind 
aborting or
00:08.55 GECKO(319869) crashing, especially if it happened in 
m_mallocfree.c.
00:08.55 GECKO(319869) If that doesn't help, please report this bug to: 
www.valgrind.org
00:08.55 GECKO(319869) In the bug report, send all the above text, the 
valgrind
00:08.55 GECKO(319869) version, and what OS and version you are using.  
Thanks.


I suspect something has changed in the TB's binary toolchain in the last 
10 days or so.

Valgrind version
Valgrind-3.20.0.GIT-90763ca763-20220522X and LibVEX

OS:
Linux version 5.18.0-4-amd64 (deb...@li...) (gcc-11 
(Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 
2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 (2022-08-10)

It seems the binary toolchain for TB seemed to have generated debug 
information that
valgrind could not grok (?)

I am uploading the relvant part of the log from the test run when the
fatal error occurred.

When valgrind failed, TB was created using ordinary -g flag of gcc-10.

On a hunch, I re-created TB using -gsplit-dwarf flag to gcc..
Then, with the newly created version of TB, valgrind did not crash 
although it did print
"### unhandled dwarf2 ..." warnings.

So something in the debug information in the libxul.so is not quite
right when ordinary non-split dwarf information is in the object..

(I will attching the gzipped libxul if that big file is accepted.)



STEPS TO REPRODUCE
1. run valgrind to check the memory usage of thunderbird mail client 
when it runs a test.
     The command line is dumped in the attached log.
2. Wait for the completion of a test run.
3. valgrind crashes.

OBSERVED RESULT
00:08.54 GECKO(319869) --319873-- VALGRIND INTERNAL ERROR: Valgrind 
received a signal 8 (SIGFPE) - exiting
00:08.54 GECKO(319869) --319873-- si_code=1;  Faulting address: 
0x580C4519;  sp: 0x100307c820
00:08.54 GECKO(319869) valgrind: the 'impossible' happened:
00:08.54 GECKO(319869)    Killed by fatal signal
00:08.54 GECKO(319869) host stacktrace:


EXPECTED RESULT
valgrind ought to finish the execution of TB running its test successfully.

SOFTWARE/OS VERSIONS
Debian GNU/Linux.
Linux version 5.18.0-4-amd64 (deb...@li...) (gcc-11 
(Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 
2.38.90.20220713) #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 (2022-08-10)

Linux/KDE Plasma:
(available in About System) <--- not sure about this. My Debian XFCE4 
desltop does not ahve "About System" anywhere.
I don't believe the GUI middleware has anything to do with the bug 
reported here.
KDE Plasma Version:
KDE Frameworks Version:
Qt Version:

ADDITIONAL INFORMATION
As I noted above, if I recompile TB using -gsplit-dwarf flag to gcc-10, 
then valgrind prints warnings about
unknown dwarf2 symbol, but it runs TB running its test to its completion.
I pass "-gdwarf-4 " to gcc.
So if something is generating dwarf2 info, it is not gcc, I think.
Maybe rust compiler being used?
  rustc --version
  rustc 1.63.0 (4b91a6ea7 2022-08-08)

[end of memo]

Re: [Valgrind-users] compiling Valgrind 3.19.0 on Solaris 11

[Paul F. <pj...@wa...>]

Can you try

https://github.com/oracle/solaris-userland/tree/master/components/valgrind


One day I’ll get round to contacting the Oracle support team that produced this with a view to merging it upstream.


A+
Paul

[Valgrind-users] bug id as url --error-exitcode=

[David A. <da...@li...>]

Here is the bug as a url.

https://bugs.kde.org/show_bug.cgi?id=459031
DavidA

[Valgrind-users] Filed bug on --error-exitcode doc issue

[David A. <da...@li...>]

I just filed a bug on kde.org about the missing words related
to --error-exitcode=
and suggested a sentence for the on-line html doc to resolve the issue.

Bug 459031 on bugs.kde.org

DavidA

Re: [Valgrind-users] Suggestion for the documentation of --error-exitcode

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

On 9/12/22 10:04, David Anderson wrote:
> Thhe html documentation
> http://www.valgrind.org/docs/manual/index.html
> explains what --error-exitcode=9
> does in case valgrind notes an error.

> [[snip]]

> It says nothing explicitly about what exit code is returned
> if valgrind does not find an error. AFAICT.
> 
> In my tests, it appears that when valgrind
> finds no problem valgrind returns the exit code
> of the application under test if --error-exitcode is set non-zero.
> I suggest that the web page should say that clearly.

The best way to handle this is to file a bug report:
https://valgrind.org/support/bug_reports.html
and then post here the URL of the bug report.
A bug report alerts multiple developers, and
will not get lost or forgotten.

[Valgrind-users] Suggestion for the documentation of --error-exitcode

[David A. <da...@li...>]

Thhe html documentation
http://www.valgrind.org/docs/manual/index.html
explains what --error-exitcode=9
does in case valgrind notes an error.


--error-exitcode=<number>
Specifies an alternative exit code to return if Valgrind reported any
errors in the run. When set to the default value (zero), the return
value from Valgrind will always be the return value of the process being
simulated. When set to a nonzero value, that value is returned instead,
if Valgrind detects any errors. This is useful for using Valgrind as
part of an automated test suite, since it makes it easy to detect test
cases for which Valgrind has reported errors, just by inspecting return
codes.


It says nothing explicitly about what exit code is returned
if valgrind does not find an error. AFAICT.

In my tests, it appears that when valgrind
finds no problem valgrind returns the exit code
of the application under test if --error-exitcode is set non-zero.
I suggest that the web page should say that clearly.

DavidA