On Freitag, 24. Februar 2017 01:32:24 CET Tim Biedert wrote: > Below you find the gdb thread infos for the single idling process (recall: > all processes have 100% but one, which idles). As you can see, there a > quite a few threads stuck in some kind of TCMalloc spin lock. > > Most backtraces in those threads contain a free(), but there are also > allocs() (see thread 68 and 79 backtraces at end for examples). > > In fact, in the phase of my program where the deadlock happens, all threads > do perform many dynamic allocations and freeings (let’s say thousands). I > guess I could implement some manual pooling, but I thought TCMalloc would > manage everything fast enough and transparently in the background. > > Have you ever encountered something like this?
I have not encountered this error so far and this looks indeed like a deadlock inside of tcmalloc. I myself use jemalloc most of the time and didn't encounter this situation. Does changing the malloc implementation to system or jemalloc help here? > > I am using gperftools-2.5 btw. > > Thanks! > Tim _______________________________________________ hpx-users mailing list hpx-users@stellar.cct.lsu.edu https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
