|
From: Alexander P. <gl...@go...> - 2010-08-18 14:48:14
|
A friendly ping
On Tue, Aug 10, 2010 at 12:13 PM, Alexander Potapenko <gl...@go...> wrote:
> Julian, Nicholas,
>
> aren't these suppressions missing in the trunk after the merge?
>
> On Mon, Jun 7, 2010 at 3:32 PM, <sv...@va...> wrote:
>> Author: sewardj
>> Date: 2010-06-07 12:32:31 +0100 (Mon, 07 Jun 2010)
>> New Revision: 11154
>>
>> Log:
>> Initial suppression files for MacOSX 10.6.
>>
>>
>> Added:
>> branches/MACOSX106/darwin10-drd.supp
>> branches/MACOSX106/darwin10.supp
>>
>>
>> Added: branches/MACOSX106/darwin10-drd.supp
>> ===================================================================
>>
>> Added: branches/MACOSX106/darwin10.supp
>> ===================================================================
>> --- branches/MACOSX106/darwin10.supp (rev 0)
>> +++ branches/MACOSX106/darwin10.supp 2010-06-07 11:32:31 UTC (rev 11154)
>> @@ -0,0 +1,273 @@
>> +
>> +# Suppressions for Darwin 10.x / Mac OS X 10.6 Snow Leopard
>> +
>> +##----------------------------------------------------------------------##
>> +# Memcheck
>> +##----------------------------------------------------------------------##
>> +
>> +{
>> + mach_msg_trap-1
>> + Memcheck:Param
>> + mach_msg(msg.msgh_remote_port)
>> + fun:mach_msg_trap
>> + obj:/System/Library/Frameworks/CoreFoundation*
>> + obj:/System/Library/Frameworks/ApplicationServices*
>> +}
>> +
>> +{
>> + mach_msg_trap-2
>> + Memcheck:Param
>> + mach_msg(msg.msgh_remote_port)
>> + fun:mach_msg_trap
>> + obj:/System/Library/Frameworks/CoreFoundation*
>> + obj:/System/Library/Frameworks/CoreServices*
>> +}
>> +
>> +{
>> + mach_msg_trap-3
>> + Memcheck:Param
>> + mach_msg(msg.msgh_remote_port)
>> + fun:mach_msg_trap
>> + obj:/System/Library/Frameworks/CoreFoundation*
>> + obj:/System/Library/Frameworks/Carbon*
>> +}
>> +
>> +{
>> + mach_msg_trap-4
>> + Memcheck:Param
>> + mach_msg(msg.msgh_remote_port)
>> + fun:mach_msg_trap
>> + obj:/System/Library/Frameworks/CoreFoundation*
>> + obj:/System/Library/Frameworks/CoreFoundation*
>> +}
>> +
>> +{
>> + mach_msg_trap-5
>> + Memcheck:Param
>> + mach_msg(msg.msgh_remote_port)
>> + fun:mach_msg_trap
>> + obj:/System/Library/Frameworks/CoreFoundation*
>> + obj:/System/Library/Frameworks/AppKit*
>> +}
>> +
>> +{
>> + macos-Cond-1
>> + Memcheck:Cond
>> + fun:GetVariationInfoFromName
>> + obj:/System/Library/Frameworks/ApplicationServices*
>> + obj:/System/Library/Frameworks/ApplicationServices*
>> +}
>> +
>> +{
>> + macos-Cond-2
>> + Memcheck:Cond
>> + fun:*PMMutex*Lock*
>> + obj:/System/Library/Frameworks/ApplicationServices*
>> + obj:/System/Library/Frameworks/ApplicationServices*
>> +}
>> +
>> +{
>> + macos-Cond-3
>> + Memcheck:Cond
>> + fun:sseCGSBlendXXXX8888
>> + obj:/System/Library/Frameworks/ApplicationServices*
>> + obj:/System/Library/Frameworks/ApplicationServices*
>> +}
>> +
>> +{
>> + macos-Cond-4
>> + Memcheck:Cond
>> + fun:*CASettingsStorage*RefreshSettings*
>> + obj:/System/Library/Frameworks/CoreAudio*
>> + obj:/System/Library/Frameworks/CoreAudio*
>> +}
>> +
>> +{
>> + macos-Cond-5
>> + Memcheck:Cond
>> + fun:gle*
>> + obj:/System/Library/Frameworks/OpenGL*
>> + obj:/System/Library/Frameworks/OpenGL*
>> +}
>> +
>> +{
>> + macos-Cond-6
>> + Memcheck:Cond
>> + fun:pthread_rwlock_init$UNIX2003
>> + fun:main
>> +}
>> +
>> +# afaict this is legit. Might be caused by setenv("VAR=")
>> +# where the value string is empty (not sure)
>> +{
>> + macos-Cond-7
>> + Memcheck:Cond
>> + fun:__setenv
>> + fun:putenv*
>> +}
>> +
>> +{
>> + macos-futimes-1
>> + Memcheck:Param
>> + futimes(tvp[1])
>> + fun:futimes
>> + obj:/usr/lib/libSystem*
>> + obj:/usr/lib/libSystem*
>> +}
>> +
>> +{
>> + macos-vsyslog-hole
>> + Memcheck:Param
>> + socketcall.sendto(msg)
>> + fun:sendto$NOCANCEL$UNIX2003
>> + fun:vsyslog
>> +}
>> +
>> +# Still-reachable memory.
>> +
>> +# I chopped this one off at libSystem_initializer, there were more frames.
>> +{
>> + darwin-still-reachable-1
>> + Memcheck:Leak
>> + fun:calloc
>> + fun:dwarf2_unwind_dyld_add_image_hook
>> + fun:_ZN4dyld19registerAddCallbackEPFvPK11mach_headerlE
>> + fun:_dyld_register_func_for_add_image
>> + fun:__keymgr_initializer
>> + fun:libSystem_initializer
>> +}
>> +
>> +# I chopped this one off at libSystem_initializer, there were more frames.
>> +{
>> + darwin-still-reachable-2
>> + Memcheck:Leak
>> + fun:malloc
>> + fun:get_or_create_key_element
>> + fun:_keymgr_get_and_lock_processwide_ptr_2
>> + fun:dwarf2_unwind_dyld_add_image_hook
>> + fun:_ZN4dyld19registerAddCallbackEPFvPK11mach_headerlE
>> + fun:_dyld_register_func_for_add_image
>> + fun:__keymgr_initializer
>> + fun:libSystem_initializer
>> +}
>> +
>> +{
>> + darwin-still-reachable-3
>> + Memcheck:Leak
>> + fun:malloc
>> + fun:__smakebuf
>> + fun:__swsetup
>> + fun:__sfvwrite
>> + fun:puts
>> +}
>> +
>> +# Genuine leaks.
>> +# See https://bugs.kde.org/show_bug.cgi?id=188572 about this; it's
>> +# unavoidable due to BSD setenv() semantics.
>> +{
>> + macos-__setenv-leak-see-our-bug-188572
>> + Memcheck:Leak
>> + fun:malloc_zone_malloc
>> + fun:__setenv
>> + fun:setenv$UNIX2003
>> +}
>> +{
>> + macos-localeconv-leak
>> + Memcheck:Leak
>> + fun:malloc
>> + fun:localeconv_l
>> + fun:__vfprintf
>> + fun:vsnprintf
>> +}
>> +
>> +##----------------------------------------------------------------------##
>> +# Helgrind
>> +##----------------------------------------------------------------------##
>> +
>> +# These ones were necessary to give no errors on a tiny non-threaded
>> +# program. I don't know if they're real problems or false positives (njn).
>> +
>> +# keymgr seems to deliberately do some bogus actions, and if they are bogus,
>> +# it passes the error codes back to the caller.
>> +{
>> + __keymgr_initializer lock failed
>> + Helgrind:PthAPIerror
>> + fun:pthread_mutex_lock
>> + fun:_dyld_register_func_for_*_image
>> + fun:__keymgr_initializer
>> + fun:libSystem_initializer
>> +}
>> +{
>> + __keymgr_initializer unlock failed
>> + Helgrind:PthAPIerror
>> + fun:pthread_mutex_unlock
>> + fun:_dyld_register_func_for_*_image
>> + fun:__keymgr_initializer
>> + fun:libSystem_initializer
>> +}
>> +{
>> + __keymgr_initializer bogus unlock
>> + Helgrind:UnlockBogus
>> + fun:pthread_mutex_unlock
>> + fun:_dyld_register_func_for_*_image
>> + fun:__keymgr_initializer
>> + fun:libSystem_initializer
>> +}
>> +
>> +# These ones were necessary to give no errors on a tiny threaded program.
>> +# I don't know if they're real problems or false positives (njn).
>> +
>> +#{
>> +# helgrind-darwinlibc-nuke-everything-in-dyld
>> +# Helgrind:Race
>> +# obj:/usr/lib/dyld
>> +#}
>> +
>> +{
>> + helgrind-darwinlibc-nuke-everything-in-libSystem.B.dylib
>> + Helgrind:Race
>> + obj:/usr/lib/libSystem.B.dylib
>> +}
>> +
>> +# This would be better as "fun:\?\?\?" but string matching doesn't seem to
>> +# allow escaping meta-chars.
>> +#
>> +# This is very bad .. not only will it hide races in any
>> +# un-identified piece of code, the ??? also matches any 3-char
>> +# function name.
>> +{
>> + helgrind-darwinlibc-nuke-everything-in-???-(unknown-code)
>> + Helgrind:Race
>> + fun:???
>> +}
>> +
>> +{
>> + helgrind-darwinlibc--mythread_wrapper-*thread*start*
>> + Helgrind:Race
>> + fun:mythread_wrapper
>> + fun:*thread*start*
>> +}
>> +
>> +{
>> + helgrind-darwinlibc--pthread_create_WRK-pthread_create
>> + Helgrind:Race
>> + fun:pthread_create_WRK
>> + fun:pthread_create
>> +}
>> +
>> +
>> +# Thread #9: Bug in libpthread: recursive write lock granted on
>> +# mutex/wrlock which does not support recursion
>> +# at 0x18696: pthread_cond_wait* (hg_intercepts.c:655)
>> +# by 0x2300B8: pthread_rwlock_wrlock$UNIX2003 (in /usr/lib/libSystem.B.dylib)
>> +# by 0x18F41: pthread_rwlock_wrlock* (hg_intercepts.c:1177)
>> +#
>> +# no idea what this is about
>> +#
>> +{
>> + helgrind-darwin9--pthread-rwlock-kludgery
>> + Helgrind:Misc
>> + fun:pthread_cond_wait*
>> + fun:pthread_rwlock_*lock*
>> + fun:pthread_rwlock_*lock*
>> +}
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit. See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Valgrind-developers mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>
>
>
>
> --
> Alexander Potapenko
> Software Engineer
> Google Moscow
>
--
Alexander Potapenko
Software Engineer
Google Moscow
|