File: solaris11.supp

package info (click to toggle)
valgrind 1%3A3.24.0-3
  • links: PTS, VCS
  • area: main
  • in suites: trixie
  • size: 176,332 kB
  • sloc: ansic: 795,029; exp: 26,134; xml: 23,472; asm: 14,393; cpp: 9,397; makefile: 7,464; sh: 6,122; perl: 5,446; python: 1,498; javascript: 981; awk: 166; csh: 1
file content (52 lines) | stat: -rw-r--r-- 1,101 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
# This is a real problem in the Solaris libc. It is caused by a read past the
# FILE structure. It's an intentional hack to differentiate between two file
# structures, FILE and xFILE.
{
   Solaris:snprintf
   Memcheck:Cond
   fun:getxfdat
   ...
   fun:_ndoprnt
   fun:snprintf
}

# The same problem as above.
{
   Solaris:vsnprintf
   Memcheck:Cond
   fun:getxfdat
   ...
   fun:_ndoprnt
   fun:vsnprintf
}

# Solaris libc doesn't deallocate I/O buffers on program exit.
{
   Solaris:file_buffer_malloc
   Memcheck:Leak
   fun:malloc
   fun:_findbuf
   obj:/lib/libc.so.1
   obj:/lib/libc.so.1
}

#----------------------------------------------------------------------------#
# Solaris libc reinitializes mutex udp->ld_lock in the child's post-fork
# handler.
{  
   Solaris:postfork_child_mutex_reinit
   drd:MutexErr
   fun:mutex_init
   fun:postfork1_child
   fun:forkx
}

{
   Solaris:std::lock_guard<std::mutex>::lock_guard
   Helgrind:Race
   fun:_ZL18__gthread_active_pv
   fun:_ZL20__gthread_mutex_lockP14_pthread_mutex
   fun:_ZNSt5mutex4lockEv
   fun:_ZNSt10lock_guardISt5mutexEC1ERS0_
}