You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
|
2
(1) |
|
3
|
4
(4) |
5
(4) |
6
|
7
|
8
|
9
|
|
10
(2) |
11
(2) |
12
(2) |
13
|
14
|
15
(2) |
16
(1) |
|
17
(2) |
18
(2) |
19
(3) |
20
(4) |
21
(1) |
22
|
23
|
|
24
(7) |
25
|
26
(4) |
27
(7) |
28
(2) |
29
(1) |
30
(2) |
|
31
|
|
|
|
|
|
|
|
From: <sv...@va...> - 2016-07-04 11:17:46
|
Author: sewardj
Date: Mon Jul 4 12:17:37 2016
New Revision: 15899
Log:
Update the bug list.
Modified:
trunk/docs/internals/3_11_BUGSTATUS.txt
Modified: trunk/docs/internals/3_11_BUGSTATUS.txt
==============================================================================
--- trunk/docs/internals/3_11_BUGSTATUS.txt (original)
+++ trunk/docs/internals/3_11_BUGSTATUS.txt Mon Jul 4 12:17:37 2016
@@ -223,3 +223,106 @@
358637 produces invalid xml
Thu 28 Jan 13:20:02 CET 2016
+
+358697 valgrind.h: Some code remains even when defining NVALGRIND
+358856 unhandled instruction bytes: 0xC4 0xE2 0x7B 0xF7
+358980 32 byte leak reported when code uses dlopen and links against pthread
+358988 rdrand support missing: 0x48 0xF 0xC7 0xF1 ...
+359133 m_deduppoolalloc.c:258 (vgPlain_allocEltDedupPA):
+ Assertion 'eltSzB <= ddpa->poolSzB' failed.
+359181 Buffer Overflow during Demangling
+359201 futex syscall "skips" argument 5 if op is FUTEXT_WAIT_BITSET
+359202 Add musl libc configure/compile
+359249 valgrind unable to load 64-bit linux executable
+ linked with -mcmodel=medium
+359264 Memcheck shows 2,064 bytes possibly lost and 20,036 suppressed bytes
+ in simplistic program on OS X El Capitan
+359289 s390x: popcnt (B9E1) not implemented
+359472 The Power PC vsubuqm instruction doesn't always give the correct result.
+359503 Add missing syscalls for aarch64 (arm64)
+359524 bt, btc, btr and bts instruction improperly translated by VEX on x86-64
+359645 [patch] "You need libc6-dbg" help message could be more helpful
+ with 32-bit target on-64-bit arch
+359703 s390: wire up separate socketcalls system calls
+359705 memcheck causes segfault on a dynamically-linked test from
+ rustlang's test suite on i686
+359724 getsockname syscall might crash - deref_UInt should check make
+ sure it is safe to deref
+359733 amd64 implement strchr/index override to avoid need for suppression
+ and redirection like x86
+359767 Valgrind does not support the IBM POWER ISA 3.0 instructions
+359829 Power PC test suite none/tests/ppc64/test_isa_2_07.c uses
+ uninitialzed data
+359838 arm64: Unhandled instruction 0xD5033F5F (clrex)
+359871 Incorrect mask handling in ppoll
+359920 Configure fails with relative DESTDIR
+359950 Wrong result comparing doubles on x87
+359952 Unrecognised PCMPESTRM variants
+360008 Contents of Power vr registers contents is not printed correctly
+ when the --vgdb-shadow-registers=yes option is used.
+360035 POWER PC instruction bcdadd and bcdsubtract generate result with
+ non-zero shadow bits
+360188 Valgrind does not build
+360378 arm64: Unhandled instruction 0x5E280844 (sha1h s4, s2)
+360415 amd64 instructions ADCX and ADOX are not implemented in VEX
+360425 arm64 unsupported instruction ldpsw
+360429 Warning: noted but unhandled ioctl 0x530d with no size/direction hints.
+360519 none/tests/arm64/memory.vgtest might fail with newer gcc
+360557 helgrind reports data race which I can't see (involves rwlocks)
+360571 Error about the Android Runtime reading below the stack pointer on ARM
+360574 Wrong parameter type for an ashmem ioctl() call on Android and ARM64
+360749 kludge for multiple .rodata sections on Solaris no longer needed
+360752 raise the number of reserved fds in m_main.c from 10 to 12
+361207 Valgrind does not support the IBM POWER ISA 3.0 instructions, part 2
+361226 s390x: risbgn (EC59) not implemented
+361253 [s390x] ex_clone.c:42: undefined reference to `pthread_create'
+361351 Assertion failure analyzing SDL_Init()
+361354 ppc64[le]: wire up separate socketcalls system calls
+361405 disInstr(ppc): unhandled instruction: 0xFF81010C
+361504 dlopen()/dlclose() and shared object usage check
+361615 Inconsistent termination when an instrumented multithreaded process
+ is terminated by signal
+361726 WARNING:unhandled syscall on ppc64
+361770 Missing F_ADD_SEALS
+361810 valgrind duplicate stdin after fork
+361926 unhandled x86-solaris syscall: 84
+362009 Valgrind dumps core on unimplemented functionality before threads
+ are created
+362033 undeclared identifier build failures for getpid(), usleep(),
+ and getuid()
+362223 valgrind: m_commandline.c:79 (read_dot_valgrindrc):
+ Assertion 'n >= 0 && n <= stat_buf.size+1' failed.
+362329 Valgrind does not support the IBM POWER ISA 3.0 instructions, part 3
+362680 --error-exitcode not honored when file descriptor leaks are found
+362892 test apk in android5.0.2,after fix the bug 344802,android log
+ "Unable to create protected region in stack for implicit overflow
+ check. Reason: Out of memory size: 4096"
+362894 missing (broken) support for wbit field on mtfsfi instruction (ppc64)
+362920 valgrind refuses to execute pkcs11-tool binary from OpenSC:
+ assertion 'tst->os_state.pthread - magic_delta == self' failed
+362934 [AsusWRT] Arm v7 illegal instruction
+362935 [AsusWRT] Assertion 'sizeof(TTEntryC) <= 88' failed
+362939 test apk in android 5.0 or most,at 0x6A23AB4:
+ art::Thread::InstallImplicitProtection() (in /system/lib/libart.so)
+362953 Request for an update to the Valgrind Developers page
+363123 SIGSEGV on Mac OS with very simple threaded code
+363497 Crash if i run valgrind on any working program -> valgrind:
+ the 'impossible' happened: LibVEX called failure_exit()
+363680 add renameat2() support
+363705 arm64 missing syscall name_to_handle_at and open_by_handle_at
+363714 ppc64 missing syscalls sync, waitid and name_to/open_by_handle_at
+363740 Possible data race in vgPlain_amd64_linux_REDIR_FOR_vgettimeofday
+363858 Add IBM ISA 3.0 support, patch set 4
+364058 array overruns are not detected
+364279 False "Uninitialized" on atomic_compare_exchange
+364359 Valgrind crashes on fcntl(F_SETFL, O_NONBLOCK, fd)
+364413 pselect sycallwrapper mishandles NULL sigmask
+364435 Crash - Unrecognized instruction for Arm64 LDPSW
+364497 Run valgrind on nginx
+364533 Process terminating with default action of signal 4 (SIGILL): dumping
+ core, : at 0x4000E7C: ??? (in /lib/ld-uClibc.so.0)
+364728 Power PC, missing support for several HW registrs i
+ n get_otrack_shadow_offset_wrk()
+364948 Add IBM ISA 3.0 support, patch set 5
+
+Mon 4 Jul 13:10:42 CEST 2016
|
|
From: Earl C. <ear...@ya...> - 2016-07-04 08:56:55
|
I believe I have found a problem with handling of signals in a multithreaded program. I think I'm close to the root cause and would appreciate advice in where to look next. I have been seeing an intermittent error message regarding an invalid write to a stack location reported by valgrind. Near the time of failure, two threads are running (main thread, and one other), and a signal (SIGCHLD) is delivered to a signal handler which runs in the main thread. The invalid write is reported after the signal handler returns. I see this problem on valgrind 3.11 and earlier. ==25683== Invalid write of size 4 ==25683== at 0x806E19A: eventclockTime (timekeeping_.c:249) ... ==25683== Address 0xbeb6e680 is on thread 1's stack ==25683== in frame #0, created by eventclockTime (timekeeping_.c:246) This problem seems sensitive to stack layout (eg removing environment variables seems to make the problem go away), architecture (eg I see this on x86 Linux, but I have not observed this on x86_64), and timing (ie the problem does not occur on every run, and the functions in question are called frequently). Just before the failure, the main thread runs. I've added some extra instrumentation that is prefixed with "+ " showing stack activation around the failing address (which in this case is 0xbeb6e680): + mc_new_mem_stack 0xbeb6e650 0x5c 0x0 current_stack 0xBEB6E000-0xBEB6FFFF 0 new_SP 0xBEB6E62C old_SP 0xBEB6E640 current_stack 0xBEB6E000-0xBEB6FFFF 0 new_SP 0xBEB6E640 old_SP 0xBEB6E62C + mc_storev32 25683 4960 vbits32 0x0 0xbeb6e680 vabits8 0x55 + mc_storev32 25683 4973 0xbeb6e680 vabits8 0xaa current_stack 0xBEB6E000-0xBEB6FFFF 0 new_SP 0xBEB6E6AC old_SP 0xBEB6E650 + mc_die_mem_stack 0xbeb6e650 0x5c 0x0 + set_address_range_perms 1738 3514 0xbeb6e680 len 44 smoff 7376 vabits16 0 current_stack 0xBEB6E000-0xBEB6FFFF 0 new_SP 0xBEB6E670 old_SP 0xBEB6E6AC + mc_new_mem_stack 0xbeb6e670 0x3c 0x0 current_stack 0xBEB6E000-0xBEB6FFFF 0 new_SP 0xBEB6E6AC old_SP 0xBEB6E670 + mc_die_mem_stack 0xbeb6e670 0x3c 0x0 + set_address_range_perms 1738 3514 0xbeb6e680 len 44 smoff 7376 vabits16 0 current_stack 0xBEB6E000-0xBEB6FFFF 0 new_SP 0x482C494 old_SP 0x482C494 new current_stack 0x4630000-0x482EFFF 1 At this point, the other thread runs, and execution seems to switch between the two: ... current_stack 0x4630000-0x482EFFF 1 new_SP 0x482C4A4 old_SP 0x482C480 current_stack 0xBEB6E000-0xBEB6FFFF 0 new_SP 0xBEB6E490 old_SP 0xBEB6E4CC current_stack 0x4630000-0x482EFFF 1 new_SP 0x482C4A4 old_SP 0x482C4A4 ... Eventually, the SIGCHLD is delivered: current_stack 0x4630000-0x482EFFF 1 new_SP 0xBEB6E6B0 old_SP 0xBEB6E6B0 new current_stack 0xBEB6E000-0xBEB6FFFF 0 + sigframe_create prev eip 0x40010b2 + mc_new_mem_stack_signal 1911 0xbeb6dfd0 0x6d8 + sigframe_create esp 0xbeb6dfd0 top esp 0xbeb6e6b0 size 0x6e0 pushed signal frame; %ESP now = 0xbeb6dfd0, next %EIP = 0x806a110, status=2 current_stack 0xBEB6DFD0-0xBEB6FFFF 0 new_SP 0xBEB6DF44 old_SP 0xBEB6DFC0 new current_stack not found The messages about "new current_stack not found" continue, presumably because the signal frame is not part of the recognised stack area for the main thread. While handing the signal, at some point, the other thread runs: ... current_stack 0xBEB6DFD0-0xBEB6FFFF 0 new_SP 0xBEB6DCA0 old_SP 0xBEB6DC64 new current_stack not found current_stack 0xBEB6DFD0-0xBEB6FFFF 0 new_SP 0x482C410 old_SP 0x482C410 new current_stack 0x4630000-0x482EFFF 1 current_stack 0x4630000-0x482EFFF 1 new_SP 0x482C3D0 old_SP 0x482C40C ... And some time after that, execution returns to the main thread, but it seems that the current_stack remains bound to the other thread and the "Invalid write" error follows: ... current_stack 0x4630000-0x482EFFF 1 new_SP 0x482C628 old_SP 0x482C63C current_stack 0x4630000-0x482EFFF 1 new_SP 0xBEB6DC80 old_SP 0xBEB6DC80 new current_stack not found current_stack 0x4630000-0x482EFFF 1 new_SP 0xBEB6DCA0 old_SP 0xBEB6DC84 new current_stack not found ... current_stack 0x4630000-0x482EFFF 1 new_SP 0xBEB6DFC0 old_SP 0xBEB6DF44 new current_stack not found + sigframe_destroy isRT 0 signo 17 esp 0xbeb6dfd0 size 0x6d8 redzone 0 + calling from track_die_mem_stack_signal 1845 0xbeb6dfd0 0x6d8 + set_address_range_perms 1738 1846 0xbeb6e680 len 40 smoff 7376 vabits16 0 current_stack 0x4630000-0x482EFFF 1 new_SP 0xBEB6E680 old_SP 0xBEB6E6AC ... ==25683== Invalid write of size 4 ==25683== at 0x806E19A: eventclockTime (timekeeping_.c:249) I suspect the key to the problem is that the current_stack no longer tracks the main thread after the other thread runs while signal delivery is still occurring in the main thread. Is this a plausible explanation? The signal frame itself seems to also cause "new current_stack not found" to be reported when handling. Should stack tracking know about signal frames? Earl |
|
From: <sv...@va...> - 2016-07-02 18:46:32
|
Author: philippe
Date: Sat Jul 2 19:46:23 2016
New Revision: 15898
Log:
Fix leak in m_redir.c
See below discussion for more details.
On Sat, 2016-07-02 at 14:20 +0200, Philippe Waroquiers wrote:
> I am testing a patch (provided by Julian) that solves a false positive
> memcheck found at my work.
>
> Testing this, I decided to run valgrind under valgrind (not done since
> a long time).
>
> This shows a leak in many tests, the stack trace being such as:
> ==26246== 336 bytes in 21 blocks are definitely lost in loss record 72 of 141
> ==26246== at 0x2801C01D: vgPlain_arena_malloc (m_mallocfree.c:1855)
> ==26246== by 0x2801D616: vgPlain_arena_strdup (m_mallocfree.c:2528)
> ==26246== by 0x2801D616: vgPlain_strdup (m_mallocfree.c:2600)
> ==26246== by 0x2801F5AD: vgPlain_redir_notify_new_DebugInfo (m_redir.c:619)
> ==26246== by 0x2803B650: di_notify_ACHIEVE_ACCEPT_STATE (debuginfo.c:771)
> ==26246== by 0x2803B650: vgPlain_di_notify_mmap (debuginfo.c:1067)
> ==26246== by 0x2806589C: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2368)
> ==26246== by 0x2809932A: vgSysWrap_amd64_linux_sys_mmap_before (syswrap-amd64-linux.c:637)
> ==26246== by 0x28061E11: vgPlain_client_syscall (syswrap-main.c:1906)
> ==26246== by 0x2805E9D2: handle_syscall (scheduler.c:1118)
> ==26246== by 0x280604A6: vgPlain_scheduler (scheduler.c:1435)
> ==26246== by 0x2806FF87: thread_wrapper (syswrap-linux.c:103)
> ==26246== by 0x2806FF87: run_a_thread_NORETURN (syswrap-linux.c:156)
>
>
> The strdup call in m_redir.c:619 was introduced by r15726.
>
> However, I am not sure this is a bug that is introduced by this change,
> or if it just reveals a leak that was already there.
> The "very original" replacement logic did not do memory allocation for
> the replacement: see m_redir.c in valgrind 3.10.1 : it was just copying
> some chars from VG_(clo_soname_synonyms) to demangled_sopatt
Yes, it should do exactly the same as the other code paths. If
replaced_sopatt != NULL then it is an allocated string that has been
assigned to demangled_sopatt. I had assumed that would take care of the
life-time issues of the allocated string. But now that I read the code
it is indeed not so clear.
> Then in 3.11, the fixed size demangled_sopatt was changed to be
> a dynamically allocated buffer.
> The revision log 14664 that introduced this explains that the ownership of
> returned buffer is not easy. It tells at the end:
> "So the rule of thunb here is: if in doubt strdup the string."
>
> but now we have to see when to free what, it seems ???
>
> Any thoughts ?
So if replaced_sopatt != NULL, then demangled_sopatt contains the
allocated string, and it is then immediately copied and assigned to
spec->from_sopatt. After that it is used under check_ppcTOCs. But there
it will first be reassigned a new value through maybe_Z_demangle
(overwriting any existing string being pointed to). So for this
particular leak it seem fine to free it right after the spec[List] has
been initialized (line 642).
Cheers,
Mark
Modified:
trunk/coregrind/m_redir.c
Modified: trunk/coregrind/m_redir.c
==============================================================================
--- trunk/coregrind/m_redir.c (original)
+++ trunk/coregrind/m_redir.c Sat Jul 2 19:46:23 2016
@@ -616,7 +616,7 @@
if (replaced_sopatt == NULL
&& VG_(strcmp) ( demangled_sopatt, SO_SYN_MALLOC_NAME ) == 0)
{
- replaced_sopatt = VG_(strdup)("m_redir.rnnD.1", "*");
+ replaced_sopatt = dinfo_strdup("m_redir.rnnD.1", "*");
demangled_sopatt = replaced_sopatt;
isGlobal = True;
}
@@ -640,6 +640,14 @@
spec->mark = False; /* not significant */
spec->done = False; /* not significant */
specList = spec;
+ /* The demangler is the owner of the demangled_sopatt memory,
+ unless it was replaced. In this case, we have to free the
+ replace_sopatt(==demangled_sopatt). We can free it,
+ because it was dinfo_strup-ed into spec->from_sopatt. */
+ if (replaced_sopatt != NULL) {
+ vg_assert(demangled_sopatt == replaced_sopatt);
+ dinfo_free(replaced_sopatt);
+ }
}
free_symname_array(names_init, &twoslots[0]);
}
|