17:23 <fche> baotiao, dunno about 'assign', but you can say if (tid() != 808) next; to filter events only to tid=808

17:24 <baotiao> fche: thank you. I have got the answer, thank you all the way

17:24 <fche> righto

17:29 <baotiao> fche: I have meet a memory leak problem, I have try many tools. However, they don't solve my probelm. So I try to use systemtap, I have write a probe in every malloc return and the entry of free, to calculate the address that we have malloc and the address that we have freed. Then if we see there is a address that is alloc for a long time that doesn't free by any one, we think this address is leak. Do you think this is a good idea?

17:29 <baotiao> https://gist.github.com/baotiao/32b430405f98af0e39478da637310f35

17:30 <fche> we've done stuff like that

17:30 <fche> at larger scale valgrind is probably better

17:32 <baotiao> fche: since this is a on-line product, so we can't use valgrind.

17:33 <baotiao> we have use valgrind to in our test environment, but it dosen't has memory leak.

17:33 <baotiao> can you show me your probe?

17:34 <fche> nothing in recent recollection, I'm afraid

17:34 <fche> ISTR finding it difficult to track every kind of memory allocation/free at small granularity (vs. mmap)

17:35 <fche> and the number of objects that needed concurrent tracking could be quite large (thus occupy large amounts of stap/kernel memory)

17:38 <baotiao> so you think use systemtap the trace the memory leak problem is not a good idea? systemtap itself will consume lots of memory?

17:40 <fche> it'd be in kernel-space, so not directly comparable

17:40 <fche> and it wouldn't leak, just be a one-time allocation

17:40 <fche> so yeah, worth a shot