valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] fuse filesystem syscall deadlocks

[Philippe W. <phi...@sk...>]

On Thu, 2015-04-09 at 14:08 -0400, Atalay Ozgovde wrote:
> This is essentially the same bug
> as:https://bugs.kde.org/show_bug.cgi?id=278057
> 
> A patch was applied for this bug in version 3.7 and it is considered
> fixed. 
> I am using version 3.10, I confirmed in the source code that the patch
> is applied. Valgrind still dread-locks when used to test an
> application that uses fuse in our environment. We are using 64bit
> Ubuntu 12.04LTS. 
> 
> Anybody knows if there is an easy fix?
As far as I can see, the 'potentially deadlocking syscall with fuse'
have to be marked specially in Valgrind code.
If compared to the patch in 3.7, you now have additional syscalls
that have to be marked, then that might explain the problem.

Maybe you could discover such syscalls by using
  --trace-syscalls=yes
valgrind option
and/or using strace -f valgrind ....

and see which syscalls are 'on-going' when the whole stuff deadlocks.

Philippe

Re: [Valgrind-users] valgrind out of memory error

[Maurice v. S. <ma...@bl...>]

I remember having a similar issue where a program was using mmap to allocate (to much) memory rather than malloc (or new). 

Valgrind doesn't track the use of mmap, correct me if I'm wrong, so might run out of memory while reporting just the usage through malloc. 

][ Maurice van Swaaij, Blue Sky Studios ][ 

----- Original Message -----

| From: "Yanwen Zhu" <Yan...@vi...>
| To: "Philippe Waroquiers" <phi...@sk...>
| Cc: val...@li...
| Sent: Friday, April 10, 2015 4:27:39 PM
| Subject: Re: [Valgrind-users] valgrind out of memory error

| Also, I just looked at online:
| https://www.mail-archive.com/val...@li.../msg02027.html

| Is it a permission problem?

| Yanwen

| -----Original Message-----
| From: Zhu, Yanwen
| Sent: Friday, April 10, 2015 4:27 PM
| To: 'Philippe Waroquiers'
| Cc: val...@li...
| Subject: RE: [Valgrind-users] valgrind out of memory error

| Philippe,

| Thanks for your prompt reply, see below for the output when running
| with -v -v -v -d -d -d and --sanity-level=4

| # valgrind -v -v -v -d -d -d
| --1955:1:debuglog DebugLog system started by Stage 1, level 3 logging
| requested --1955:1:launcher no tool requested, defaulting to
| 'memcheck'
| --1955:1:launcher no client specified, defaulting platform to
| 'mips64-linux'
| --1955:1:launcher launching /usr/lib/valgrind/memcheck-mips64-linux
| --1955:1:debuglog DebugLog system started by Stage 2 (main), level 3
| logging requested
| --1955:1:main Welcome to Valgrind version 3.10.1 debug logging
| --1955:1:main Checking current stack is plausible
| --1955:1:main Checking initial stack was noted
| --1955:1:main Starting the address space manager
| --1955:2:aspacem sp_at_startup = 0x007f8a7ca0 (supplied)
| --1955:2:aspacem minAddr = 0x0004000000 (computed)
| --1955:2:aspacem maxAddr = 0x00ffffffff (computed)
| --1955:2:aspacem cStart = 0x0004000000 (computed)
| --1955:2:aspacem vStart = 0x0082000000 (computed)
| --1955:2:aspacem suggested_clstack_end = 0x00ff000fff (computed)
| --1955:2:aspacem <<< SHOW_SEGMENTS: Initial layout (4 segments, 0
| segnames)
| --1955:2:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed
| --1955:2:aspacem 1: 0004000000-0081ffffff 2016m
| --1955:2:aspacem 2: RSVN 0082000000-0082000fff 4096 ----- SmFixed
| --1955:2:aspacem 3: 0082001000-00ffffffff 2015m
| --1955:2:aspacem >>>
| --1955:2:aspacem Reading /proc/self/maps
| --1955:2:aspacem <<< SHOW_SEGMENTS: With contents of /proc/self/maps
| (13 segments, 1 segnames)
| --1955:2:aspacem ( 0) /usr/lib/valgrind/memcheck-mips64-linux
| --1955:2:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed
| --1955:2:aspacem 1: 0004000000-000fffffff 192m
| --1955:2:aspacem 2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100
| i=2074 o=0 (0)
| --1955:2:aspacem 3: 00103df000-00103dffff 4096
| --1955:2:aspacem 4: FILE 00103e0000-00103ebfff 49152 rw--- d=0x100
| i=2074 o=4063232 (0)
| --1955:2:aspacem 5: ANON 00103ec000-0011947fff 21m rwx--
| --1955:2:aspacem 6: 0011948000-007f886fff 1759m
| --1955:2:aspacem 7: ANON 007f887000-007f8a7fff 135168 rwx--
| --1955:2:aspacem 8: 007f8a8000-007fff6fff 7663616
| --1955:2:aspacem 9: ANON 007fff7000-007fff7fff 4096 r-x--
| --1955:2:aspacem 10: 007fff8000-0081ffffff 32m
| --1955:2:aspacem 11: RSVN 0082000000-0082000fff 4096 ----- SmFixed
| --1955:2:aspacem 12: 0082001000-00ffffffff 2015m
| --1955:2:aspacem >>>
| --1955:1:main Address space manager is running
| --1955:1:main Starting the dynamic memory manager
| --1955:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1
| segnames) --1955:0:aspacem ( 0)
| /usr/lib/valgrind/memcheck-mips64-linux
| --1955:0:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed
| --1955:0:aspacem 1: 0004000000-000fffffff 192m
| --1955:0:aspacem 2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100
| i=2074 o=0 (0)
| --1955:0:aspacem 3: 00103df000-00103dffff 4096
| --1955:0:aspacem 4: FILE 00103e0000-00103ebfff 49152 rw--- d=0x100
| i=2074 o=4063232 (0)
| --1955:0:aspacem 5: ANON 00103ec000-0011947fff 21m rwx--
| --1955:0:aspacem 6: 0011948000-007f886fff 1759m
| --1955:0:aspacem 7: ANON 007f887000-007f8a7fff 135168 rwx--
| --1955:0:aspacem 8: 007f8a8000-007fff6fff 7663616
| --1955:0:aspacem 9: ANON 007fff7000-007fff7fff 4096 r-x--
| --1955:0:aspacem 10: 007fff8000-0081ffffff 32m
| --1955:0:aspacem 11: RSVN 0082000000-0082000fff 4096 ----- SmFixed
| --1955:0:aspacem 12: 0082001000-00ffffffff 2015m
| --1955:0:aspacem >>>
| --1955-- core : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,
| 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 12 rzB
| --1955-- dinfo : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,
| 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 12 rzB
| --1955-- (null) : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb
| unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 0
| rzB
| --1955-- demangle: 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb
| unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 12
| rzB
| --1955-- ttaux : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,
| 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 12 rzB
| --1955-- translate: fast SP updates identified: 0 ( --%)
| --1955-- translate: generic_known SP updates identified: 0 ( --%)
| --1955-- translate: generic_unknown SP updates identified: 0 ( --%)
| --1955-- tt/tc: 0 tt lookups requiring 0 probes
| --1955-- tt/tc: 0 fast-cache updates, 0 flushes
| --1955-- transtab: new 0 (0 -> 0; ratio 0:10) [0 scs]
| --1955-- transtab: dumped 0 (0 -> ??)
| --1955-- transtab: discarded 0 (0 -> ??)
| --1955-- scheduler: 0 event checks.
| --1955-- scheduler: 0 indir transfers, 0 misses (1 in 0)
| --1955-- scheduler: 0/0 major/minor sched events.
| --1955-- sanity: 0 cheap, 0 expensive checks.
| ==1955==
| ==1955== Valgrind's memory management: out of memory:
| ==1955== newSuperblock's request for 4194304 bytes failed.
| ==1955== 22536192 bytes have already been allocated.
| ==1955== Valgrind cannot continue. Sorry.
| ==1955==
| ==1955== There are several possible reasons for this.
| ==1955== - You have some kind of memory limit in place. Look at the
| ==1955== output of 'ulimit -a'. Is there a limit on the size of
| ==1955== virtual memory or address space?
| ==1955== - You have run out of swap space.
| ==1955== - Valgrind has a bug. If you think this is the case or you
| are
| ==1955== not sure, please let us know and we'll try to fix it.
| ==1955== Please note that programs can take substantially more memory
| than
| ==1955== normal when running under Valgrind tools, eg. up to twice or
| ==1955== more, depending on the tool. On a 64-bit machine, Valgrind
| ==1955== should be able to make use of up 32GB memory. On a 32-bit
| ==1955== machine, Valgrind should be able to use all the memory
| available
| ==1955== to a single process, up to 4GB if that's how you have your
| ==1955== kernel configured. Most 32-bit Linux setups allow a maximum
| of
| ==1955== 3GB per process.
| ==1955==
| ==1955== Whatever the reason, Valgrind cannot continue. Sorry.
| #
| #
| #
| #
| #
| # valgrind --sanity-level=4
| --1956:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1
| segnames) --1956:0:aspacem ( 0)
| /usr/lib/valgrind/memcheck-mips64-linux
| --1956:0:aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed
| --1956:0:aspacem 1: 0004000000-000fffffff 192m
| --1956:0:aspacem 2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100
| i=2074 o=0 (0)
| --1956:0:aspacem 3: 00103df000-00103dffff 4096
| --1956:0:aspacem 4: FILE 00103e0000-00103ebfff 49152 rw--- d=0x100
| i=2074 o=4063232 (0)
| --1956:0:aspacem 5: ANON 00103ec000-0011947fff 21m rwx--
| --1956:0:aspacem 6: 0011948000-007f880fff 1759m
| --1956:0:aspacem 7: ANON 007f881000-007f8a1fff 135168 rwx--
| --1956:0:aspacem 8: 007f8a2000-007fff6fff 7688192
| --1956:0:aspacem 9: ANON 007fff7000-007fff7fff 4096 r-x--
| --1956:0:aspacem 10: 007fff8000-0081ffffff 32m
| --1956:0:aspacem 11: RSVN 0082000000-0082000fff 4096 ----- SmFixed
| --1956:0:aspacem 12: 0082001000-00ffffffff 2015m
| --1956:0:aspacem >>>
| --1956-- core : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,
| 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 12 rzB
| --1956-- dinfo : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,
| 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 12 rzB
| --1956-- (null) : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb
| unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 0
| rzB
| --1956-- demangle: 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb
| unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 12
| rzB
| --1956-- ttaux : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,
| 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 12 rzB
| --1956-- translate: fast SP updates identified: 0 ( --%)
| --1956-- translate: generic_known SP updates identified: 0 ( --%)
| --1956-- translate: generic_unknown SP updates identified: 0 ( --%)
| --1956-- tt/tc: 0 tt lookups requiring 0 probes
| --1956-- tt/tc: 0 fast-cache updates, 0 flushes
| --1956-- transtab: new 0 (0 -> 0; ratio 0:10) [0 scs]
| --1956-- transtab: dumped 0 (0 -> ??)
| --1956-- transtab: discarded 0 (0 -> ??)
| --1956-- scheduler: 0 event checks.
| --1956-- scheduler: 0 indir transfers, 0 misses (1 in 0)
| --1956-- scheduler: 0/0 major/minor sched events.
| --1956-- sanity: 0 cheap, 0 expensive checks.
| ==1956==
| ==1956== Valgrind's memory management: out of memory:
| ==1956== newSuperblock's request for 4194304 bytes failed.
| ==1956== 22536192 bytes have already been allocated.
| ==1956== Valgrind cannot continue. Sorry.
| ==1956==
| ==1956== There are several possible reasons for this.
| ==1956== - You have some kind of memory limit in place. Look at the
| ==1956== output of 'ulimit -a'. Is there a limit on the size of
| ==1956== virtual memory or address space?
| ==1956== - You have run out of swap space.
| ==1956== - Valgrind has a bug. If you think this is the case or you
| are
| ==1956== not sure, please let us know and we'll try to fix it.
| ==1956== Please note that programs can take substantially more memory
| than
| ==1956== normal when running under Valgrind tools, eg. up to twice or
| ==1956== more, depending on the tool. On a 64-bit machine, Valgrind
| ==1956== should be able to make use of up 32GB memory. On a 32-bit
| ==1956== machine, Valgrind should be able to use all the memory
| available
| ==1956== to a single process, up to 4GB if that's how you have your
| ==1956== kernel configured. Most 32-bit Linux setups allow a maximum
| of
| ==1956== 3GB per process.
| ==1956==
| ==1956== Whatever the reason, Valgrind cannot continue. Sorry.

| -----Original Message-----
| From: Philippe Waroquiers [mailto:phi...@sk...]
| Sent: Friday, April 10, 2015 4:23 PM
| To: Zhu, Yanwen
| Cc: val...@li...
| Subject: Re: [Valgrind-users] valgrind out of memory error

| On Fri, 2015-04-10 at 20:04 +0000, Zhu, Yanwen wrote:
| > Has anyone seen this error when running valgrind 3.10.1 in a MIPS64
| > platform?
| >
| >
| >
| > ==1769== Valgrind's memory management: out of memory:
| >
| > ==1769== newSuperblock's request for 4194304 bytes failed.
| >
| > ==1769== 22536192 bytes have already been allocated.
| >
| > ==1769== Valgrind cannot continue. Sorry.
| Not seen such a thing (but not having access to a mips platform, it
| is not easy to see what is going on).

| What looks really strange is the very low level value of the already
| allocated bytes.

| So, maybe the aspacemgr view of the memory mapping is not in sync
| with the kernel view.

| Normally, such an OOM produces the state of the memory and the
| aspacemgr state.
| More trace would also be useful.

| So, can you run with
| -v -v -v -d -d -d
| and send the full log (if not too big).

| Also, might be useful to run with
| --sanity-level=4
| as this will report aspacemgr<>kernel desync.

| Philippe

| ------------------------------------------------------------------------------
| BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
| Develop your own process in accordance with the BPMN 2 standard
| Learn Process modeling best practices with Bonita BPM through live
| exercises
| http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
| event?utm_
| source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
| _______________________________________________
| Valgrind-users mailing list
| Val...@li...
| https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] valgrind out of memory error

[Philippe W. <phi...@sk...>]

On Fri, 2015-04-10 at 20:48 +0000, Zhu, Yanwen wrote:

> From: Maurice van Swaaij [mailto:ma...@bl...] 
> Sent: Friday, April 10, 2015 4:45 PM
> To: Zhu, Yanwen
> Cc: val...@li...; Philippe Waroquiers
> Subject: Re: [Valgrind-users] valgrind out of memory error
> 
> 
>  
> 
> I remember having a similar issue where a program was using mmap to
> allocate (to much) memory rather than malloc (or new).
> 
> Valgrind doesn't track the use of mmap, correct me if I'm wrong, so
> might run out of memory while reporting just the usage through malloc.
Valgrind tracks the use of mmap. If it would not do it, nothing
would work.
But for sure, the memory mmap-ed by the client is not counted
in e.g. the memcheck heap reports.

Philippe

Re: [Valgrind-users] valgrind out of memory error

[Philippe W. <phi...@sk...>]

On Fri, 2015-04-10 at 20:27 +0000, Zhu, Yanwen wrote:
> Also, I just looked at online:
> https://www.mail-archive.com/val...@li.../msg02027.html
> 
> Is it a permission problem?
It does not look like.
But in any case, it looks like you are running Valgrind as root.
This is very unusual, and should not be needed.

Apart of that, the trace you gave shows that initialisation of
the Valgrind malloc lib fails.
A succesful startup of the Valgrind malloc lib would give:
--13999:1:    main Starting the dynamic memory manager
--13999:1:mallocfr newSuperblock at 0x61C35000 (pszB 4194288)  owner VALGRIND/core

So, can you redo the -v -v -v -d -d -d experiment, but using strace to
trace it i.e.
   strace -f valgrind -v -v -v -d -d -d

A succesful startup results in a trace such as:
[pid 13912] write(2, "--13912:1:    main Starting the "..., 55--13912:1:    main Starting the dynamic memory manager
) = 55
[pid 13912] mmap2(0x61e41000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = 0x61e41000
[pid 13912] getpid()                    = 13912
[pid 13912] write(2, "--13912:1:mallocfr newSuperblock"..., 83--13912:1:mallocfr newSuperblock at 0x61E41000 (pszB 4194288)  owner VALGRIND/core
) = 83

which shows the mmap syscall, and the resulting superblock trace.

So, can you redo the trial with strace, and give the equivalent traces ?
Probably the mmap fails. We can then see which address has been chosen
by aspacemgr, the resulting errno, and all that could explain the
failure

Philippe

Re: [Valgrind-users] valgrind out of memory error

[Zhu, Y. <Yan...@vi...>]

Also, I just looked at online:
https://www.mail-archive.com/val...@li.../msg02027.html

Is it a permission problem?

Yanwen

-----Original Message-----
From: Zhu, Yanwen 
Sent: Friday, April 10, 2015 4:27 PM
To: 'Philippe Waroquiers'
Cc: val...@li...
Subject: RE: [Valgrind-users] valgrind out of memory error

Philippe,

Thanks for your prompt reply, see below for the output when running with -v -v -v -d -d -d and --sanity-level=4


# valgrind -v -v -v -d -d -d
--1955:1:debuglog DebugLog system started by Stage 1, level 3 logging requested --1955:1:launcher no tool requested, defaulting to 'memcheck'
--1955:1:launcher no client specified, defaulting platform to 'mips64-linux'
--1955:1:launcher launching /usr/lib/valgrind/memcheck-mips64-linux
--1955:1:debuglog DebugLog system started by Stage 2 (main), level 3 logging requested
--1955:1:main     Welcome to Valgrind version 3.10.1 debug logging
--1955:1:main     Checking current stack is plausible
--1955:1:main     Checking initial stack was noted
--1955:1:main     Starting the address space manager
--1955:2:aspacem            sp_at_startup = 0x007f8a7ca0 (supplied)
--1955:2:aspacem                  minAddr = 0x0004000000 (computed)
--1955:2:aspacem                  maxAddr = 0x00ffffffff (computed)
--1955:2:aspacem                   cStart = 0x0004000000 (computed)
--1955:2:aspacem                   vStart = 0x0082000000 (computed)
--1955:2:aspacem    suggested_clstack_end = 0x00ff000fff (computed)
--1955:2:aspacem    <<< SHOW_SEGMENTS: Initial layout (4 segments, 0 segnames)
--1955:2:aspacem      0: RSVN 0000000000-0003ffffff     64m ----- SmFixed
--1955:2:aspacem      1:      0004000000-0081ffffff   2016m
--1955:2:aspacem      2: RSVN 0082000000-0082000fff    4096 ----- SmFixed
--1955:2:aspacem      3:      0082001000-00ffffffff   2015m
--1955:2:aspacem    >>>
--1955:2:aspacem    Reading /proc/self/maps
--1955:2:aspacem    <<< SHOW_SEGMENTS: With contents of /proc/self/maps (13 segments, 1 segnames)
--1955:2:aspacem    ( 0) /usr/lib/valgrind/memcheck-mips64-linux
--1955:2:aspacem      0: RSVN 0000000000-0003ffffff     64m ----- SmFixed
--1955:2:aspacem      1:      0004000000-000fffffff    192m
--1955:2:aspacem      2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 i=2074    o=0       (0)
--1955:2:aspacem      3:      00103df000-00103dffff    4096
--1955:2:aspacem      4: FILE 00103e0000-00103ebfff   49152 rw--- d=0x100 i=2074    o=4063232 (0)
--1955:2:aspacem      5: ANON 00103ec000-0011947fff     21m rwx--
--1955:2:aspacem      6:      0011948000-007f886fff   1759m
--1955:2:aspacem      7: ANON 007f887000-007f8a7fff  135168 rwx--
--1955:2:aspacem      8:      007f8a8000-007fff6fff 7663616
--1955:2:aspacem      9: ANON 007fff7000-007fff7fff    4096 r-x--
--1955:2:aspacem     10:      007fff8000-0081ffffff     32m
--1955:2:aspacem     11: RSVN 0082000000-0082000fff    4096 ----- SmFixed
--1955:2:aspacem     12:      0082001000-00ffffffff   2015m
--1955:2:aspacem    >>>
--1955:1:main     Address space manager is running
--1955:1:main     Starting the dynamic memory manager
--1955:0:aspacem  <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1 segnames) --1955:0:aspacem  ( 0) /usr/lib/valgrind/memcheck-mips64-linux
--1955:0:aspacem    0: RSVN 0000000000-0003ffffff     64m ----- SmFixed
--1955:0:aspacem    1:      0004000000-000fffffff    192m
--1955:0:aspacem    2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 i=2074    o=0       (0)
--1955:0:aspacem    3:      00103df000-00103dffff    4096
--1955:0:aspacem    4: FILE 00103e0000-00103ebfff   49152 rw--- d=0x100 i=2074    o=4063232 (0)
--1955:0:aspacem    5: ANON 00103ec000-0011947fff     21m rwx--
--1955:0:aspacem    6:      0011948000-007f886fff   1759m
--1955:0:aspacem    7: ANON 007f887000-007f8a7fff  135168 rwx--
--1955:0:aspacem    8:      007f8a8000-007fff6fff 7663616
--1955:0:aspacem    9: ANON 007fff7000-007fff7fff    4096 r-x--
--1955:0:aspacem   10:      007fff8000-0081ffffff     32m
--1955:0:aspacem   11: RSVN 0082000000-0082000fff    4096 ----- SmFixed
--1955:0:aspacem   12:      0082001000-00ffffffff   2015m
--1955:0:aspacem  >>>
--1955-- core    :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1955-- dinfo   :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1955-- (null)  :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 0 rzB
--1955-- demangle:        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1955-- ttaux   :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1955-- translate:            fast SP updates identified: 0 (   --%)
--1955-- translate:   generic_known SP updates identified: 0 (   --%)
--1955-- translate: generic_unknown SP updates identified: 0 (   --%)
--1955--     tt/tc: 0 tt lookups requiring 0 probes
--1955--     tt/tc: 0 fast-cache updates, 0 flushes
--1955--  transtab: new        0 (0 -> 0; ratio 0:10) [0 scs]
--1955--  transtab: dumped     0 (0 -> ??)
--1955--  transtab: discarded  0 (0 -> ??)
--1955-- scheduler: 0 event checks.
--1955-- scheduler: 0 indir transfers, 0 misses (1 in 0)
--1955-- scheduler: 0/0 major/minor sched events.
--1955--    sanity: 0 cheap, 0 expensive checks.
==1955==
==1955==     Valgrind's memory management: out of memory:
==1955==        newSuperblock's request for 4194304 bytes failed.
==1955==        22536192 bytes have already been allocated.
==1955==     Valgrind cannot continue.  Sorry.
==1955==
==1955==     There are several possible reasons for this.
==1955==     - You have some kind of memory limit in place.  Look at the
==1955==       output of 'ulimit -a'.  Is there a limit on the size of
==1955==       virtual memory or address space?
==1955==     - You have run out of swap space.
==1955==     - Valgrind has a bug.  If you think this is the case or you are
==1955==     not sure, please let us know and we'll try to fix it.
==1955==     Please note that programs can take substantially more memory than
==1955==     normal when running under Valgrind tools, eg. up to twice or
==1955==     more, depending on the tool.  On a 64-bit machine, Valgrind
==1955==     should be able to make use of up 32GB memory.  On a 32-bit
==1955==     machine, Valgrind should be able to use all the memory available
==1955==     to a single process, up to 4GB if that's how you have your
==1955==     kernel configured.  Most 32-bit Linux setups allow a maximum of
==1955==     3GB per process.
==1955==
==1955==     Whatever the reason, Valgrind cannot continue.  Sorry.
#
#
#
#
#
# valgrind --sanity-level=4
--1956:0:aspacem  <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1 segnames) --1956:0:aspacem  ( 0) /usr/lib/valgrind/memcheck-mips64-linux
--1956:0:aspacem    0: RSVN 0000000000-0003ffffff     64m ----- SmFixed
--1956:0:aspacem    1:      0004000000-000fffffff    192m
--1956:0:aspacem    2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 i=2074    o=0       (0)
--1956:0:aspacem    3:      00103df000-00103dffff    4096
--1956:0:aspacem    4: FILE 00103e0000-00103ebfff   49152 rw--- d=0x100 i=2074    o=4063232 (0)
--1956:0:aspacem    5: ANON 00103ec000-0011947fff     21m rwx--
--1956:0:aspacem    6:      0011948000-007f880fff   1759m
--1956:0:aspacem    7: ANON 007f881000-007f8a1fff  135168 rwx--
--1956:0:aspacem    8:      007f8a2000-007fff6fff 7688192
--1956:0:aspacem    9: ANON 007fff7000-007fff7fff    4096 r-x--
--1956:0:aspacem   10:      007fff8000-0081ffffff     32m
--1956:0:aspacem   11: RSVN 0082000000-0082000fff    4096 ----- SmFixed
--1956:0:aspacem   12:      0082001000-00ffffffff   2015m
--1956:0:aspacem  >>>
--1956-- core    :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1956-- dinfo   :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1956-- (null)  :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 0 rzB
--1956-- demangle:        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1956-- ttaux   :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1956-- translate:            fast SP updates identified: 0 (   --%)
--1956-- translate:   generic_known SP updates identified: 0 (   --%)
--1956-- translate: generic_unknown SP updates identified: 0 (   --%)
--1956--     tt/tc: 0 tt lookups requiring 0 probes
--1956--     tt/tc: 0 fast-cache updates, 0 flushes
--1956--  transtab: new        0 (0 -> 0; ratio 0:10) [0 scs]
--1956--  transtab: dumped     0 (0 -> ??)
--1956--  transtab: discarded  0 (0 -> ??)
--1956-- scheduler: 0 event checks.
--1956-- scheduler: 0 indir transfers, 0 misses (1 in 0)
--1956-- scheduler: 0/0 major/minor sched events.
--1956--    sanity: 0 cheap, 0 expensive checks.
==1956==
==1956==     Valgrind's memory management: out of memory:
==1956==        newSuperblock's request for 4194304 bytes failed.
==1956==        22536192 bytes have already been allocated.
==1956==     Valgrind cannot continue.  Sorry.
==1956==
==1956==     There are several possible reasons for this.
==1956==     - You have some kind of memory limit in place.  Look at the
==1956==       output of 'ulimit -a'.  Is there a limit on the size of
==1956==       virtual memory or address space?
==1956==     - You have run out of swap space.
==1956==     - Valgrind has a bug.  If you think this is the case or you are
==1956==     not sure, please let us know and we'll try to fix it.
==1956==     Please note that programs can take substantially more memory than
==1956==     normal when running under Valgrind tools, eg. up to twice or
==1956==     more, depending on the tool.  On a 64-bit machine, Valgrind
==1956==     should be able to make use of up 32GB memory.  On a 32-bit
==1956==     machine, Valgrind should be able to use all the memory available
==1956==     to a single process, up to 4GB if that's how you have your
==1956==     kernel configured.  Most 32-bit Linux setups allow a maximum of
==1956==     3GB per process.
==1956==
==1956==     Whatever the reason, Valgrind cannot continue.  Sorry.




-----Original Message-----
From: Philippe Waroquiers [mailto:phi...@sk...]
Sent: Friday, April 10, 2015 4:23 PM
To: Zhu, Yanwen
Cc: val...@li...
Subject: Re: [Valgrind-users] valgrind out of memory error

On Fri, 2015-04-10 at 20:04 +0000, Zhu, Yanwen wrote:
> Has anyone seen this error when running valgrind 3.10.1 in a MIPS64 
> platform?
> 
>  
> 
> ==1769==     Valgrind's memory management: out of memory:
> 
> ==1769==        newSuperblock's request for 4194304 bytes failed.
> 
> ==1769==        22536192 bytes have already been allocated.
> 
> ==1769==     Valgrind cannot continue.  Sorry.
Not seen such a thing (but not having access to a mips platform, it is not easy to see what is going on).

What looks really strange is the very low level value of the already allocated bytes.

So, maybe the aspacemgr view of the memory mapping is not in sync with the kernel view.

Normally, such an OOM produces the state of the memory and the aspacemgr state.
More trace would also be useful.

So, can you run with
   -v -v -v -d -d -d
and send the full log (if not too big).

Also, might be useful to run with
  --sanity-level=4
as this will report aspacemgr<>kernel desync.

Philippe

Re: [Valgrind-users] valgrind out of memory error

[Zhu, Y. <Yan...@vi...>]

Philippe,

Thanks for your prompt reply, see below for the output when running with -v -v -v -d -d -d and --sanity-level=4


# valgrind -v -v -v -d -d -d
--1955:1:debuglog DebugLog system started by Stage 1, level 3 logging requested
--1955:1:launcher no tool requested, defaulting to 'memcheck'
--1955:1:launcher no client specified, defaulting platform to 'mips64-linux'
--1955:1:launcher launching /usr/lib/valgrind/memcheck-mips64-linux
--1955:1:debuglog DebugLog system started by Stage 2 (main), level 3 logging requested
--1955:1:main     Welcome to Valgrind version 3.10.1 debug logging
--1955:1:main     Checking current stack is plausible
--1955:1:main     Checking initial stack was noted
--1955:1:main     Starting the address space manager
--1955:2:aspacem            sp_at_startup = 0x007f8a7ca0 (supplied)
--1955:2:aspacem                  minAddr = 0x0004000000 (computed)
--1955:2:aspacem                  maxAddr = 0x00ffffffff (computed)
--1955:2:aspacem                   cStart = 0x0004000000 (computed)
--1955:2:aspacem                   vStart = 0x0082000000 (computed)
--1955:2:aspacem    suggested_clstack_end = 0x00ff000fff (computed)
--1955:2:aspacem    <<< SHOW_SEGMENTS: Initial layout (4 segments, 0 segnames)
--1955:2:aspacem      0: RSVN 0000000000-0003ffffff     64m ----- SmFixed
--1955:2:aspacem      1:      0004000000-0081ffffff   2016m
--1955:2:aspacem      2: RSVN 0082000000-0082000fff    4096 ----- SmFixed
--1955:2:aspacem      3:      0082001000-00ffffffff   2015m
--1955:2:aspacem    >>>
--1955:2:aspacem    Reading /proc/self/maps
--1955:2:aspacem    <<< SHOW_SEGMENTS: With contents of /proc/self/maps (13 segments, 1 segnames)
--1955:2:aspacem    ( 0) /usr/lib/valgrind/memcheck-mips64-linux
--1955:2:aspacem      0: RSVN 0000000000-0003ffffff     64m ----- SmFixed
--1955:2:aspacem      1:      0004000000-000fffffff    192m
--1955:2:aspacem      2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 i=2074    o=0       (0)
--1955:2:aspacem      3:      00103df000-00103dffff    4096
--1955:2:aspacem      4: FILE 00103e0000-00103ebfff   49152 rw--- d=0x100 i=2074    o=4063232 (0)
--1955:2:aspacem      5: ANON 00103ec000-0011947fff     21m rwx--
--1955:2:aspacem      6:      0011948000-007f886fff   1759m
--1955:2:aspacem      7: ANON 007f887000-007f8a7fff  135168 rwx--
--1955:2:aspacem      8:      007f8a8000-007fff6fff 7663616
--1955:2:aspacem      9: ANON 007fff7000-007fff7fff    4096 r-x--
--1955:2:aspacem     10:      007fff8000-0081ffffff     32m
--1955:2:aspacem     11: RSVN 0082000000-0082000fff    4096 ----- SmFixed
--1955:2:aspacem     12:      0082001000-00ffffffff   2015m
--1955:2:aspacem    >>>
--1955:1:main     Address space manager is running
--1955:1:main     Starting the dynamic memory manager
--1955:0:aspacem  <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1 segnames)
--1955:0:aspacem  ( 0) /usr/lib/valgrind/memcheck-mips64-linux
--1955:0:aspacem    0: RSVN 0000000000-0003ffffff     64m ----- SmFixed
--1955:0:aspacem    1:      0004000000-000fffffff    192m
--1955:0:aspacem    2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 i=2074    o=0       (0)
--1955:0:aspacem    3:      00103df000-00103dffff    4096
--1955:0:aspacem    4: FILE 00103e0000-00103ebfff   49152 rw--- d=0x100 i=2074    o=4063232 (0)
--1955:0:aspacem    5: ANON 00103ec000-0011947fff     21m rwx--
--1955:0:aspacem    6:      0011948000-007f886fff   1759m
--1955:0:aspacem    7: ANON 007f887000-007f8a7fff  135168 rwx--
--1955:0:aspacem    8:      007f8a8000-007fff6fff 7663616
--1955:0:aspacem    9: ANON 007fff7000-007fff7fff    4096 r-x--
--1955:0:aspacem   10:      007fff8000-0081ffffff     32m
--1955:0:aspacem   11: RSVN 0082000000-0082000fff    4096 ----- SmFixed
--1955:0:aspacem   12:      0082001000-00ffffffff   2015m
--1955:0:aspacem  >>>
--1955-- core    :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1955-- dinfo   :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1955-- (null)  :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 0 rzB
--1955-- demangle:        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1955-- ttaux   :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1955-- translate:            fast SP updates identified: 0 (   --%)
--1955-- translate:   generic_known SP updates identified: 0 (   --%)
--1955-- translate: generic_unknown SP updates identified: 0 (   --%)
--1955--     tt/tc: 0 tt lookups requiring 0 probes
--1955--     tt/tc: 0 fast-cache updates, 0 flushes
--1955--  transtab: new        0 (0 -> 0; ratio 0:10) [0 scs]
--1955--  transtab: dumped     0 (0 -> ??)
--1955--  transtab: discarded  0 (0 -> ??)
--1955-- scheduler: 0 event checks.
--1955-- scheduler: 0 indir transfers, 0 misses (1 in 0)
--1955-- scheduler: 0/0 major/minor sched events.
--1955--    sanity: 0 cheap, 0 expensive checks.
==1955==
==1955==     Valgrind's memory management: out of memory:
==1955==        newSuperblock's request for 4194304 bytes failed.
==1955==        22536192 bytes have already been allocated.
==1955==     Valgrind cannot continue.  Sorry.
==1955==
==1955==     There are several possible reasons for this.
==1955==     - You have some kind of memory limit in place.  Look at the
==1955==       output of 'ulimit -a'.  Is there a limit on the size of
==1955==       virtual memory or address space?
==1955==     - You have run out of swap space.
==1955==     - Valgrind has a bug.  If you think this is the case or you are
==1955==     not sure, please let us know and we'll try to fix it.
==1955==     Please note that programs can take substantially more memory than
==1955==     normal when running under Valgrind tools, eg. up to twice or
==1955==     more, depending on the tool.  On a 64-bit machine, Valgrind
==1955==     should be able to make use of up 32GB memory.  On a 32-bit
==1955==     machine, Valgrind should be able to use all the memory available
==1955==     to a single process, up to 4GB if that's how you have your
==1955==     kernel configured.  Most 32-bit Linux setups allow a maximum of
==1955==     3GB per process.
==1955==
==1955==     Whatever the reason, Valgrind cannot continue.  Sorry.
#
#
#
#
#
# valgrind --sanity-level=4
--1956:0:aspacem  <<< SHOW_SEGMENTS: out_of_memory (13 segments, 1 segnames)
--1956:0:aspacem  ( 0) /usr/lib/valgrind/memcheck-mips64-linux
--1956:0:aspacem    0: RSVN 0000000000-0003ffffff     64m ----- SmFixed
--1956:0:aspacem    1:      0004000000-000fffffff    192m
--1956:0:aspacem    2: FILE 0010000000-00103defff 4059136 r-x-- d=0x100 i=2074    o=0       (0)
--1956:0:aspacem    3:      00103df000-00103dffff    4096
--1956:0:aspacem    4: FILE 00103e0000-00103ebfff   49152 rw--- d=0x100 i=2074    o=4063232 (0)
--1956:0:aspacem    5: ANON 00103ec000-0011947fff     21m rwx--
--1956:0:aspacem    6:      0011948000-007f880fff   1759m
--1956:0:aspacem    7: ANON 007f881000-007f8a1fff  135168 rwx--
--1956:0:aspacem    8:      007f8a2000-007fff6fff 7688192
--1956:0:aspacem    9: ANON 007fff7000-007fff7fff    4096 r-x--
--1956:0:aspacem   10:      007fff8000-0081ffffff     32m
--1956:0:aspacem   11: RSVN 0082000000-0082000fff    4096 ----- SmFixed
--1956:0:aspacem   12:      0082001000-00ffffffff   2015m
--1956:0:aspacem  >>>
--1956-- core    :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1956-- dinfo   :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1956-- (null)  :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 0 rzB
--1956-- demangle:        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1956-- ttaux   :        0/       0  max/curr mmap'd, 0/0 unsplit/split sb unmmap'd,         0/       0 max/curr,           0/         0 totalloc-blocks/bytes,           0 searches 12 rzB
--1956-- translate:            fast SP updates identified: 0 (   --%)
--1956-- translate:   generic_known SP updates identified: 0 (   --%)
--1956-- translate: generic_unknown SP updates identified: 0 (   --%)
--1956--     tt/tc: 0 tt lookups requiring 0 probes
--1956--     tt/tc: 0 fast-cache updates, 0 flushes
--1956--  transtab: new        0 (0 -> 0; ratio 0:10) [0 scs]
--1956--  transtab: dumped     0 (0 -> ??)
--1956--  transtab: discarded  0 (0 -> ??)
--1956-- scheduler: 0 event checks.
--1956-- scheduler: 0 indir transfers, 0 misses (1 in 0)
--1956-- scheduler: 0/0 major/minor sched events.
--1956--    sanity: 0 cheap, 0 expensive checks.
==1956==
==1956==     Valgrind's memory management: out of memory:
==1956==        newSuperblock's request for 4194304 bytes failed.
==1956==        22536192 bytes have already been allocated.
==1956==     Valgrind cannot continue.  Sorry.
==1956==
==1956==     There are several possible reasons for this.
==1956==     - You have some kind of memory limit in place.  Look at the
==1956==       output of 'ulimit -a'.  Is there a limit on the size of
==1956==       virtual memory or address space?
==1956==     - You have run out of swap space.
==1956==     - Valgrind has a bug.  If you think this is the case or you are
==1956==     not sure, please let us know and we'll try to fix it.
==1956==     Please note that programs can take substantially more memory than
==1956==     normal when running under Valgrind tools, eg. up to twice or
==1956==     more, depending on the tool.  On a 64-bit machine, Valgrind
==1956==     should be able to make use of up 32GB memory.  On a 32-bit
==1956==     machine, Valgrind should be able to use all the memory available
==1956==     to a single process, up to 4GB if that's how you have your
==1956==     kernel configured.  Most 32-bit Linux setups allow a maximum of
==1956==     3GB per process.
==1956==
==1956==     Whatever the reason, Valgrind cannot continue.  Sorry.




-----Original Message-----
From: Philippe Waroquiers [mailto:phi...@sk...] 
Sent: Friday, April 10, 2015 4:23 PM
To: Zhu, Yanwen
Cc: val...@li...
Subject: Re: [Valgrind-users] valgrind out of memory error

On Fri, 2015-04-10 at 20:04 +0000, Zhu, Yanwen wrote:
> Has anyone seen this error when running valgrind 3.10.1 in a MIPS64 
> platform?
> 
>  
> 
> ==1769==     Valgrind's memory management: out of memory:
> 
> ==1769==        newSuperblock's request for 4194304 bytes failed.
> 
> ==1769==        22536192 bytes have already been allocated.
> 
> ==1769==     Valgrind cannot continue.  Sorry.
Not seen such a thing (but not having access to a mips platform, it is not easy to see what is going on).

What looks really strange is the very low level value of the already allocated bytes.

So, maybe the aspacemgr view of the memory mapping is not in sync with the kernel view.

Normally, such an OOM produces the state of the memory and the aspacemgr state.
More trace would also be useful.

So, can you run with
   -v -v -v -d -d -d
and send the full log (if not too big).

Also, might be useful to run with
  --sanity-level=4
as this will report aspacemgr<>kernel desync.

Philippe

Re: [Valgrind-users] valgrind out of memory error

[Philippe W. <phi...@sk...>]

On Fri, 2015-04-10 at 20:04 +0000, Zhu, Yanwen wrote:
> Has anyone seen this error when running valgrind 3.10.1 in a MIPS64
> platform?
> 
>  
> 
> ==1769==     Valgrind's memory management: out of memory:
> 
> ==1769==        newSuperblock's request for 4194304 bytes failed.
> 
> ==1769==        22536192 bytes have already been allocated.
> 
> ==1769==     Valgrind cannot continue.  Sorry.
Not seen such a thing (but not having access to a mips platform,
it is not easy to see what is going on).

What looks really strange is the very low level value of
the already allocated bytes.

So, maybe the aspacemgr view of the memory mapping is
not in sync with the kernel view.

Normally, such an OOM produces the state of the memory
and the aspacemgr state.
More trace would also be useful.

So, can you run with
   -v -v -v -d -d -d 
and send the full log (if not too big).

Also, might be useful to run with 
  --sanity-level=4
as this will report aspacemgr<>kernel desync.

Philippe

[Valgrind-users] valgrind out of memory error

[Zhu, Y. <Yan...@vi...>]

Has anyone seen this error when running valgrind 3.10.1 in a MIPS64 platform?

==1769==     Valgrind's memory management: out of memory:
==1769==        newSuperblock's request for 4194304 bytes failed.
==1769==        22536192 bytes have already been allocated.
==1769==     Valgrind cannot continue.  Sorry.

I have enough memory in my system as shown below:
# top
Mem: 167900K used, 1800920K free, 0K shrd, 848K buff, 25840K cached
CPU:   0% usr   0% sys   0% nic 100% idle   0% io   0% irq   0% sirq
Load average: 0.00 0.02 0.05 1/68 1949
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
1899     1 root     S    21036   1%   0% /usr/sbin/uia_init
1931  1899 root     S    20680   1%   0% /usr/sbin/uia_init
1930  1899 root     S     6244   0%   0% zebra -i /tmp/quagga/zebra.pid
1932  1899 root     S     5068   0%   0% /usr/sbin/stunnel /etc/stunnel/stunnel
1902     1 root     S     2956   0%   0% login
1832     1 root     S     2944   0%   0% /usr/sbin/thttpd -C /etc/thttpd.conf -
1834     1 root     S     2944   0%   0% /usr/sbin/thttpd -C /etc/thttpd.conf -
1901     1 root     S     2892   0%   0% /bin/busybox ash --login
    1     0 root     S     2828   0%   0% init
1903     1 root     S     2828   0%   0% /sbin/syslogd -n
1904     1 root     S     2828   0%   0% /sbin/klogd -n
1847     1 root     S     2828   0%   0% /usr/sbin/telnetd -l /bin/sh
1949  1901 root     R     2828   0%   0% top
  163     2 root     SW       0   0%   0% [kworker/3:1]
  957     2 root     SW       0   0%   0% [kworker/0:1]
    6     2 root     SW       0   0%   0% [kworker/u8:0]
1008     2 root     SW       0   0%   0% [kworker/u8:3]
  955     2 root     SW       0   0%   0% [kworker/1:1]
  967     2 root     SW       0   0%   0% [kworker/2:1]
    9     2 root     SW       0   0%   0% [rcu_sched]
# free
             total         used         free       shared      buffers
Mem:       1968820       168148      1800672            0          848
-/+ buffers:             167300      1801520
Swap:            0            0            0
# ulimit -a
-f: file size (blocks)             36028797018963967
-t: cpu time (seconds)             18446744073709551615
-d: data seg size (kb)             18014398509481983
-s: stack size (kb)                8192
-c: core file size (blocks)        0
-m: resident set size (kb)         18014398509481983
-l: locked memory (kb)             64
-p: processes                      7569
-n: file descriptors               1024
-v: address space (kb)             18014398509481983
-w: locks                          18446744073709551615
-e: scheduling priority            0
-r: real-time priority             0

I really appreciate if I can get some help.

Thanks,
Yanwen

Re: [Valgrind-users] Valgrind failing to run applypatch in android recovery

[Shrinivas S. <shr...@gm...>]

Hi All,

I am a new bee to run valgrind,
I am trying to run android applypatch (
https://android.googlesource.com/platform/bootable/recovery/+/android-5.1.0_r3/applypatch/applypatch.c
)
Which internally uses libbz.so, (/external/bzip2)

but surprisingly with valgrind it is failing at decompress of patch file.
line number 817 (
https://android.googlesource.com/platform/external/bzip2/+/android-5.1.0_r3/bzlib.c
)

but if I run applypatch normally, it does its work properly, and returns
success,

but when I run it with valgrind, it enters into the while (true) loop,
first line printf statements are printing. but later after some time it
waits there and fails saying bz error -4.

I have been running with this problem from many days now, when i searched
in net, found some valgrind hang issues reported in 3.10.0 version, which
is what i am using currently.

I found this patch which said it fixes some hang issue:(
http://permalink.gmane.org/gmane.comp.debugging.valgrind.devel/28264)

but dint fix my problem, when I tried it.

Please suggest me, If i am doing any wrong

On Thu, Apr 2, 2015 at 5:39 PM, Shrinivas Sahukar <
shr...@gm...> wrote:

> Hi All,
>
> I am a new bee to run valgrind,
> I am trying to run android applypatch (
> https://android.googlesource.com/platform/bootable/recovery/+/android-5.1.0_r3/applypatch/applypatch.c
> )
> Which internally uses libbz.so, (/external/bzip2)
>
> but surprisingly with valgrind it is failing at decompress of patch file.
> line number 817 (
> https://android.googlesource.com/platform/external/bzip2/+/android-5.1.0_r3/bzlib.c
> )
>
> but if I run applypatch normally, it does its work properly, and returns
> success,
>
> but when I run it with valgrind, it enters into the while (true) loop,
> first line printf statements are printing. but later after some time it
> waits there and fails saying bz error -4.
>
> I have been running with this problem from many days now, when i searched
> in net, found some valgrind hang issues reported in 3.10.0 version, which
> is what i am using currently.
>
> I found this patch which said it fixes some hang issue:(
> http://permalink.gmane.org/gmane.comp.debugging.valgrind.devel/28264)
>
> but dint fix my problem, when I tried it.
>
> Please suggest me, If i am doing any wrong
>
>
> --
> Regards,
> Shrinivas Sahukar.
>



-- 
Regards,
Shrinivas Sahukar.

[Valgrind-users] fuse filesystem syscall deadlocks

[Atalay O. <aoz...@ra...>]

This is essentially the same bug as:
https://bugs.kde.org/show_bug.cgi?id=278057
A patch was applied for this bug in version 3.7 and it is considered fixed.
I am using version 3.10, I confirmed in the source code that the patch is
applied. Valgrind still dread-locks when used to test an application that
uses fuse in our environment. We are using 64bit Ubuntu 12.04LTS.
Anybody knows if there is an easy fix?

Thanks,

Atalay

Re: [Valgrind-users] Failed to read a valid object file image from memory.

[Philippe W. <phi...@sk...>]

On Tue, 2015-04-07 at 23:10 +0100, "João M. S. Silva" wrote:
> > --db-attach=yes is deprecated in 3.10
> > and will be removed (sooner or later).
> >
> > Better use the Valgrind gdbserver.
> >
> > See
> > http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver
> > for more information.
> 
> Thanks for the vgdb suggestion.
> 
> I've tried it before but with --vgdb-error=1.
> 
> With --vgdb-error=0 like suggested in the manual you indicate, and 
> running gdb in another shell, I was able to eliminate the "Failed to 
> read a valid object file image from memory" error.
> 
> However, the possibly uninitialized variables seem initialized as before.
> 
> With --track-origins=yes, I see:
> 
> ==3541==  Uninitialised value was created by a stack allocation
> ==3541==    at 0x5A11639: 
> tesseract::Tesseract::rejection_passes(PAGE_RES*, ETEXT_DESC*, TBOX 
> const*, char const*) (control.cpp:591)
> 
> I'm not familiar with Tesseract's code, but it seems to indicate that in 
> the call in line 591 of control.cpp:
> 
>    quality_based_rejection(page_res_it, good_quality_doc);
> 
> One of the arguments is uninitialized when passed through the stack.
> 
> And if, inside the function, the error is in line 145 of docqual.cpp:
> 
>    if ((tessedit_good_quality_unrej && good_quality_doc))
> 
> then "good_quality_doc" should be the culprit (not "page_res_it"). But 
> this is a boolean correctly initialized:
> 
> (gdb) p good_quality_doc
> $1 = 1 '\001'
> 
> Any further hints?
> 
The origin (i.e. the stack allocation) is one of the local variables
in the function which is at line 591. Valgrind cannot give
a more precise indication of which variable.
Why the created by a stack allocation points somewhere inside a
function rather than at the beginning of the function I do not know.
Might depend on the way the compiler has optimised.

What you can further do is to use the memcheck monitor commands to
examine the definedness of the variables used on the line where the
error is detected.

See manual for more info
http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands

Philippe

Re: [Valgrind-users] make dies: " /usr/bin/ar: libcoregrind_amd64_linux_a-m_cpuid.o: No such file or directory"

[João M. S. S. <joa...@gm...>]

Hi,

Some quick, basic hints:

> % tar -xaf valgrind-3.10.1.tar.bz2

Does -a work for decompression? Maybe RHEL has an older version, but 
current tar versions by default detect the format of the input file, so 
xf is enough.

> % cd valgrind-3.10.1
> % ./configure --prefix=/home/name/bin
> % make
> <<error as shown in subject line>>

 From my experience valgrind always compiled straightforwardly but I use 
Mint or Ubuntu.

Maybe configure did not run OK? Try to look at its output to see if any 
configuration failed.

configure uses /bin/sh, is it pointing to bash in RHEL? In Ubuntu 
sometimes it is pointing to dash, which does not support the complete 
bash syntax.

-- 
João M. S. Silva

[Valgrind-users] make dies: " /usr/bin/ar: libcoregrind_amd64_linux_a-m_cpuid.o: No such file or directory"

[Robert E F. <bfa...@ra...>]

Hi all,

First let me say, I tried to look at the mail list archives first but after
waiting 8 hours for the page to load, gave up.

I am trying to do a "no root access" compile and install on a RHEL6
machine. I downloaded the 3.10.1 tarball,
% tar -xaf valgrind-3.10.1.tar.bz2
% cd valgrind-3.10.1
% ./configure --prefix=/home/name/bin
% make
<<error as shown in subject line>>

I went back through the log and found where it should have created the
object file in question. I saw that the gcc command was proceeded by
"compile" command which describes itself as a script to be used if the
compiler does not support "-c -o" options. I thought gcc did, so this was
bizarre. When I ran either the "compile gcc" command or the "gcc" by itself
with the rest of the command line copied from the log, I got mismatched ".
error I thought it was odd that the file names in double-quotes were
preceded by double-quote, backslash, double-quote which would put the
escaped double-quote inside the quoted string, but at the end it had the
same thing which puts the escaped double-quote outside the quoted string. I
tried to fool around with double quotes generation in the Makefile, but
could not get something that worked. I could get the file to compile if I
manually replaced the double-quote, backslash, double-quote occurrences
with just double-quote.

How should I proceed?

Thanks,
Bob

Re: [Valgrind-users] How to mark separate bits as undefined?

[Florian K. <fl...@ei...>]

On 08.04.2015 11:37, juris wrote:

> Thank you very much! The example is helpful. (But the documentation isn't :-(

You know how it is with documentation... Patches welcome.  :)

> This looks sufficient to implement the marking of separate bits.
> Am I safe to assume that V bit value '0' will always mean 'defined' and
> '1' will mean 'undefined'?

Yes.
memcheck/mc_include.h:#define V_BIT_DEFINED         0
memcheck/mc_include.h:#define V_BIT_UNDEFINED       1

   Florian

Re: [Valgrind-users] How to mark separate bits as undefined?

[juris <ju...@mt...>]

On Wed, 8 Apr 2015 09:00:43 +0300
Azat Khuzhin <a3a...@gm...> wrote:

> You could look at VALGRIND_SET_VBITS here:
> http://valgrind.org/docs/manual/mc-manual.html
> 
> Example here:
> http://repo.or.cz/w/valgrind.git/blob/HEAD:/memcheck/tests/metadata.c

Thank you very much! The example is helpful. (But the documentation isn't :-(
This looks sufficient to implement the marking of separate bits.
Am I safe to assume that V bit value '0' will always mean 'defined' and
'1' will mean 'undefined'? Or at least that this meaning will not be
different for different address ranges?
I cannot find this mentioned in manual...

Re: [Valgrind-users] How to mark separate bits as undefined?

[John R. <jr...@bi...>]

> Hello, I was wondering if it is possible to partially mark
> a memory location as undefined when running under valgrind.

Quoting the documentation  http://valgrind.org/info/tools.html :
>  Memcheck tracks addressability at the byte-level, and initialisation of values at the bit-level. As a result, it can detect the use of single uninitialised bits, and does not report spurious errors on bitfield operations

Therefore: Run memcheck under a debugger, and watch while memcheck checks this program:
-----
#include <stdlib.h>
int *p;
int main()
{
	p = (int *)malloc(100);
	p[5] &= 0xec6da539;  /* clear some bits, leave the rest uninit */
	return p[0xff & p[5]];  /* indexing by uninit is an immediate error */
}
-----

Re: [Valgrind-users] How to mark separate bits as undefined?

[Azat K. <a3a...@gm...>]

On Wed, Apr 08, 2015 at 08:43:27AM +0300, juris wrote:
> Hello, I was wondering if it is possible to partially mark
> a memory location as undefined when running under valgrind.
> 
> I am using a custom allocator, that allocates a some bits
> in a bitmap for each memory allocation. I would like to catch
> access to these bits before they are initialized. Is there some
> way to do it?
> 
> Thank you for the help.

You could look at VALGRIND_SET_VBITS here:
http://valgrind.org/docs/manual/mc-manual.html

Example here:
http://repo.or.cz/w/valgrind.git/blob/HEAD:/memcheck/tests/metadata.c

[Valgrind-users] How to mark separate bits as undefined?

[juris <ju...@mt...>]

Hello, I was wondering if it is possible to partially mark
a memory location as undefined when running under valgrind.

I am using a custom allocator, that allocates a some bits
in a bitmap for each memory allocation. I would like to catch
access to these bits before they are initialized. Is there some
way to do it?

Thank you for the help.

Re: [Valgrind-users] Failed to read a valid object file image from memory.

[João M. S. S. <joa...@gm...>]

> --db-attach=yes is deprecated in 3.10
> and will be removed (sooner or later).
>
> Better use the Valgrind gdbserver.
>
> See
> http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver
> for more information.

Thanks for the vgdb suggestion.

I've tried it before but with --vgdb-error=1.

With --vgdb-error=0 like suggested in the manual you indicate, and 
running gdb in another shell, I was able to eliminate the "Failed to 
read a valid object file image from memory" error.

However, the possibly uninitialized variables seem initialized as before.

With --track-origins=yes, I see:

==3541==  Uninitialised value was created by a stack allocation
==3541==    at 0x5A11639: 
tesseract::Tesseract::rejection_passes(PAGE_RES*, ETEXT_DESC*, TBOX 
const*, char const*) (control.cpp:591)

I'm not familiar with Tesseract's code, but it seems to indicate that in 
the call in line 591 of control.cpp:

   quality_based_rejection(page_res_it, good_quality_doc);

One of the arguments is uninitialized when passed through the stack.

And if, inside the function, the error is in line 145 of docqual.cpp:

   if ((tessedit_good_quality_unrej && good_quality_doc))

then "good_quality_doc" should be the culprit (not "page_res_it"). But 
this is a boolean correctly initialized:

(gdb) p good_quality_doc
$1 = 1 '\001'

Any further hints?

-- 
João M. S. Silva

Re: [Valgrind-users] Failed to read a valid object file image from memory.

[Philippe W. <phi...@sk...>]

On Tue, 2015-04-07 at 17:22 +0100, "João M. S. Silva" wrote:
> Hi,
> 
> I'm trying to debug a program with memcheck. There is an error:
> 
> --19524-- memcheck GC: 1000 nodes, 419 survivors (41.9%)
> --19524-- memcheck GC: 1014 new table size (driftup)
> --19524-- REDIR: 0x72c60c0 (libc.so.6:__strspn_sse42) redirected to 
> 0x4c32010 (strspn)
> ==19524== Conditional jump or move depends on uninitialised value(s)
> ==19524==    at 0x5A1E317: 
> tesseract::Tesseract::quality_based_rejection(PAGE_RES_IT&, unsigned 
> char) (docqual.cpp:145)
> ==19524==    by 0x5A11871: 
> tesseract::Tesseract::rejection_passes(PAGE_RES*, ETEXT_DESC*, TBOX 
> const*, char const*) (control.cpp:680)
> ==19524==    by 0x5A1551E: 
> tesseract::Tesseract::recog_all_words(PAGE_RES*, ETEXT_DESC*, TBOX 
> const*, char const*, int) (control.cpp:371)
> ==19524==    by 0x5A05D93: 
> tesseract::TessBaseAPI::Recognize(ETEXT_DESC*) (baseapi.cpp:747)
> ==19524==    by 0x5A05F7C: tesseract::TessBaseAPI::GetUTF8Text() 
> (baseapi.cpp:1019)
> ==19524==    by 0x41D2D1: Tesseract::ocr(cv::Mat) (Tesseract.cpp:26)
> ==19524==    by 0x4066F8: main (test.cpp:206)
> ==19524==
> ==19524==
> ==19524== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y

--db-attach=yes is deprecated in 3.10
and will be removed (sooner or later).

Better use the Valgrind gdbserver.

See
http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver
for more information.

Philippe

[Valgrind-users] Failed to read a valid object file image from memory.

[João M. S. S. <joa...@gm...>]

Hi,

I'm trying to debug a program with memcheck. There is an error:

--19524-- memcheck GC: 1000 nodes, 419 survivors (41.9%)
--19524-- memcheck GC: 1014 new table size (driftup)
--19524-- REDIR: 0x72c60c0 (libc.so.6:__strspn_sse42) redirected to 
0x4c32010 (strspn)
==19524== Conditional jump or move depends on uninitialised value(s)
==19524==    at 0x5A1E317: 
tesseract::Tesseract::quality_based_rejection(PAGE_RES_IT&, unsigned 
char) (docqual.cpp:145)
==19524==    by 0x5A11871: 
tesseract::Tesseract::rejection_passes(PAGE_RES*, ETEXT_DESC*, TBOX 
const*, char const*) (control.cpp:680)
==19524==    by 0x5A1551E: 
tesseract::Tesseract::recog_all_words(PAGE_RES*, ETEXT_DESC*, TBOX 
const*, char const*, int) (control.cpp:371)
==19524==    by 0x5A05D93: 
tesseract::TessBaseAPI::Recognize(ETEXT_DESC*) (baseapi.cpp:747)
==19524==    by 0x5A05F7C: tesseract::TessBaseAPI::GetUTF8Text() 
(baseapi.cpp:1019)
==19524==    by 0x41D2D1: Tesseract::ocr(cv::Mat) (Tesseract.cpp:26)
==19524==    by 0x4066F8: main (test.cpp:206)
==19524==
==19524==
==19524== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y

and then I attach to gdb but get:

Failed to read a valid object file image from memory.
0x0000000005a1e317 in tesseract::Tesseract::quality_based_rejection 
(this=this@entry=0x1a47b780, page_res_it=...,
     good_quality_doc=good_quality_doc@entry=1 '\001') at docqual.cpp:145
145	  if ((tessedit_good_quality_unrej && good_quality_doc))
(gdb) p tessedit_good_quality_unrej
$1 = {<tesseract::Param> = {name_ = 0x5bdf54f 
"tessedit_good_quality_unrej", info_ = 0x5bdf56b "Reduce rejection on 
good docs", init_ = false,
     debug_ = false}, value_ = 1 '\001', params_vec_ = 0x1a47b9a0}
(gdb) p good_quality_doc
$2 = 1 '\001'

What does "Failed to read a valid object file image from memory" mean? 
Does it come from gdb or may be caused upstream by valgrind?

This is a "Conditional jump or move" error but the variables, as printed 
above in gdb, seem initialized? So it this a false positive?

Any help?

Thanks.

-- 
João M. S. Silva

Re: [Valgrind-users] problems tracking heap memory and free...

[Philippe W. <phi...@sk...>]

On Fri, 2015-04-03 at 14:47 +0100, lmx wrote:
> how can total heap be:
> total heap usage: 0 allocs, 0 frees, 0 bytes allocated ???
> 
> even with "valgrind --tool=memcheck ./program"
> 
> i get the same :(
> 
> does any one knows how to track the mallocs and free ??
The classical explanations for the above are:
  1. the application is statically linked
  2. the application is using an alternate malloc library
     (e.g. tcmalloc or jemalloc or ...)
  3. the dynamic loader does not support LD_PRELOAD

For 1 and 2, you can use --soname-synonyms=... to indicate to
valgrind that the malloc lib is static or in which soname it is found.

For 3, you have to find (or recompile) a dynamic loader
that supports LD_PRELOAD.

Philippe

[Valgrind-users] problems tracking heap memory and free...

[lmx <lm...@sa...>]

Hi guys,

I am developing an app, and at the state it is, i am looking now to 
details...

I tried valgrind-3.8.1, on Debian amd_64.

struct record{
     uint8_t        data_size;
     uint8_t        rec_type;
     uint16_t    addr;
     uint8_t        *data;
     uint8_t        checksum;
};

struct holder{
     uint32_t nrecords;
     struct record *records;
};

struct holder blahhh = {0, NULL);

blahhh.records = ( struct record *) calloc( sizeof( struct record ), 
holder.nrecords );
blahhh.records[ record_no ].data = calloc( record_len, 1 );//I alloc an 
amount of record data chars

when i freed the mem i free everithyng

  free(blahhh.records[ record_no ].data);
free(blahhh.records);

my problem is..

I run :

valgrind ./program

and I get lots of unitialized blocks :S
..
....
.....
==24106== Use of uninitialised value of size 8
==24106==    at 0x40A9ED: _int_free (in 
/home/tuxd3v/Desktop/geany/lypus_parser/parsers)
==24106==    by 0x401782: ihx_close (ihx.c:162)
==24106==    by 0x401E2C: main (main.c:18)
==24106==
==24106== Use of uninitialised value of size 8
==24106==    at 0x40ACC0: _int_free (in 
/home/tuxd3v/Desktop/geany/lypus_parser/parsers)
==24106==    by 0x401782: ihx_close (ihx.c:162)
==24106==    by 0x401E2C: main (main.c:18)
==24106==
==24106==
==24106== HEAP SUMMARY:
==24106==     in use at exit: 0 bytes in 0 blocks
==24106==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==24106==
==24106== All heap blocks were freed -- no leaks are possible

how can total heap be:
total heap usage: 0 allocs, 0 frees, 0 bytes allocated ???

even with "valgrind --tool=memcheck ./program"

i get the same :(

does any one knows how to track the mallocs and free ??

thanks in advance

regards,
tux

Re: [Valgrind-users] _mm_maskstore_ps issue

[Mark A. <mar...@gm...>]

Hi,

This issue seems to be fixed in the valgrind trunk since January 2015.

Thanks for the quick response, Julian!

Mark

On Sun, Mar 29, 2015 at 7:39 PM, Julian Seward <js...@ac...> wrote:

> On 29/03/15 19:26, Mark Abraham wrote:
> > Hi,
> >
> > I was writing unit tests for some code that used the x86 compiler
> intrinsic
> > _mm_maskstore_ps (
> >
> https://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-C32657F6-AAF5-4DCC-AC94-2BA02AEBADFB.htm
> ).
> > I observed that Valgrind 3.10.1 thought the resulting instruction was
> > illegal. However, non-valgrind execution of the code works correctly (on
> an
> > avx machine, of course). Compiler gcc (Ubuntu 4.9.2-0ubuntu1~14.04) 4.9.2
> > (same with clang 3.5.0)
>
> I think this was fixed late January, after 3.10.1 shipped.  Try using
> the trunk
>
>   svn co svn://svn.valgrind.org/valgrind/trunk
>   cd trunk ;
>   ./autogen.sh
>   configure/build as normal.
>
> J
>
>

[Valgrind-users] _mm_maskstore_ps issue

[Mark A. <mar...@gm...>]

Hi,

I was writing unit tests for some code that used the x86 compiler intrinsic
_mm_maskstore_ps (
https://software.intel.com/sites/products/documentation/doclib/iss/2013/compiler/cpp-lin/GUID-C32657F6-AAF5-4DCC-AC94-2BA02AEBADFB.htm).
I observed that Valgrind 3.10.1 thought the resulting instruction was
illegal. However, non-valgrind execution of the code works correctly (on an
avx machine, of course). Compiler gcc (Ubuntu 4.9.2-0ubuntu1~14.04) 4.9.2
(same with clang 3.5.0)

Code snippet to reproduce:

#include <immintrin.h>
#include <xmmintrin.h>
#include <iostream>

int main(int, char **)
{
    float dest[32];
    __m128 source = _mm_set1_ps(1.0);
    __m128i mask128 = _mm_set_epi32(0, -1, -1, -1);
    _mm_maskstore_ps(dest, mask128, source);

    std::cout << dest[0] << dest[1] << dest[2] << dest[3];
    // Writes "111?" to stdout
    return 0;
}

g++ source.cpp -g -mavx -lstdc++

valgrind ./a.out

==442== Memcheck, a memory error detector
==442== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==442== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==442== Command: ./a.out
==442==
vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x71 0x2E 0x0 0x8B
0x9D 0x6C
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=1 VEX.L=0 VEX.nVVVV=0x1 ESC=0F38
vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
==442== valgrind: Unrecognised instruction at address 0x400835.
==442==    at 0x400835: _mm_maskstore_ps (avxintrin.h:937)
==442==    by 0x400835: main (maskstore-bug.cpp:10)
==442== Your program just tried to execute an instruction that Valgrind
==442== did not recognise.  There are two possible reasons for this.
==442== 1. Your program has a bug and erroneously jumped to a non-code
==442==    location.  If you are running Memcheck and you just saw a
==442==    warning about a bad jump, it's probably your program's fault.
==442== 2. The instruction is legitimate but Valgrind doesn't handle it,
==442==    i.e. it's Valgrind's fault.  If you think this is the case or
==442==    you are not sure, please let us know and we'll try to fix it.
==442== Either way, Valgrind will now raise a SIGILL signal which will
==442== probably kill your program.
==442==
==442== Process terminating with default action of signal 4 (SIGILL)
==442==  Illegal opcode at address 0x400835
==442==    at 0x400835: _mm_maskstore_ps (avxintrin.h:937)
==442==    by 0x400835: main (maskstore-bug.cpp:10)
==442==
==442== HEAP SUMMARY:
==442==     in use at exit: 0 bytes in 0 blocks
==442==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==442==
==442== All heap blocks were freed -- no leaks are possible
==442==
==442== For counts of detected and suppressed errors, rerun with: -v
==442== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction (core dumped)

Further observations I made:
* use of _mm_maskload_ps was fine
* disassembly by DDT showed that a VMASKMOVPS was being generated, which is
correct
* different masks, or an aligned dest made no difference

Is this a known issue, or have I done something wrong, or?

Thanks!

Mark