I think what you're running into is the shallow knowledge of people on forums/mailing lists. With a few exceptions, the people who actually know the most about the Linux kernel, glibc internals, etc. do not frequently post on StackOverflow. They're too busy, you know, working on the kernel and shit.

So you get Joe Chucklefuck, he installed Ubuntu three months ago and posted on the Ubuntu forums about how he has no free RAM and Linux sucks. Someone showed him this page, and now when he sees your question about why malloc isn't working right, he thinks, "Aha! A memory problem! I shall post that linux ate my ram site!" Meanwhile, Ulrich Drepper isn't reading the list, even though he could tell you that the version of glibc you're using has a known bug in malloc. (He'll also tell you that you're stupid, but that's just because he's an asshole)

Exactly. But I believe that developers have their hands full solving real problems, no need to ask them play level 1 support too.

So when I find an issue that I can't be sure if it isn't my own fault, or I don't know the root cause of it, I try to gather some information before heading to the bugzilla. Memory issues are the only thing it is absolutely impossible to gather any useful information. Your only option is to learn C and debugging tools.

A suspected memory-leak is definitely the sort of thing that you should report to the authors/maintainers. Even if you think it is triggered by something that you are doing wrong, their program should not respond to that incorrect input by leaking memory.

Places like stackoverflow and IRC support channels are really only useful if the answer you are looking for can probably be found in some form of documentation somewhere. For things like suspected bugs or issues with specific implementation, it is best to go to the source (either the actual source, or the responsible devs (which almost always means going to a mailing list).

Some particular projects are infamously dismissive specifically of memory leaks, really no matter how much detail you put into your report (Mozilla, I am looking squarely at you), but those should be the minority. Typically if you see run-away memory usage, and are able to provide enough details about what you are seeing, the developers should be receptive. That's been my experience anyway.

The gap between 'Joe Chucklefuck' and the lead developer for glibc is wide enough to fit a whole lot of people who can triage a bug without necessarily being skilled (or interested) enough to submit patches.

I think describing the phenomenon as 'noise' is reasonable. You find a moderate number of answers with a reasonable degree of certainty as to their accuracy and a large number of answers that are just whatever came to mind first (these aren't necessarily provided by completely distinct groups of people). The result is a lot of almost-but-not-quite-related nonsense that drowns out the answers with any relevant content.

This probably isn't purely a problem of numbers, either. Even attempting to be helpful takes a certain amount of effort that naturally limits the impact of the former group at any particular instant. It's also easy (as evidenced by this very article) to take helpful information and render it non-helpful by repeating it without context.

Just give more information right off the bat. Don't say "XYZ is chewing up lots of RAM"; the best case scenario if you say that is they have to respond back asking for more information. Give that information to them in the first place "XYZ starts at XXXXMB shared and XXMB resident. Over five minutes it steadily climbs to XXXXMB resident. Shared remains constant at XXXMB."

Doing this, I can't say I've ever been brushed off using this page.

Doesn't work most of the time. I do but everyone ignores every word from your question except the “chewing RAM” part.

So leave out the chewing RAM part. Use vocabulary and explain it in a way that will alienate newbies but still be clear to experts.