rjshayes

I was aware of the entire conversation here, sadly.

" the Dining Philosophers chapter from the book which cannot exhibit the leak from that issue because it doesn't define any destructors (let alone define any potentially-panicking destructors, let alone attempt to catch any panics, all of which would be required to observe such a leak)."

Since when can memory leaks only be observed from within the language itself? There are a number of tools that are used on a regular basis to observe memory leaks, with many of them being entirely language agnostic. Additionally, the entire issue brought up in the deleted comment was in relation to threads, an argument of a lack of user-defined destructors wasn't brought into question at all.

    use std::thread;
    use std::sync::{Mutex, Arc};

Glancing briefly over the section of the Rust book in question here, the above two lines appear in the code. In any language, whenever memory is used and then not freed there is a leak. A leak may have nothing to do with a destructor in a language, but could relate to code generation, etc..

As I linked to the other commentator who was assured the individual in question (whose comment is now deleted) was incorrect, Alex Crichton (one of Rust's main contributors) posted a valgrind example yesterday on one of the issues that individual linked (https://github.com/rust-lang/rust/issues/19776).

    ==21255== HEAP SUMMARY:
    ==21255==     in use at exit: 312 bytes in 7 blocks
    ==21255==   total heap usage: 26 allocs, 19 frees, 2,720 bytes allocated
    ==21255== 
    ==21255== LEAK SUMMARY:
    ==21255==    definitely lost: 0 bytes in 0 blocks
    ==21255==    indirectly lost: 0 bytes in 0 blocks
    ==21255==      possibly lost: 0 bytes in 0 blocks
    ==21255==    still reachable: 312 bytes in 7 blocks

The original comment mentioning this issue was lacking so in confrontational qualities that the responses he or she received here and on twitter (how I myself arrived here) were entirely unwarranted.

I'm following up on this since the person you were writing in response to has deleted their comments.

Alex Crichton, one of Rust's top contributors, confirmed that the problem is still present a day ago. He acknowledged this on one of the very issues the original comment was in reference to.

See https://github.com/rust-lang/rust/issues/19776

alexcrichton commented a day ago @huonw did you test on linux? You may have been using the ELF TLS instead of pthread tls. I just built a compiler with --disable-elf-tls and it looks like the leak is still present:

    $ valgrind ./foo 
    ==21255== Memcheck, a memory error detector
    ==21255== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
    ==21255== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
    ==21255== Command: ./foo
    ==21255== 
    Hello World!
    How are you today
    ==21255== 
    ==21255== HEAP SUMMARY:
    ==21255==     in use at exit: 312 bytes in 7 blocks
    ==21255==   total heap usage: 26 allocs, 19 frees, 2,720 bytes allocated
    ==21255== 
    ==21255== LEAK SUMMARY:
    ==21255==    definitely lost: 0 bytes in 0 blocks
    ==21255==    indirectly lost: 0 bytes in 0 blocks
    ==21255==      possibly lost: 0 bytes in 0 blocks
    ==21255==    still reachable: 312 bytes in 7 blocks
    ==21255==         suppressed: 0 bytes in 0 blocks
    ==21255== Rerun with --leak-check=full to see details of leaked memory
    ==21255== 
    ==21255== For counts of detected and suppressed errors, rerun with: -v
    ==21255== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

It's exceptionally too bad the person who originally pointed this out in the comments here felt the need to delete their comment.

Yeah, my remarks now lack their context with the deletions/edits. I haven't checked hacker news since I edited by own reply, but I can only imagine they were edited by the time you saw them, given the time stamps.

I experienced this problem too. It didn't seem to exist on ubuntu or fedora, which were the two OS distributions I was developing for. Windows and Mac were the only platforms displaying the issue when I'd tested it.

EDIT:

Awh, that's sad... s/he deleted the comment....

The issue the individual linked was https://github.com/rust-lang/rust/issues/14875, an open issue the contributors acknowledged as existing since June 13, 2014.

Come on everyone, this is HN -- let's not pick apart valid concerns people express that they have experienced personally, especially when those concerns are acknowledged as an existing issue by the repository's main contributors in the linked issue...

Being rude is not supportive of an open dialogue and comments intended to efface the author of the original comment from the conversation are just despicable. When you alienate someone, they leave, and that's exactly what happened here. Hopefully whoever that was didn't just up and delete their HN account.

Interesting -- this study referenced another which focused on the effects of color on individuals with and without ADHD (http://www.ncbi.nlm.nih.gov/pubmed/21854630/). The game was designed for and taken from study for use in this one -- the results were nearly the same. The other study came back with similar results due to the structure of the game favoring ADHD individuals for level 1 and favoring individuals without ADHD for level 2.

The results in the original study were nearly the same proportionally and the game was found to favor the performance of an individual with ADHD.

The linked study, in fact, goes on to misrepresent the study it references in stating it was conducted "to quantify the performance of people with ADHD characteristics," when in fact the study stated it was conducted to describe "the development and the testing of a virtual environment that is capable to quantify the influence of red-green versus blue-yellow colour stimuli on the performance of people."

The referenced study concluded: "The game proved to be a user-friendly tool capable to detect and quantify the influence of color on the performance of people executing tasks that require attention and showed to be attractive for people with ADHD"