[valgrind] [Bug 371869] New: support '%' in symbol Z-encoding
https://bugs.kde.org/show_bug.cgi?id=371869 Bug ID: 371869 Summary: support '%' in symbol Z-encoding Product: valgrind Version: 3.12 SVN Platform: Compiled Sources OS: Solaris Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: iv...@ivosh.net Target Milestone: --- Support '%' (percent character) in Z-encoding of function replacement and wrapping. Solaris libc contains several implementations of memmove, memcpy, memset, based on CPU capabilities. For example for memmove, libc on x86 contains: - memmove() - the base function - memmove%avx2() - utilizing AVX-2 instructions when available The point here is that the detection and correct setup (which memmove implementation to use) is done by dynamic linker. Therefore we need to replace all memmove variants, not only the base one. However specifying "memmove" and "memmoveZa" in shared/vg_replace_strmem.c causes also other functions to be replaced (such as memmove_s() which has different number of arguments then memmove()). So we need to specify something like "memmove" and "memmove%Za". However '%' needs to be escaped from the C preprocessor. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371869] support '%' in symbol Z-encoding
https://bugs.kde.org/show_bug.cgi?id=371869 Ivo Raisr changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net CC||iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371869] support '%' in symbol Z-encoding
https://bugs.kde.org/show_bug.cgi?id=371869 Ivo Raisr changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371869] support '%' in symbol Z-encoding
https://bugs.kde.org/show_bug.cgi?id=371869 --- Comment #1 from Ivo Raisr --- Created attachment 101900 --> https://bugs.kde.org/attachment.cgi?id=101900&action=edit proposed patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371869] support '%' in symbol Z-encoding
https://bugs.kde.org/show_bug.cgi?id=371869 Ivo Raisr changed: What|Removed |Added Attachment #101900|0 |1 is obsolete|| --- Comment #3 from Ivo Raisr --- Created attachment 101909 --> https://bugs.kde.org/attachment.cgi?id=101909&action=edit proposed patch v2 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371869] support '%' in symbol Z-encoding
https://bugs.kde.org/show_bug.cgi?id=371869
--- Comment #4 from Ivo Raisr ---
Well, umm, that is of course wrong. It should have read:
+ case 'P': EMITFN('%'); break;
case 'R': EMITFN(')'); break;
+ case 'S': EMITFN('/'); break;
Thank you for catching it! Have a look at patch #v2.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 371869] support '%' in symbol Z-encoding
https://bugs.kde.org/show_bug.cgi?id=371869 Ivo Raisr changed: What|Removed |Added Attachment #101909|0 |1 is obsolete|| --- Comment #5 from Ivo Raisr --- Created attachment 101910 --> https://bugs.kde.org/attachment.cgi?id=101910&action=edit proposed patch v3 And for memset%* replacement to work, the following needs to be changed as well: #define MEMSET(soname, fnname) \ - void* VG_REPLACE_FUNCTION_EZU(20210,soname,fnname) \ + void* VG_REPLACE_FUNCTION_EZZ(20210,soname,fnname) \ (void *s, Int c, SizeT n); \ - void* VG_REPLACE_FUNCTION_EZU(20210,soname,fnname) \ + void* VG_REPLACE_FUNCTION_EZZ(20210,soname,fnname) \ (void *s, Int c, SizeT n) \ -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371916] execution tree xtree concept
https://bugs.kde.org/show_bug.cgi?id=371916 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #3 from Ivo Raisr --- Thank you for this patch, Philippe. I was concentrating on the interface pub_tool_xtree.h in the first run and here are my questions and comments: 1. void*(*alloc_fn)(const HChar*, SizeT) in VG_(newXT)(). What is 'const HChar *' used for? I can imagine 'SizeT' is for the size. Perhaps if you can name the arguments, it would be clearer? Or you can give a hint that VG_(malloc)() and VG_(free)() are typically used for alloc_fn and free_fn? 2. What is 'ec' and 'IP' as referred to in VG_(newXT)()'? It is not explained in the file header. 3. What is argument 'cc' used for in VG_(newXT)()? 4. Functions in this header file use a mixture of camelCase and all_lower_case which is inconsistent and disturbs reader's eyes. Can you do something with it? 5. I wonder why VG_(init_XtAllocs)(), VG_(add_XtAllocs)(), VG_(sub_XtAllocs)() and VG_(img_XtAllocs)() do not use structure XtAllocs instead of 'void *'? Am I missing something? 6. XtAllocsEvents does not need to be exported. 7. For VG_(XtMemoryFull_free)(), does providing ec_alloc brings an unnecessary burden on the tool? Perhaps m_xtree.c could cache it? 8. VG_(XtMemory_report)() talks about xtree-memory=full, --xtree-memory=allocs and --xtree-memory=none. How one does set these? 9. "typedef void MsFile;" Surely we can do better with implementation hiding. Several lines above "typedef struct _XTree XTree;" was used, so what about: typedef struct _MsFile MsFile; 10. I also wonder why callgrind and massif specific functionality is contained in generic module xtree? Perhaps it could be located in the tools themselves? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371916] execution tree xtree concept
https://bugs.kde.org/show_bug.cgi?id=371916 --- Comment #4 from Ivo Raisr --- The idea of associating some data to execution contexts reminds me of an aggregation and quantization capabilities of DTrace in Solaris/illumos when applied to stack traces... Oh, the world is so small! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371869] support '%' in symbol Z-encoding
https://bugs.kde.org/show_bug.cgi?id=371869 Ivo Raisr changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||r16112 Status|CONFIRMED |RESOLVED --- Comment #6 from Ivo Raisr --- Fixed in SVN r16112. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371916] execution tree xtree concept
https://bugs.kde.org/show_bug.cgi?id=371916 Ivo Raisr changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #8 from Ivo Raisr --- Thank you, Philippe, for answering my questions. I have an additional one and then some docs stuff below. >> 4. Functions in this header file use a mixture of camelCase and >> all_lower_case which is inconsistent and disturbs reader's eyes. Can you do >> something with it? > Humph, that is a very valuable comment, but I am not sure what style > to use. Alright. But you can unify the function names so their names are consistent among themselves. Consider this random selection: VG_(newXT)() VG_(xt_filter_maybe_below_main)() VG_(xt_offset_main_or_below_main)() VG_(init_XtAllocs)() VG_(XtMemoryFull_init)() VG_(XtMemoryFull_resizeInPlace)() VG_(XtMemory_report)() VG_(snapshotXT)() VG_(subFromXT)() VG_(n_ips_sel)() VG_(XtPrint_callgrind)() VG_(XtClose_massif)() Sometimes the function name follows pattern: "XTthing_operation", sometimes "operationXT" and sometimes something completely different. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371916] execution tree xtree concept
https://bugs.kde.org/show_bug.cgi?id=371916 --- Comment #9 from Ivo Raisr --- As for the documentation, the concept is explained very well. Thank you for this! I found just few typos: When set to none, no memory execution - tree is be produced. + tree is produced. When set to allocs, the memory execution - tree gives the current number of allocated bytes and current number of + tree gives the current number of allocated bytes and the current number of allocated blocks. - bytes and blocks, the total number of freed bypes and + bytes and blocks, the total number of freed bytes and - an heap usage xtree graphical representation produced by + a heap usage xtree graphical representation produced by -curB current number of bytes allocated. The +curB current number of Bytes allocated. The -curBk current number of blocks allocated, +curBk current number of Blocks allocated, -An xtree file in a Callgrind Format contains a single callgraph, +An xtree file in the Callgrind Format contains a single callgraph, -An xtree file in a Massif Format contains one detailed tree +An xtree file in the Massif Format contains one detailed tree - visualiser are more versatile that the Massif Format + visualisers are more versatile than the Massif Format I also wonder if you can add a paragraph or two describing how to apply xtree analysis when profiling large programs, if possible? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371916] execution tree xtree concept
https://bugs.kde.org/show_bug.cgi?id=371916 --- Comment #13 from Ivo Raisr --- Thanks for addressing my comments. Especially for providing hints on Xtree usage! I am happy with the documentation and pub_tool_xtree.h interface. However note I have not reviewed any implementation files. The last remark I have: have you considered naming the xtree output file based on the executed program name, such as .kcg? Currently the default xtmemory.kcg will get overwritten every time, even for different profiled programs. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352395] Please provide SVN revision info in --version
https://bugs.kde.org/show_bug.cgi?id=352395 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #7 from Ivo Raisr --- I had a look and overall it looks pretty good. However 'pushd/popd' is a bash'ism and won't work in other shells. Please can you try this also under shells, for example ksh? What happens (and what is the version) if this is run not inside a SVN/GIT repository? For example one can run 'make dist', take the tarball, unpack it somewhere else and build the stuff again. Also this construct: "if test -d .svn; then svnversion -n .; elif test -d .git; then git svn info | \ grep ^Revision | cut -d ' ' -f2 | tr -d '\n'; fi" can be reused, for example through a Makefile variable: EXTRACT_SVN_VERSION = "" vgversion.h: ... ... $(shell $(EXTRACT_SVN_VERSION)) ... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 372600] process loops forever when fatal signals are arriving quickly
https://bugs.kde.org/show_bug.cgi?id=372600 Ivo Raisr changed: What|Removed |Added Latest Commit||r16147 CC||iv...@ivosh.net --- Comment #2 from Ivo Raisr --- Follow up revisions r16143 and r16147. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352395] Please provide SVN revision info in --version
https://bugs.kde.org/show_bug.cgi?id=352395 Ivo Raisr changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #15 from Ivo Raisr --- I agree with Philippe that vgversion.h should be a part of the tarball created by 'make dist'. This way it is very intuitive and reasonable. As regards the errors during 'make dist' build you encountered, they are most probably connected with missing packages for documentation build. See comments in docs/README which lists some distributions and the required packages. I will be happy to test 'make dist' for you on Solaris which is working as well. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352395] Please provide SVN revision info in --version
https://bugs.kde.org/show_bug.cgi?id=352395 --- Comment #20 from Ivo Raisr --- Patch #6 seems to be working well. I tested it on Solaris, inside SVN tree, outside and after 'make dist'. In addition to the last comment by Austin, please change also: auxprogs/make_or_upd_vgversion_h: - when using command lines options: -v --version + when using command line options: -v --version and make sure that auxprogs/make_or_upd_vgversion_h is marked as executable in SVN repository. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352395] Please provide SVN revision info in --version
https://bugs.kde.org/show_bug.cgi?id=352395 --- Comment #21 from Ivo Raisr --- There is also online tool at: http://www.shellcheck.net/ However it did not catch the problem with mismatched then... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 373046] Stacks registered by core are never deregistered
https://bugs.kde.org/show_bug.cgi?id=373046 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #2 from Ivo Raisr --- Follow up in SVN r16160. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 373069] memcheck/tests/leak_cpp_interior fails with GCC 5.1+
https://bugs.kde.org/show_bug.cgi?id=373069 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #1 from Ivo Raisr --- I cannot comment anything about std::string implementation. However for your second query have a look at bug: https://bugs.kde.org/show_bug.cgi?id=345307 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369854] Valgrind reports an Invalid Read in __intel_new_memcpy
https://bugs.kde.org/show_bug.cgi?id=369854 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #7 from Ivo Raisr --- I see you are stuck among all different parties, everyone saying "our part behaves ok; it's not our fault". At this point I'd suggest you do as folks on Intel forum suggested, in combination with gdb+vgdb [1]. Use '--vgdb-error=1' or an appropriate number which will stop the execution right upon reaching the reported problem. Disassemble the offending part of __intel_new_memcpy(), observe values of relevant registers and report back here. [1] http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390471] suppression by specification of source-file line number
https://bugs.kde.org/show_bug.cgi?id=390471 Ivo Raisr changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||iv...@ivosh.net Assignee|jsew...@acm.org |iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390471] suppression by specification of source-file line number
https://bugs.kde.org/show_bug.cgi?id=390471 Ivo Raisr changed: What|Removed |Added Attachment #110691|0 |1 is obsolete|| --- Comment #6 from Ivo Raisr --- Created attachment 113569 --> https://bugs.kde.org/attachment.cgi?id=113569&action=edit patch with NEWS updated Patch cleaned up. Tests still pending. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390471] suppression by specification of source-file line number
https://bugs.kde.org/show_bug.cgi?id=390471 Ivo Raisr changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Ivo Raisr --- Fixed in changeset 410d736a9928f535e2591c9d5f32e8e0941f96d8. https://sourceware.org/git/?p=valgrind.git;a=commitdiff;h=410d736a9928f535e2591c9d5f32e8e0941f96d8 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384727] [PATCH]valgrind does not support debug info for read only segments (generated by LLD)
https://bugs.kde.org/show_bug.cgi?id=384727 Ivo Raisr changed: What|Removed |Added Ever confirmed|0 |1 Assignee|jsew...@acm.org |iv...@ivosh.net Status|UNCONFIRMED |ASSIGNED CC||iv...@ivosh.net --- Comment #3 from Ivo Raisr --- Please could you try one of the patches from bug https://bugs.kde.org/show_bug.cgi?id=395682 These two bugs seem to be very similar. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384727] [PATCH]valgrind does not support debug info for read only segments (generated by LLD)
https://bugs.kde.org/show_bug.cgi?id=384727 Ivo Raisr changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #6 from Ivo Raisr --- *** This bug has been marked as a duplicate of bug 395682 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395682] Reading debug info of binaries with readonly PT_LOAD segments
https://bugs.kde.org/show_bug.cgi?id=395682 Ivo Raisr changed: What|Removed |Added CC||ori...@gmx.fr --- Comment #14 from Ivo Raisr --- *** Bug 384727 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381553] VEX register allocator v3
https://bugs.kde.org/show_bug.cgi?id=381553 --- Comment #75 from Ivo Raisr --- And thank you, Julian, for your guidance. Unfortunately I won't be able to finish the VEX enhancement/rework residing in (I think) vex-jit-hacks-2 branch. Perhaps some brave soul will be able to continue... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 396290] [PATCH] Possible tool - allocfail
https://bugs.kde.org/show_bug.cgi?id=396290
Ivo Raisr changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |CONFIRMED
CC||iv...@ivosh.net
--- Comment #5 from Ivo Raisr ---
Thank you for sharing this tool with the Valgrind community.
I can see value of this tool in its systemic way in which it fails the
application and taking a central place in an automated solution for checking
memory allocation problems.
The idea of storing call stacks instead of hashes is of course welcome, as it
is much more user friendly and configurable.
Please could you also fix some small problems in your code, such as using
"naked" C types (char), missing space between 'if' and '{'. Also do not include
system files (fcntl.h) - use Valgrind's own ones (VKI_O_RDONLY etc.).
As regards '--depth' command line argument, please could you explain why
existing --num-callers is not suitable to use?
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 384337] performance improvements to VEX register allocator v2 and v3
https://bugs.kde.org/show_bug.cgi?id=384337 Ivo Raisr changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #16 from Ivo Raisr --- Julian, I have closed this bug now. Register allocator v3 has been the default in Valgrid for many months and all the improvements from this bug which made sense have been already implemented. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 396290] [PATCH] Possible tool - allocfail
https://bugs.kde.org/show_bug.cgi?id=396290 --- Comment #7 from Ivo Raisr --- Alright, I think it would be preferable to have --num-callers used instead of --depth. Users are already familiar with --num-callers. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 385409] s390x: z13 vector integer instructions not implemented
https://bugs.kde.org/show_bug.cgi?id=385409 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #19 from Ivo Raisr --- (In reply to Andreas Arnez from comment #18) > Another suspicous construct is the type cast > (const s390x_vec_op_details_t*) &details > where 'details' is a ULong. I believe this violates the strict aliasing rule. Indeed. In short words strict aliasing says you are not allowed to view the same piece of memory through lenses of different types *other* than 'char *'. I debugged once a nasty problem in SPEC2017 CPU due to a strict aliasing violation combined with LTO. The question is also whether strict aliasing is enabled for this compilation unit... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 396290] [PATCH] Possible tool - allocfail
https://bugs.kde.org/show_bug.cgi?id=396290 --- Comment #10 from Ivo Raisr --- (In reply to Philippe Waroquiers from comment #9) > I am wondering also how much difficult it would be to somewhat more > generalise the tool. > > For example, we might want to make similar tests to check failing syscalls. Injecting failures in general is a very good topic. However given the imminent Valgrind release, we should decide if this exp-tool can make it for 3.14 in its current shape (and with some regtests available) or not. This decision eventually drives the scope... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 396290] [PATCH] Possible tool - allocfail
https://bugs.kde.org/show_bug.cgi?id=396290 --- Comment #13 from Ivo Raisr --- (In reply to roger.light from comment #8) > Created attachment 114229 [details] > Updated patch with fixes and text callstacks. Looks quite good. There are just few nits: - Please remove trailing whitespace you introduced (a few occurrences). For example 'git am' gives the list. - Please have a space between 'while' and the condition. - Please do better job with fixed size buffers (for example in write_callstack_line). Some times ago, Florian underwent a painful exercise auditing all fixed size buffers. - You can use C99 constructs. - Description for command line option --callstack-file deserves a better wording. - Description for command line option --show-fail-traces should be probably renamed to --show-failed-traces (or simply --show-failed). The sentence should start with capital letter anyway. - Fix indentation of function af_instrument. I will post my findings about using tool in a separate reply. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 396290] [PATCH] Possible tool - allocfail
https://bugs.kde.org/show_bug.cgi?id=396290 --- Comment #14 from Ivo Raisr --- The current exp-allocfail crashes badly on my Ubuntu 18.04 box. When running './vg-in-place --tool=exp-allocfail /bin/date', it crashes at af_main.c:119. That's because i is equal to an equivalent of '-1' (4294967295). You need to fix the code at af_main.c:96 - UInt i; + Int i; With this fix in place, I was able to play with ordinary Linux/UNIX standalone programs. Will try to do 'make dist' and check if everything works ok tomorrow. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 396290] [PATCH] Possible tool - allocfail
https://bugs.kde.org/show_bug.cgi?id=396290 --- Comment #20 from Ivo Raisr --- Thank you for your work. This is going to be a useful Valgrind tool. I like the documentation for the latest patch. Reasoning explained well on examples. You could mention that the default behaviour (fail unseen allocations) can be heavily tuned by options which are described later. As regards instrumentation: unfortunately I don't think the current scheme of detecting function entry/return w.r.t. --toggle-fn is going to work. Instruction instrumentation is done by blocks and their processing is mostly orthogonal to the actual execution. I think Callgrind tool solves similar problem - detecting when a function is entered and returned - try to have a look there. I think it still suffers from some limitations on arm architecture, though. For coding style - please use explicit check for NULL or != NULL. For example if (instr_callstack) => if (instr_callstack != NULL) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net Summary|false positive of |Add replacements for |__wcsnlen_sse4_1 with glibc |wmemchr and wcsnlen on |2.26|Linux -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 Ivo Raisr changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 --- Comment #4 from Ivo Raisr --- Thank you for the patch. I had to make some fixes to make it actually work and do not introduce regressions. Please review the attachment. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 Ivo Raisr changed: What|Removed |Added Attachment #111086|0 |1 is obsolete|| --- Comment #5 from Ivo Raisr --- Created attachment 42 --> https://bugs.kde.org/attachment.cgi?id=42&action=edit 0001-Add-replacements-for-wmemchr-and-wcsnlen-on-Linux.patch Fixed patch originally from Nick Alcock. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 --- Comment #7 from Ivo Raisr --- Oh, alright, let's make it Int also for wcslen() so the whole file is consistent. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 Ivo Raisr changed: What|Removed |Added Attachment #42|0 |1 is obsolete|| --- Comment #8 from Ivo Raisr --- Created attachment 43 --> https://bugs.kde.org/attachment.cgi?id=43&action=edit Add-replacements-for-wmemchr-and-wcsnlen-on-Linux Make wcslen() operate on Int as well. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 --- Comment #10 from Ivo Raisr --- :-) There was also a problem with the actual replacement definition. For example wcsnlen had the following: #if defined(VGO_linux) STRNLEN(VG_Z_LIBC_SONAME, wcsnlen) STRNLEN(VG_Z_LIBC_SONAME, __GI_wcsnlen) #endif This could not have worked. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 Ivo Raisr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Ivo Raisr --- Pushed as 23185f46a17079fcfca35c2ef335a598812cb23b. https://sourceware.org/git/?p=valgrind.git;a=commitdiff;h=23185f46a17079fcfca35c2ef335a598812cb23b -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390524] use of 0b prefix for binary constants
https://bugs.kde.org/show_bug.cgi?id=390524 Ivo Raisr changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390524] use of 0b prefix for binary constants
https://bugs.kde.org/show_bug.cgi?id=390524 Ivo Raisr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||iv...@ivosh.net Resolution|--- |WONTFIX --- Comment #3 from Ivo Raisr --- Support for binary constants has been around since gcc 4.3.0 (since 2008, 10 years ago). Also clang supports this notation. I don't see any reason why we need to prefer compatibility with ancient compilers over readability and maintainability. I think your case is a singular one; majority of LTS distros have moved off of such ancient gcc versions long time ago. You can't expect recent version of Valgrind work with an ancient version of the compiler; neither is the case of other toolchain components. There are going to be more and more cases of Valgrind using compiler features available only to reasonably recent compilers. You could get away for now with a simple patch, changing the binary constants into hexadecimal ones, for example. But with the evolution bringing new changes, you could end up with a huge patchset eventually. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 338252] building valgrind with -flto (link time optimisation) fails
https://bugs.kde.org/show_bug.cgi?id=338252 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #15 from Ivo Raisr --- (In reply to Дилян Палаузов from comment #14) > Autoconf users willing to compile everything with LTO just by calling > ./configure put in /usr/local/etc/config.site: > > CFLAGS="-O3 -fno-fat-lto-objects -flto" CXXFLAGS="-O3 -fno-fat-lto-objects > -flto" LDFLAGS="-Wl,-O1,-s -flto=4" > > And then any ./configure implies LTO. Just as other programs relying on > autoconf doing the right thing do not offer --enable-lto option in > ./configure --help, can be compiled with LTO, valgrind./configure --help > shall not print --enable-lto. Programmer printing on --help "--enable-lto" > don't understand autoconf. This applies also for artificially added -g or > -O2 from configure.ac or contained in Makefile* Thank you for this insight and sharing your approach. It is really helpful to know that other possibilities exists. However I modifying /usr/local/etc/config.site affects all projects build on a box. Also we cannot force Valgrind users and maintainers to modify global configuration file [consider shared build machines, for example in the gcc build farm]. Perhaps a merged approach could be found? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 387766] asm shifts cause false positive "Conditional jump or move depends on uninitialised value"
https://bugs.kde.org/show_bug.cgi?id=387766 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #2 from Ivo Raisr --- (In reply to Markus Trippelsdorf from comment #0) > Running gcc trunk under valgrind produces many false positives, e.g.: Please provide a simple standalone reproducer. For example, could a part of update_costs_from_copies() be isolated to reproduce the problem? There is also a patch for Valgrind which makes it to spend some extra time to accurately track definedness: https://bugs.kde.org/show_bug.cgi?id=387664 Please could you try to build Valgrind with this patch and then run it with --expensive-definedness-checks=yes (or --expensive-definedness-checks=auto). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381819] amd64: unhandled instruction bextr (0x8F 0xEA 0x78 0x10 0xD0 0x8 0x4) from BMI1
https://bugs.kde.org/show_bug.cgi?id=381819 --- Comment #15 from Ivo Raisr --- (In reply to Bernd Buschinski from comment #14) > any chance we can push/fix/update this to official valgrind? I would happy > to test new patches :) As discussed previously, the patch attached in this bug is not 100% perfect as it does not properly decode all bextr variants. So it is not ready yet to be integrated into Valgrind source code. And as Mark explained in bug 328357: According to https://en.wikipedia.org/wiki/Bit_Manipulation_Instruction_Sets#TBM_.28Trailing_Bit_Manipulation.29 TBM instructions are only supported on a few AMD processors (Piledriver, Steamroller and Excavator). > Btw is this also related to > https://bugs.kde.org/show_bug.cgi?id=328357? Do we have 3 bugreports for > (almost) the same thing? Probably yes. I will make this bug the main one and close the others. My take here is as follows: these instructions are supported only by a few AMD processors and later versions removed the support. So unless the community will be willing to dedicate some engineering time to support properly all the instruction variants, not much will happen. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381819] amd64: unhandled instruction bextr (0x8F 0xEA 0x78 0x10 0xD0 0x8 0x4) from BMI1
https://bugs.kde.org/show_bug.cgi?id=381819 --- Comment #16 from Ivo Raisr --- Created attachment 109550 --> https://bugs.kde.org/attachment.cgi?id=109550&action=edit support for TBM bextr Patch originally attached to bug https://bugs.kde.org/show_bug.cgi?id=322586 by "Petr Pisar" titled "support for TBM bextr". -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381819] amd64: unhandled instruction bextr (0x8F 0xEA 0x78 0x10 0xD0 0x8 0x4) from BMI1
https://bugs.kde.org/show_bug.cgi?id=381819 Ivo Raisr changed: What|Removed |Added CC||sgtcapsl...@lavabit.com --- Comment #17 from Ivo Raisr --- *** Bug 322586 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 322586] Unknown instruction (bextr) in ld-2.15.so with --march=native on AMD FX-8350
https://bugs.kde.org/show_bug.cgi?id=322586 Ivo Raisr changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||iv...@ivosh.net --- Comment #7 from Ivo Raisr --- The patch by "Petr Pisar" has been attached also to bug 381819. *** This bug has been marked as a duplicate of bug 381819 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381819] amd64: unhandled instruction bextr (0x8F 0xEA 0x78 0x10 0xD0 0x8 0x4) from BMI1
https://bugs.kde.org/show_bug.cgi?id=381819 Ivo Raisr changed: What|Removed |Added CC||x...@fictionpress.com --- Comment #18 from Ivo Raisr --- *** Bug 328357 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 328357] TBM bextr instruction unsupported vex amd64->IR: unhandled instruction bytes: 0x8F 0xEA 0xF8 0x10 0xEF 0x3 0x5 0x0
https://bugs.kde.org/show_bug.cgi?id=328357 Ivo Raisr changed: What|Removed |Added Resolution|--- |DUPLICATE CC||iv...@ivosh.net Status|UNCONFIRMED |RESOLVED --- Comment #10 from Ivo Raisr --- *** This bug has been marked as a duplicate of bug 381819 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388493] exp-sgcheck fails on DW_TAG_subrange_type
https://bugs.kde.org/show_bug.cgi?id=388493
Ivo Raisr changed:
What|Removed |Added
CC||iv...@ivosh.net
--- Comment #3 from Ivo Raisr ---
The DWARF problem is highly probably caused by an unimplemented functionality
in parse_type_DIE(). For DW_tag_subrange, the following is handled:
/* Figure out if we have a definite range or not */
if (have_lower && have_upper && (!have_count)) {
boundE.Te.Bound.knownL = True;
boundE.Te.Bound.knownU = True;
boundE.Te.Bound.boundL = lower;
boundE.Te.Bound.boundU = upper;
}
else if (have_lower && (!have_upper) && (!have_count)) {
boundE.Te.Bound.knownL = True;
boundE.Te.Bound.knownU = False;
boundE.Te.Bound.boundL = lower;
boundE.Te.Bound.boundU = 0;
}
else if ((!have_lower) && have_upper && (!have_count)) {
boundE.Te.Bound.knownL = False;
boundE.Te.Bound.knownU = True;
boundE.Te.Bound.boundL = 0;
boundE.Te.Bound.boundU = upper;
}
else if ((!have_lower) && (!have_upper) && (!have_count)) {
boundE.Te.Bound.knownL = False;
boundE.Te.Bound.knownU = False;
boundE.Te.Bound.boundL = 0;
boundE.Te.Bound.boundU = 0;
} else {
/* FIXME: handle more cases */
goto_bad_DIE;
}
So probably implementing the missing case would overcome the reported DWARF
problem.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 385408] s390x: z13 vector "support" instructions not implemented
https://bugs.kde.org/show_bug.cgi?id=385408 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 197915] 80-bit floats are not supported on x86 and x86-64
https://bugs.kde.org/show_bug.cgi?id=197915 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #33 from Ivo Raisr --- (In reply to Rich Felker from comment #32) > Is something blocking fixing this issue still? Lack of skilled manpower :-) Feel free to work this issue! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390723] New: make xtree dump files world wide readable, similar to log files
https://bugs.kde.org/show_bug.cgi?id=390723
Bug ID: 390723
Summary: make xtree dump files world wide readable, similar to
log files
Product: valgrind
Version: 3.14 SVN
Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: iv...@ivosh.net
Target Milestone: ---
There is no reason why xtree dump files should not be world wide readable,
similar to log files.
Users can always set the corresponding umask to tighten the permissions.
diff --git a/coregrind/m_xtree.c b/coregrind/m_xtree.c
index 7d5766222..217cad9da 100644
--- a/coregrind/m_xtree.c
+++ b/coregrind/m_xtree.c
@@ -377,7 +377,7 @@ static VgFile* xt_open (const HChar* outfilename)
VgFile* fp;
fp = VG_(fopen)(outfilename, VKI_O_CREAT|VKI_O_WRONLY|VKI_O_TRUNC,
- VKI_S_IRUSR|VKI_S_IWUSR);
+ VKI_S_IRUSR|VKI_S_IWUSR|VKI_S_IRGRP|VKI_S_IROTH);
if (fp == NULL) {
VG_(message)(Vg_UserMsg,
"Error: can not open xtree output file `%s'\n",
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 390723] make xtree dump files world wide readable, similar to log files
https://bugs.kde.org/show_bug.cgi?id=390723 Ivo Raisr changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390723] make xtree dump files world wide readable, similar to log files
https://bugs.kde.org/show_bug.cgi?id=390723 Ivo Raisr changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED CC||iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390723] make xtree dump files world wide readable, similar to log files
https://bugs.kde.org/show_bug.cgi?id=390723 Ivo Raisr changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #1 from Ivo Raisr --- Fixed in commit c014c2c43669106b4e2aeb6203a2fbe9e3e4ff48. https://sourceware.org/git/?p=valgrind.git;a=commitdiff;h=c014c2c43669106b4e2aeb6203a2fbe9e3e4ff48 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 162848] --log-file output isn't split when a program forks
https://bugs.kde.org/show_bug.cgi?id=162848 --- Comment #23 from Ivo Raisr --- Follow up commit in SVN r16210. Somehow I forgot to include the documentation changes previously... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 375772] New: +1 error in get_elf_symbol_info() when computing value of 'hi' address for ML_(find_rx_mapping)
https://bugs.kde.org/show_bug.cgi?id=375772 Bug ID: 375772 Summary: +1 error in get_elf_symbol_info() when computing value of 'hi' address for ML_(find_rx_mapping) Product: valgrind Version: 3.13 SVN Platform: Compiled Sources OS: Solaris Status: UNCONFIRMED Severity: crash Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: iv...@ivosh.net Target Milestone: --- Function ML_(find_rx_mapping)() expects 'lo' and 'hi' addresses. However get_elf_symbol_info() passes the following to it: ML_(find_rx_mapping)(di, (*sym_avmas_out).main,// lo (*sym_avmas_out).main + *sym_size_out); // hi Causing the debuginfo reader assert horribly when the last symbol ends precisely on the text segment end. I was able to reproduce this problem under special circumstances on sparcv9/Solaris platform, however it is generic. All other ML_(find_rx_mapping)() call sites account for 'lo'/'hi' argument semantics. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 375772] +1 error in get_elf_symbol_info() when computing value of 'hi' address for ML_(find_rx_mapping)
https://bugs.kde.org/show_bug.cgi?id=375772 Ivo Raisr changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net Ever confirmed|0 |1 CC||iv...@ivosh.net Status|UNCONFIRMED |CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 375772] +1 error in get_elf_symbol_info() when computing value of 'hi' address for ML_(find_rx_mapping)()
https://bugs.kde.org/show_bug.cgi?id=375772 Ivo Raisr changed: What|Removed |Added Summary|+1 error in |+1 error in |get_elf_symbol_info() when |get_elf_symbol_info() when |computing value of 'hi' |computing value of 'hi' |address for |address for |ML_(find_rx_mapping)|ML_(find_rx_mapping)() -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 375772] +1 error in get_elf_symbol_info() when computing value of 'hi' address for ML_(find_rx_mapping)()
https://bugs.kde.org/show_bug.cgi?id=375772 --- Comment #1 from Ivo Raisr --- Created attachment 103726 --> https://bugs.kde.org/attachment.cgi?id=103726&action=edit proposed patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 375772] +1 error in get_elf_symbol_info() when computing value of 'hi' address for ML_(find_rx_mapping)()
https://bugs.kde.org/show_bug.cgi?id=375772 Ivo Raisr changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ivo Raisr --- Fixed in SVN r16216. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 351043] Invalid XML output when tracing into forked child processes
https://bugs.kde.org/show_bug.cgi?id=351043 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #3 from Ivo Raisr --- This is probably fixed with the fix for bug 162848. Please report if Valgrind built from latest sources works for you. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 358620] ARM: disInstr(arm): unhandled instruction: 0xF1010200
https://bugs.kde.org/show_bug.cgi?id=358620 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #11 from Ivo Raisr --- I've done some googling for you as regards "unhandled instruction: 0xF1010200" and found this bug: https://bugs.kde.org/show_bug.cgi?id=322935 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388895] LibVEX_FrontEnd assertion failure: `0 == sizeof(VexGuestX86State) % LibVEX_GUEST_STATE_ALIGN'
https://bugs.kde.org/show_bug.cgi?id=388895 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #3 from Ivo Raisr --- SVN is a past thing. Valgrind lives in GIT now: http://valgrind.org/downloads/repository.html -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 389065] valgrind meets gcc flag -Wlogical-op
https://bugs.kde.org/show_bug.cgi?id=389065 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Ivo Raisr --- Thank you for the bug report. Indeed, the second one is a bug in Valgrind code. The first one is not a bug but merely a mental note for maintainer that this piece of code handles both pkhbt (tb == 0) and pkhbt (tb == 1) variants. Would you like to supply a patch for both the occurrences? Would you like to supply a patch for extending Valgrind build with -Wlogical-op (have a look at configure.ac, similar flags are enabled there). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384633] Add a simple progress-reporting facility
https://bugs.kde.org/show_bug.cgi?id=384633 Ivo Raisr changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #5 from Ivo Raisr --- (In reply to Julian Seward from comment #4) > Addresses all review comments in comments 2 and 3. Ivo, if you are > happy with it, could you please do the Solaris version of > VG_(get_user_milliseconds)? Will do that, Julian. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 389065] valgrind meets gcc flag -Wlogical-op
https://bugs.kde.org/show_bug.cgi?id=389065 Ivo Raisr changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net --- Comment #3 from Ivo Raisr --- Created attachment 109970 --> https://bugs.kde.org/attachment.cgi?id=109970&action=edit patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 389065] valgrind meets gcc flag -Wlogical-op
https://bugs.kde.org/show_bug.cgi?id=389065 Ivo Raisr changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #4 from Ivo Raisr --- The attached patch enables -Wlogical-op (if supported) and fixes an obvious typo. I used https://github.com/mirage/xen/blob/master/tools/libxc/xc_monitor.c for an inspiration. My gcc 7.2.0 on Ubuntu 17.10 did not report a problem in priv/guest_arm_toIR.c with -Wlogical-op. I guess the first reported problem must have been caused by some other factor. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384633] Add a simple progress-reporting facility
https://bugs.kde.org/show_bug.cgi?id=384633 Ivo Raisr changed: What|Removed |Added Attachment #109872|0 |1 is obsolete|| --- Comment #6 from Ivo Raisr --- Created attachment 109992 --> https://bugs.kde.org/attachment.cgi?id=109992&action=edit Patch with Solaris implementation added -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384633] Add a simple progress-reporting facility
https://bugs.kde.org/show_bug.cgi?id=384633 --- Comment #7 from Ivo Raisr --- Hi Julian, patch with Solaris implementation is attached. The patch has been refreshed to apply cleanly to the latest git HEAD and a NEWS entry added. It is ready to be pushed - let me know if I should do it. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384633] Add a simple progress-reporting facility
https://bugs.kde.org/show_bug.cgi?id=384633 Ivo Raisr changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Ivo Raisr --- Pushed as commit bd077baa71a40b60dcf0286b9fb89d803323fd93. https://sourceware.org/git/?p=valgrind.git;a=commit;h=bd077baa71a40b60dcf0286b9fb89d803323fd93 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 389065] valgrind meets gcc flag -Wlogical-op
https://bugs.kde.org/show_bug.cgi?id=389065 Ivo Raisr changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Ivo Raisr --- Fixed in commit f19a956e0a96b4f6b37c50b00ae24ecf09a7a3f5. https://sourceware.org/git/?p=valgrind.git;a=commitdiff;h=f19a956e0a96b4f6b37c50b00ae24ecf09a7a3f5 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 208052] strlcpy error when n = 0
https://bugs.kde.org/show_bug.cgi?id=208052 --- Comment #7 from Ivo Raisr --- Tom, would you mind integrating the fix into Valgrind source code base at this point? Alternatively, I could do it myself - just let me know. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 208052] strlcpy error when n = 0
https://bugs.kde.org/show_bug.cgi?id=208052 --- Comment #9 from Ivo Raisr --- Fixed in commit a5af4146e383dd442130905901b046e2cb4b0ed4, https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=a5af4146e383dd442130905901b046e2cb4b0ed4 NEWS updated in commit 4a8ea8908f7171f50ad3fa66346778e2f73e5976 https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=commit;h=4a8ea8908f7171f50ad3fa66346778e2f73e5976 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362223] assertion failed when .valgrindrc is a directory instead of a file
https://bugs.kde.org/show_bug.cgi?id=362223 Ivo Raisr changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Ivo Raisr --- Committed in Valgrind SVN as r16364. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 370028] Reduce the number of compiler warnings on MIPS platforms
https://bugs.kde.org/show_bug.cgi?id=370028 --- Comment #36 from Ivo Raisr --- (In reply to Tamara Vlahovic from comment #35) Committed in Valgrind SVN as r16365. Nice approach, thank you for the patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362223] assertion failed when .valgrindrc is a directory instead of a file
https://bugs.kde.org/show_bug.cgi?id=362223 --- Comment #15 from Ivo Raisr --- Follow up commit SVN r16366. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379744] disInstr(arm): unhandled instruction: 0xEEBE2AC6 (valgrind-3.9.0)
https://bugs.kde.org/show_bug.cgi?id=379744 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #1 from Ivo Raisr --- Please could you supply the unhandled instruction name? You can use objdump or gdb, for example. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 370028] Reduce the number of compiler warnings on MIPS platforms
https://bugs.kde.org/show_bug.cgi?id=370028 --- Comment #39 from Ivo Raisr --- (In reply to Tamara Vlahovic from comment #37) Committed in Valgrind SVN as r16368. Thank you for the patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 370028] Reduce the number of compiler warnings on MIPS platforms
https://bugs.kde.org/show_bug.cgi?id=370028 --- Comment #40 from Ivo Raisr --- (In reply to Tamara Vlahovic from comment #38) I've had a look at patch for x87 stuff. While passing Fpu_State* instead of UChar* is a good idea, on the other hand changing UChar[80] to UShort[40] is not a very good idead, though. As you are aware, the real x87 layout contains 8 registers per 80 bits (10 bytes). So it is hard to express 80 bits as a natural C type; and that is the reason why UChar[80] was chosen. In addition to that, Fpu_State_16 still contains UChar[80], leading to confusion. I don't know if there is a good/straightforward way how to mitigate warnings for reg[80]. Perhaps some kind of union? If you are not sure, then split the patch and I will take in Fpu_State* stuff while you can work on reg[80] part. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379748] [PATCH] Missing pselect syscall (OS X 10.12)
https://bugs.kde.org/show_bug.cgi?id=379748 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #1 from Ivo Raisr --- POSIX does not mandate pselect kernel interface; it mandates only pselect system (library) interface. Therefore placing pselect syscall wrapper in syswrap-generic. is not very fortunate. Have a look at other OSes and their kernel interfaces - Linux has pselect6, Solaris has no pselect at all (libc bases it directly on ppoll). Only *BSD seems to have the same kernel interface as OS X does. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 368529] Android arm target link error, missing atexit and pthread_atfork
https://bugs.kde.org/show_bug.cgi?id=368529 Ivo Raisr changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net CC||iv...@ivosh.net Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #6 from Ivo Raisr --- I will have a look. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379744] disInstr(arm): unhandled instruction: 0xEEBE2AC6 (vcvt.s32.f32)
https://bugs.kde.org/show_bug.cgi?id=379744 Ivo Raisr changed: What|Removed |Added Summary|disInstr(arm): unhandled|disInstr(arm): unhandled |instruction: 0xEEBE2AC6 |instruction: 0xEEBE2AC6 |(valgrind-3.9.0)|(vcvt.s32.f32) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379744] disInstr(arm): unhandled instruction: 0xEEBE2AC6 (vcvt.s32.f32)
https://bugs.kde.org/show_bug.cgi?id=379744 Ivo Raisr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Ivo Raisr --- Next time please do not report bugs against s old releases - ideally try with sources compiled from source repository. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 368529] Android arm target link error, missing atexit and pthread_atfork
https://bugs.kde.org/show_bug.cgi?id=368529 Ivo Raisr changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #7 from Ivo Raisr --- I am a little worried about this condition in the patch: #if defined(ANDROID) && defined(__clang__) Nowhere in Valgrind sources we currently base a decision on naked "ANDROID". It is always this combo (from vki-linux.h): #if defined(VGPV_arm_linux_android) || defined(VGPV_x86_linux_android) \ || defined(VGPV_mips32_linux_android) \ || defined(VGPV_arm64_linux_android) ... #endif /* defined(VGPV_*_linux_android) */ If this patch is really arm-android specific, then it should fold inside existing #if defined(VGP_arm_linux) [at line 2424] ... #endif [at line 2442] with a guard such as: #if defined(VGPV_arm_linux_android) ... #endif No need to "defined(__clang__)". Let me know what is the case here. Please eventually modify the patch and test it on arm. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 374963] increase valgrind's load address to prevent mmap failure
https://bugs.kde.org/show_bug.cgi?id=374963 Ivo Raisr changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net Status|CONFIRMED |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379838] New: disAMode(x86): not an addr!
https://bugs.kde.org/show_bug.cgi?id=379838 Bug ID: 379838 Summary: disAMode(x86): not an addr! Product: valgrind Version: 3.13 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: crash Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: iv...@ivosh.net Target Milestone: --- Running DRD or Helgrind on test case helgrind/tests/tc12_rwl_trivial compiled in 32-bit mode (X86) produces the following crash: $ ./vg-in-place --tool=helgrind helgrind/tests/tc12_rwl_trivial ==29388== Helgrind, a thread error detector ==29388== Copyright (C) 2007-2017, and GNU GPL'd, by OpenWorks LLP et al. ==29388== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for copyright info ==29388== Command: helgrind/tests/tc12_rwl_trivial ==29388== ==29388== ---Thread-Announcement-- ==29388== ==29388== Thread #1 is the program's root thread ==29388== ==29388== ==29388== ==29388== Thread #1 unlocked a not-locked lock at 0xFEA5ADEC ==29388==at 0x48333AB: pthread_rwlock_unlock_WRK (hg_intercepts.c:2540) ==29388==by 0x4834D7C: pthread_rwlock_unlock (hg_intercepts.c:2559) ==29388==by 0x10891F: safe_pthread_rwlock_unlock (safe-pthread.h:58) ==29388==by 0x108AF9: main (tc12_rwl_trivial.c:29) ==29388== Lock at 0xFEA5ADEC was first observed ==29388==at 0x4832D45: pthread_rwlock_init_WRK (hg_intercepts.c:2027) ==29388==by 0x4834D2E: pthread_rwlock_init (hg_intercepts.c:2042) ==29388==by 0x10898D: main (tc12_rwl_trivial.c:18) ==29388== Address 0xfea5adec is on thread #1's stack ==29388== in frame #3, created by main (tc12_rwl_trivial.c:14) ==29388== ==29388== vex: the `impossible' happened: disAMode(x86): not an addr! vex storage: T total 32739272 bytes allocated vex storage: P total 384 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==29388==at 0x5802918B: show_sched_status_wrk (m_libcassert.c:355) ==29388==by 0x580292BD: report_and_quit (m_libcassert.c:426) ==29388==by 0x5802946C: panic (m_libcassert.c:502) ==29388==by 0x5802946C: vgPlain_core_panic_at (m_libcassert.c:507) ==29388==by 0x5802948A: vgPlain_core_panic (m_libcassert.c:512) ==29388==by 0x580449FC: failure_exit (m_translate.c:740) ==29388==by 0x581062F3: vpanic (main_util.c:231) ==29388==by 0x5812886B: disAMode (guest_x86_toIR.c:1564) ==29388==by 0x58148B0C: disInstr_X86_WRK (guest_x86_toIR.c:15322) ==29388==by 0x5814A3A1: disInstr_X86 (guest_x86_toIR.c:15456) ==29388==by 0x5811D570: bb_to_IR (guest_generic_bb_to_IR.c:365) ==29388==by 0x5810370F: LibVEX_FrontEnd (main_main.c:558) ==29388==by 0x58103F42: LibVEX_Translate (main_main.c:1173) ==29388==by 0x580472B7: vgPlain_translate (m_translate.c:1791) ==29388==by 0x58082558: handle_chain_me (scheduler.c:1084) ==29388==by 0x58084257: vgPlain_scheduler (scheduler.c:1428) ==29388==by 0x58094FA7: thread_wrapper (syswrap-linux.c:103) ==29388==by 0x58094FA7: run_a_thread_NORETURN (syswrap-linux.c:156) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 29388) ==29388==at 0x4873818: _xend (pthread_rwlock_unlock.c:38) ==29388==by 0x4873818: pthread_rwlock_unlock (pthread_rwlock_unlock.c:38) ==29388==by 0x48333DA: pthread_rwlock_unlock_WRK (hg_intercepts.c:2543) ==29388==by 0x4834D7C: pthread_rwlock_unlock (hg_intercepts.c:2559) ==29388==by 0x10891F: safe_pthread_rwlock_unlock (safe-pthread.h:58) ==29388==by 0x108AF9: main (tc12_rwl_trivial.c:29) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. $ file helgrind/tests/tc12_rwl_trivial helgrind/tests/tc12_rwl_trivial: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=f5d2b09e348834b0a9c00c65487771d10f9bbc1f, not stripped $ gcc --version gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ./vg-in-place --version -v valgrind-3.13.0.SVN-16373M-vex-3369 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379838] disAMode(x86): not an addr!
https://bugs.kde.org/show_bug.cgi?id=379838 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #1 from Ivo Raisr --- The problem is reproducible even with 'none' tool: $ ./vg-in-place --tool=none helgrind/tests/tc12_rwl_trivial ==29554== Nulgrind, the minimal Valgrind tool ==29554== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote. ==29554== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for copyright info ==29554== Command: helgrind/tests/tc12_rwl_trivial ==29554== vex: the `impossible' happened: disAMode(x86): not an addr! vex storage: T total 26363116 bytes allocated vex storage: P total 384 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==29554==at 0x580A62CB: show_sched_status_wrk (m_libcassert.c:355) ==29554==by 0x580A63FD: report_and_quit (m_libcassert.c:426) ==29554==by 0x580A65AC: vgPlain_core_panic_at (m_libcassert.c:502) ==29554==by 0x580A65CA: vgPlain_core_panic (m_libcassert.c:512) ==29554==by 0x58019F6C: failure_exit (m_translate.c:740) ==29554==by 0x580E76B3: vpanic (main_util.c:231) ==29554==by 0x58109C2B: disAMode (guest_x86_toIR.c:1564) ==29554==by 0x58129ECC: disInstr_X86_WRK (guest_x86_toIR.c:15322) ==29554==by 0x5812B761: disInstr_X86 (guest_x86_toIR.c:15456) ==29554==by 0x580FE930: bb_to_IR (guest_generic_bb_to_IR.c:365) ==29554==by 0x580E4ACF: LibVEX_FrontEnd (main_main.c:558) ==29554==by 0x580E5302: LibVEX_Translate (main_main.c:1173) ==29554==by 0x5801C827: vgPlain_translate (m_translate.c:1791) ==29554==by 0x58053368: handle_chain_me (scheduler.c:1084) ==29554==by 0x58055067: vgPlain_scheduler (scheduler.c:1428) ==29554==by 0x58065DB7: run_a_thread_NORETURN (syswrap-linux.c:103) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 29554) ==29554==at 0x485F818: pthread_rwlock_unlock (pthread_rwlock_unlock.c:38) ==29554==by 0x10891F: safe_pthread_rwlock_unlock (safe-pthread.h:58) ==29554==by 0x108AF9: main (tc12_rwl_trivial.c:29) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379838] disAMode(x86): not an addr!
https://bugs.kde.org/show_bug.cgi?id=379838 Ivo Raisr changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #4 from Ivo Raisr --- Seems like the offending instruction is 'xend' from __pthread_rwlock_unlock(). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 374963] increase valgrind's load address to prevent mmap failure
https://bugs.kde.org/show_bug.cgi?id=374963 --- Comment #4 from Ivo Raisr --- Created attachment 105544 --> https://bugs.kde.org/attachment.cgi?id=105544&action=edit patch to increase load address for almost all platforms to 0x5800 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 374963] increase valgrind's load address to prevent mmap failure
https://bugs.kde.org/show_bug.cgi?id=374963 --- Comment #5 from Ivo Raisr --- Please test the attached patch [1] which increases the load address for almost all platforms to 0x5800 (from 0x3800). This gives another 512 MB for executable without changing linkage model (which is different on every platform). I've tested on x86/Linux, amd64/Linux, x86/Solaris, amd64/Solaris. 32-bit only, 64-bit only, mix and outer/inner setup. [1] https://bugs.kde.org/attachment.cgi?id=105544 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379838] disAMode(x86): not an addr!
https://bugs.kde.org/show_bug.cgi?id=379838 Ivo Raisr changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #5 from Ivo Raisr --- VEX SVN commit r3370. Valgrind SVN commit 16375. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 378430] www: update Valgrind alias mirrors
https://bugs.kde.org/show_bug.cgi?id=378430 Ivo Raisr changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #1 from Ivo Raisr --- Commited in Valgrind www SVN as r520. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360415] amd64 instructions ADCX and ADOX are not implemented in VEX
https://bugs.kde.org/show_bug.cgi?id=360415 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #16 from Ivo Raisr --- Running the latest Valgrind on regression test fb_test_amd64 built with gcc 5.4.0 gives the following crash: vex amd64->IR: unhandled instruction bytes: 0x66 0x4D 0xF 0x38 0xF6 0xC5 0x9C 0x58 0x48 0x83 vex amd64->IR: REX=1 REX.W=1 REX.R=1 REX.X=0 REX.B=1 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=0F38 vex amd64->IR: PFX.66=1 PFX.F2=0 PFX.F3=0 ==1119== valgrind: Unrecognised instruction at address 0x409768. ==1119==at 0x409768: exec_adcx (fb_test_amd64.h:69) ==1119==by 0x409806: test_adcx (fb_test_amd64.h:166) ==1119==by 0x411652: main (fb_test_amd64.c:1201) Disassembly indeed shows it is adcx: 0x00409767 <+405>: popfq => 0x00409768 <+406>: adcx %r13,%r8 0x0040976e <+412>: pushfq (gdb) x/16xb 0x409768 0x409768 : 0x660x4d0x0f0x380xf60xc5 0x9c0x58 0x409770 : 0x480x830xec0x080x250xd5 0x080x00 ./vg-in-place --version -v valgrind-3.13.0.SVN-16374-vex-3369 Is it possible that some paths in adcx decoding are not handled properly? -- You are receiving this mail because: You are watching all bug changes.
