Re^8: memory leaks with threads (race of 1)

Is there a possibility that this is somehow related to my dual core processor ?
My gut says no, but I don't have a dual core to with which to verify my gut one way or another.

I've seen that if one has a single core, then one can avoid many race conditions because only one thread ever runs at a time. I've seen several cases of code that works great "forever" on a single-core system but gets confused when run on a multi-processor or multi-core system. Losing track of resources and thus leaking memory is certainly a possible outcome of such race conditions.

It isn't terribly hard to test such either, just bind the process to a single processor / core and see if the memory leak goes away.

The leak being that dramatic vs. not at all is a rather stark difference to explain with a race condition, however, so a configuration difference seems more likely.

- tye

Comment on Re^8: memory leaks with threads (race of 1)

Replies are listed 'Best First'.
Re^9: memory leaks with threads (race of 1) by BrowserUk (Patriarch) on Jul 09, 2007 at 21:41 UTC
I've seen that if one has a single core, then one can avoid many race conditions because only one thread ever runs at a time. I completely agree that moving from single-cpu multi-threading to multi-cpu multi-threading often causes latent bugs to become glaringly obvious. Though I think this is more apparent with compiled-to-native code than ithreads, simply because you do not get the 'atomicity' of native machine instructions with Perl op-codes. The basis of my gut feel is the lack of any great program level memory allocations, and the inherent simplicity of the OPs demo code. Given the latest info from the OP, that creating & destroying threads consisting soley of `sub{ 1; }` causes fast, massive leaks on his system, I have to suspect that the leak is inherent in the implementation of the creation and freeing of interpreter structures on his platform. The big difference between nix and Win32 in this regard is that Win32 returns memory segments allocated by the creation of threads to the OS. So, even if during the creation of the internal structures required to create a new interpreter, there is some circular reference or other reference counting error, that on the nix system means that some part of it does not get free'd back to the memory pool for re-use, on the win32 system, the entire kit'n'kaboodle gets given back to the OS, so reference counting errors do not persist. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l]
Re^10: memory leaks with threads (race of 1) by misc (Friar) on Jul 10, 2007 at 12:21 UTC
I disabled the second core of my system for some testing, but there are still leaks. I just wrote a new script, which has the lowest memory growth I was able to produce. What really surprises me is the erratic growth of resident memory consumption.(the second cell) I just submitted a bugreport. `use threads; while( 1 ) { my $t = threads->create( sub{ undef @_;undef;} ); my $f = $t->join(); undef $t; undef $f; threads->yield(); select undef,undef,undef,0.2; }` [download] micha@laptop /proc $ perl -e 'while(1){system("cat $ARGV[0]/statm");sl +eep 1;}' 24857 20376 11566 394 289 0 19667 0 20376 11566 394 289 0 19667 0 20376 11566 394 289 0 19667 0 20376 11566 394 289 0 19667 0 53160 11582 394 289 0 52451 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 77748 11596 394 289 0 77039 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 20376 11568 394 289 0 19667 0 133071 11623 394 289 0 132362 0 21161 12359 394 289 0 20452 0 21161 12359 394 289 0 20452 0 21161 12359 394 289 0 20452 0 21161 12359 394 289 0 20452 0 21161 12359 394 289 0 20452 0 21150 12354 394 289 0 20441 0 21150 12354 394 289 0 20441 0 21150 12354 394 289 0 20441 0 21150 12354 394 289 0 20441 0 21150 12354 394 289 0 20441 0 21150 12354 394 289 0 20441 0 21150 12354 394 289 0 20441 0 21150 12354 394 289 0 20441 0 21150 12354 394 289 0 20441 0 21150 12354 394 289 0 20441 0 45738 12366 394 289 0 45029 0 [download]	[reply] [d/l] [select]