Menu
▾
▴
valgrind-users
|
From: Benjamin S. <bsc...@vr...> - 2013-11-18 10:42:03
|
Hi I just upgraded to valgrind 3.9.0 (debian sid backport). Most features work, but helgrind hangs with my application, and starts to fill up memory until the system starts swapping badly. This did not happen with 3.8. I tried with and without the suppressions file I'm using but that doesn't help. The only thing that might be an issue is that the application uses cuda and helgrind used to throw a lot of errors concerning cuda (all of which I dealt with using a suppression file) Is this something known or is there a way I can debug this further? Thank you Benjamin Schindler -- Dr. Benjamin Schindler, Software Developer VRVis Forschungs-GmbH, www.VRVis.at FN, 195369h, HG Wien mail: bsc...@vr..., tel +43(0)1 20501 30803 |
|
From: Philippe W. <phi...@sk...> - 2013-11-18 22:55:19
|
On Mon, 2013-11-18 at 11:40 +0100, Benjamin Schindler wrote:
> Hi
>
> I just upgraded to valgrind 3.9.0 (debian sid backport). Most features
> work, but helgrind hangs with my application, and starts to fill up
> memory until the system starts swapping badly. This did not happen with
> 3.8. I tried with and without the suppressions file I'm using but that
> doesn't help.
> The only thing that might be an issue is that the application uses cuda
> and helgrind used to throw a lot of errors concerning cuda (all of which
> I dealt with using a suppression file)
>
> Is this something known or is there a way I can debug this further?
You can try several things to get more info about what is going on:
* run with --profile-heap=yes
This will regularly provide details about who allocates what
* together with the above, you can also use gdb+vgdb to debug
your app running under valgrind, and use
monitor v.info memory aspacemgr
to get memory details at selected places.
It might be interesting to do the above with 3.8.1 and 3.9 and look at
the differences.
Note that in 3.9.0, several arenas (kind of memory
zones of the valgrind allocator) have been merged together.
Philippe
|
|
From: Benjamin S. <bsc...@vr...> - 2013-11-19 10:21:30
Attachments:
output
|
I did start with --profile-heap, and it gave me the following (before I
killed it). The bottom-most entry was growing really fast. The other
entries seemed to stay more or less contact. Attached for reference is a
complete run ( I snipped a few outputs because the mailing list doesn't
like messages over 40k)
I think the likelyhood of my app being faulty is rather small. It runs
all fine using memcheck and standalone as well as in drd (it does show a
few possible races)
Regards
Benjamin
-------- Arena "core": 159383552/159383552 max/curr mmap'd, 0/0
unsplit/split sb unmmap'd, 103453184/103453184 max/curr on_loan 8 rzB
--------
16 in 1: sched_lock
32 in 1: main.mpclo.3
32 in 2: hg.lae.1
32 in 1: stacks.rs.1
32 in 2: hg.lae.2
48 in 1: libhb.Thr__new.1
64 in 2: hg.lae.3
64 in 1: hg.mk_Thread.1
80 in 1: libhb.Thr__new.3 (local_Kws_and_stacks)
80 in 1: commandline.sua.3
80 in 1: libhb.verydead_thread_table_init.1
80 in 1: gdbserved_watches
96 in 2: commandline.sua.2
96 in 2: libhb.Thr__new.4
128 in 1: initimg-linux.sce.5
128 in 2: hashtable.Hc.1
144 in 1: m_cache
208 in 6: errormgr.sLTy.2
496 in 3: hg.lNaw.1
528 in 3: hg.laog__init.2
640 in 5: hg.laog__init.1
736 in 27: errormgr.losf.4
848 in 34: errormgr.sLTy.1
1,040 in 27: errormgr.losf.2
2,160 in 27: errormgr.losf.1
2,224 in 65: libhb.SO__Alloc.1
3,376 in 2: libhb.vts_tab_init.1
3,552 in 66: hg.ids.2
4,000 in 1: hg.ids.1
4,112 in 116: libhb.vts_set_focaa.1
4,304 in 17: hg.ids.5 (univ_laog)
5,264 in 65: hg.mk_Lock.1
5,280 in 44: hg.ids.4
6,160 in 1: hashtable.Hc.2
6,416 in 117: libhb.vts_set_init.1
15,632 in 10: libhb.aFfw.1 (LineF storage)
16,384 in 1: libhb.Thr__new.2
33,056 in 6: gdbsrv
49,216 in 1: execontext.reh1
49,216 in 1: hashtable.resize.1
237,632 in 4,945: hg.new_MallocMeta.1
389,152 in 3,632: perm_malloc
1,572,912 in 1: libhb.event_map_init.2 (context table)
2,097,168 in 1: libhb.libhb_init.1
6,656,864 in 67: libhb.event_map_init.1 (RCEC pools)
15,937,808 in 169: libhb.event_map_init.3 (OldRef pools)
25,078,672 in 11,973: libhb.event_map_init.4 (oldref tree)
51,266,896 in 1,068,037: libhb.zsm_init.1 (map_shmem)
On 11/18/2013 11:55 PM, Philippe Waroquiers wrote:
> On Mon, 2013-11-18 at 11:40 +0100, Benjamin Schindler wrote:
>> Hi
>>
>> I just upgraded to valgrind 3.9.0 (debian sid backport). Most features
>> work, but helgrind hangs with my application, and starts to fill up
>> memory until the system starts swapping badly. This did not happen with
>> 3.8. I tried with and without the suppressions file I'm using but that
>> doesn't help.
>> The only thing that might be an issue is that the application uses cuda
>> and helgrind used to throw a lot of errors concerning cuda (all of which
>> I dealt with using a suppression file)
>>
>> Is this something known or is there a way I can debug this further?
> You can try several things to get more info about what is going on:
> * run with --profile-heap=yes
> This will regularly provide details about who allocates what
> * together with the above, you can also use gdb+vgdb to debug
> your app running under valgrind, and use
> monitor v.info memory aspacemgr
> to get memory details at selected places.
>
> It might be interesting to do the above with 3.8.1 and 3.9 and look at
> the differences.
> Note that in 3.9.0, several arenas (kind of memory
> zones of the valgrind allocator) have been merged together.
>
> Philippe
>
>
--
Dr. Benjamin Schindler, Software Developer
VRVis Forschungs-GmbH, www.VRVis.at
FN, 195369h, HG Wien
mail: bsc...@vr..., tel +43(0)1 20501 30803
|
|
From: Philippe W. <phi...@sk...> - 2013-11-19 20:31:00
|
On Tue, 2013-11-19 at 11:20 +0100, Benjamin Schindler wrote: > I did start with --profile-heap, and it gave me the following (before I > killed it). The bottom-most entry was growing really fast. The other > entries seemed to stay more or less contact. Attached for reference is a > complete run ( I snipped a few outputs because the mailing list doesn't > like messages over 40k) > I think the likelyhood of my app being faulty is rather small. It runs > all fine using memcheck and standalone as well as in drd (it does show a > few possible races) Effectively, it is very likely that this is a change in 3.9.0 which causes the increase of memory in 'libhb.zsm_init.1 (map_shmem)'. Do you have a (small) reproducer for this problem ? Without that, it looks difficult to track down. I quickly diff-ed helgrind 3.8 and 3.9, but could not find a good candidate for this memory increase. Without a small reproducer, I guess the best way will be to isolate the commit by doing a dichotomic search between the 3.8 and 3.9 release. Philippe |
|
From: Benjamin S. <bsc...@vr...> - 2013-11-27 15:06:11
|
Hmm Unfortunatelly, I moved from Vienna to Zurich now and I don't have access to the machine which showed this behavior. I just tried to reproduce it on my gentoo box but there, it just worked fine. So I think it has likely something to do with dependent libs. After all, backporting an unstable debian package to stable is considered risky... Regards Benjamin On 19.11.2013 21:30, Philippe Waroquiers wrote: > On Tue, 2013-11-19 at 11:20 +0100, Benjamin Schindler wrote: >> I did start with --profile-heap, and it gave me the following (before I >> killed it). The bottom-most entry was growing really fast. The other >> entries seemed to stay more or less contact. Attached for reference is a >> complete run ( I snipped a few outputs because the mailing list doesn't >> like messages over 40k) >> I think the likelyhood of my app being faulty is rather small. It runs >> all fine using memcheck and standalone as well as in drd (it does show a >> few possible races) > Effectively, it is very likely that this is a change in 3.9.0 which > causes the increase of memory in 'libhb.zsm_init.1 (map_shmem)'. > > Do you have a (small) reproducer for this problem ? > Without that, it looks difficult to track down. > > I quickly diff-ed helgrind 3.8 and 3.9, but could not find a > good candidate for this memory increase. > > Without a small reproducer, I guess the best way will be to isolate > the commit by doing a dichotomic search between the 3.8 and 3.9 release. > > Philippe > > |
|
From: Philippe W. <phi...@sk...> - 2013-11-27 22:59:27
|
On Wed, 2013-11-27 at 17:05 +0100, Benjamin Schindler wrote: > Hmm > Unfortunatelly, I moved from Vienna to Zurich now and I don't have > access to the machine which showed this behavior. I just tried to > reproduce it on my gentoo box but there, it just worked fine. So I think > it has likely something to do with dependent libs. After all, > backporting an unstable debian package to stable is considered risky... If by dependent libs, you mean libs that are linked with helgrind, that cannot be the case, as the valgrind tools do not use any lib (even not glibc). So, still a mystery at this moment Philippe > > Regards > Benjamin > > On 19.11.2013 21:30, Philippe Waroquiers wrote: > > On Tue, 2013-11-19 at 11:20 +0100, Benjamin Schindler wrote: > >> I did start with --profile-heap, and it gave me the following (before I > >> killed it). The bottom-most entry was growing really fast. The other > >> entries seemed to stay more or less contact. Attached for reference is a > >> complete run ( I snipped a few outputs because the mailing list doesn't > >> like messages over 40k) > >> I think the likelyhood of my app being faulty is rather small. It runs > >> all fine using memcheck and standalone as well as in drd (it does show a > >> few possible races) > > Effectively, it is very likely that this is a change in 3.9.0 which > > causes the increase of memory in 'libhb.zsm_init.1 (map_shmem)'. > > > > Do you have a (small) reproducer for this problem ? > > Without that, it looks difficult to track down. > > > > I quickly diff-ed helgrind 3.8 and 3.9, but could not find a > > good candidate for this memory increase. > > > > Without a small reproducer, I guess the best way will be to isolate > > the commit by doing a dichotomic search between the 3.8 and 3.9 release. > > > > Philippe > > > > > |
Thanks for helping keep SourceForge clean.
X