[valgrind] [Bug 390524] use of 0b prefix for binary constants
https://bugs.kde.org/show_bug.cgi?id=390524 --- Comment #2 from Jeff Frontz <jeff.fro...@gmail.com> --- Note -- the target application is in a regulated industry and the development environment has all been validated (i.e., changing-up to a later version of gcc isn't in the cards for quite a while). Would it be at least possible to add some sort of config (in combination with a variably defined #define for the constant)? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390792] 'impossible' happened in dh_handle_noninsn_write()
https://bugs.kde.org/show_bug.cgi?id=390792 --- Comment #1 from Jeff Frontz <jeff.fro...@gmail.com> --- I changed the tl_assert(0) in dh_handle_noninsn_write() to print out the unhandled value (a la 'tl_assert2(0, "part is %d", part);'): DHAT: dh_main.c:756 (dh_handle_noninsn_write): the 'impossible' happened. DHAT: part is 6 Adding the runtime arguments "--run-libc-freeres=no --run-cxx-freeres=no" (per https://sourceforge.net/p/valgrind/mailman/message/35910210/ ) seems to make things better. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390792] New: 'impossible' happened in dh_handle_noninsn_write()
https://bugs.kde.org/show_bug.cgi?id=390792 Bug ID: 390792 Summary: 'impossible' happened in dh_handle_noninsn_write() Product: valgrind Version: 3.14 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: dhat Assignee: jsew...@acm.org Reporter: jeff.fro...@gmail.com Target Milestone: --- During process termination of a dhat-instrumented run, the following appeared. The valgrind process apparently then exited with a "1". DHAT: dh_main.c:756 (dh_handle_noninsn_write): the 'impossible' happened. host stacktrace: ==4307==at 0x58007362: show_sched_status_wrk (m_libcassert.c:355) ==4307==by 0x5800781E: report_and_quit (m_libcassert.c:426) ==4307==by 0x5800781E: vgPlain_assert_fail (m_libcassert.c:492) ==4307==by 0x5800252C: dh_handle_noninsn_write (dh_main.c:756) ==4307==by 0x58013248: final_tidyup (m_main.c:2325) ==4307==by 0x5801374C: shutdown_actions_NORETURN (m_main.c:2090) ==4307==by 0x580AD9AF: run_a_thread_NORETURN (syswrap-linux.c:203) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 4307) ==4307==at 0x40014A6: _vgnU_freeres (vg_preloaded.c:59) ==4307==by 0x2: ??? ==4307==by 0xB76F77: (below main) (in /lib/libc-2.6.so) -- 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 --- Comment #5 from Jeff Frontz <jeff.fro...@gmail.com> --- I'm not sure what the protocol is for creating test cases (I can't seem to get them to work in my environment) but if someone can give me a pointer, I'll do my best to create something. I tested this on x86 linux (FC7); building required modification per https://bugs.kde.org/show_bug.cgi?id=390524 -- 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 --- Comment #4 from Jeff Frontz <jeff.fro...@gmail.com> --- Created attachment 110691 --> https://bugs.kde.org/attachment.cgi?id=110691=edit Patch against 3.14.0 src & doc to implement/document suppression-by-file -- 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 --- Comment #1 from Jeff Frontz <jeff.fro...@gmail.com> --- Converting the constant to a simple 0x10 seems to make everything better (at least as far as compilation and running on x86 linux). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390524] New: use of 0b prefix for binary constants
https://bugs.kde.org/show_bug.cgi?id=390524
Bug ID: 390524
Summary: use of 0b prefix for binary constants
Product: valgrind
Version: 3.14 SVN
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: vex
Assignee: jsew...@acm.org
Reporter: jeff.fro...@gmail.com
Target Milestone: ---
Was there a conscious decision to begin using 0b prefixes [more widely] in
3.14.0?
I'm trying to build 3.14.0 on/for an x86 linux box using gcc 4.1.2 (it's an old
FC7 distro that we're using for an embedded application). I pulled the 3.14.0
valgrind source from the repository using git, ran the autogen, followed by
"./configure prefix=$HOME/valgrind exec_prefix=$HOME/valgrind", and make.
The build chokes on a binary constant ("0b0001") at line 1802 in
priv/guest_s390_toIR.c:
priv/guest_s390_toIR.c:1802:43: error: invalid suffix "b0001" on integer
constant
3.13.0 builds fine (though I didn't use git to pull it -- I just used the
source tarball).
I noticed that there are uses of the "0b" prefix in 3.13.0, but that seems to
be limited to the ARM architectures (where presumably all the SDKs are
relatively new and support "0b" use).
Would it be possible to avoid use of "0b" in the x86 flavors?
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 390471] New: suppression by specification of source-file line number
https://bugs.kde.org/show_bug.cgi?id=390471
Bug ID: 390471
Summary: suppression by specification of source-file line
number
Product: valgrind
Version: 3.13.0
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: wishlist
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: jeff.fro...@gmail.com
Target Milestone: ---
Several years ago (2005), Joe Link submitted a patch to allow specification of
line numbers in suppression expressions
(https://sourceforge.net/p/valgrind/mailman/message/14023169/ )
[E.g., in Joe's words:
support for suppression entries such as:
{
allocator
Memcheck:Leak
fun:_Znaj
src:quick_allocator.hpp:97
}
{
allocator
Memcheck:Leak
fun:_Znaj
src:quick_allocator.hpp
}
]
According to Ivo Raisr, this patch was never incorporated
(https://sourceforge.net/p/valgrind/mailman/message/36225028/ )
I've modified Joe's original patch to conform to the new[er] infrastructure in
a copy of the 3.13.0 source. I'm clueless as to how to go about submitting the
changes for review (and potential inclusion). Do I just attach a diff/patch
file to this request? Or should I try to integrate it with a private version
of 3.14.0 first (and then attach a diff/patch)? Or something else?
--
You are receiving this mail because:
You are watching all bug changes.
