Not that this is a major bug, but it makes me wonder why a bug report of this detailed nature (basically doing the debugging for Microsoft engineers) shouldn't be eligible for a bounty, just as exposed security flaws are.
For this bug, it would be a very small or non-existent bounty since this use case affects almost no one, but what if someone found a major bug that was not a security issue, and worked out the cause and fix, as was done in this case? Is that so much less valuable than a security issue?
Bounties exist for security bugs to make it more profitable to report the bug than it is to exploit it, or to sell knowledge of it to those who would. A buy about opening 70 copies of Visual Studio is unlikely to be very profitable to exploit.
In my experience the "bounty" is faster attention to the issue from the devs (no-one likes to spend a lot of extra effort on trying to work on something that is vague, ambiguous or confusing), a better chance that a fix is created quickly and addresses your actual issue, and that it creates a good working relationships with the devs for working with them in the future (builds karma). I like to think of it like keeping up my end of the implicit user/Dev contract :)
That explains it: this is a Schabse bug. He reports bugs like: when you have 4 levels of nested generics with an overriden indexed property going through ComImport, the modopts are incorrectly copied into the method signature, causing a runtime crash in the CLR.
My guess would be that it's an automated build / deploy system that required some addon installed to run, so they had to run `devenv /build` instead of using msbuild. Then they saw this behavior on one of their build machines when something wasn't installed correctly and the process just terminated, after 71 retries...
Source: I was on the visual studio environment team a decade ago, and Rube Goldberg himself could not design a build process that would surprise me, at this point.
One main project (open all day) and small projects throughout the week/month with a machine never shut down? I can see that happening easily at web agencies and the like.
Maybe it happens if you click on a cs or sln file and then press shift and click somewhere else. This might select all sln or cs files and invoke open on all of them, launching many instances at once. Happened to me once with another programm
I don't think you can always expect your users to do the reduction and the debugging for you, they pay you for a bug free product. In this case it's a developer-centric product, so I guess the bug reports are more geeky, but customers are not here to serve the developers.
Agreed but I was confused by the MS response of "Thank you for submitting feedback on Visual Studio and .NET Framework." It seems like the bug is in VS and not .NET. Are they that interweaved these days?
haha, yeah, it's really funny:
"Do not open more than 70 copies of Visual Studio and do not, in any case, choke the artery! What's wrong with you? Choking the artery! Have nothing better to do?"
Would the GetLinesFromFile() memory leak cause performance issues on anything outside of this example?
Its hard to think of a broader usecase.
Though I would suppose its annoying that it eats memory on an older machine. But since it will only be updated for VS 2013 that wont matter until the newer machines get old.
Slight affect if doing long running performance testing?
I run multiple instances of vs.net and don't reboot every week, In my case, I'm cycling through at least 10 instances a day. This bug report is actually interesting (to me).
hehe.... i wonder if they will fix it or simply accuse you of being an idiot several times over before reading the bug report and realising its genuine. :P
what i find much more interesting than this kind of bug though is that there are several possible ways to expose vs bugs with one step after making a new project in the current version...
[+] [-] kohanz|12 years ago|reply
For this bug, it would be a very small or non-existent bounty since this use case affects almost no one, but what if someone found a major bug that was not a security issue, and worked out the cause and fix, as was done in this case? Is that so much less valuable than a security issue?
[+] [-] evan_|12 years ago|reply
[+] [-] jenscow|12 years ago|reply
If you don't report it, then there is slim chance of the bug being fixed.
[+] [-] Serow225|12 years ago|reply
[+] [-] Locke1689|12 years ago|reply
It's like having another tester on the C# team :)
[+] [-] dev360|12 years ago|reply
[+] [-] mnichloo|12 years ago|reply
[+] [-] larsberg|12 years ago|reply
Source: I was on the visual studio environment team a decade ago, and Rube Goldberg himself could not design a build process that would surprise me, at this point.
[+] [-] masklinn|12 years ago|reply
[+] [-] atesti|12 years ago|reply
[+] [-] stackcollision|12 years ago|reply
[+] [-] mburst|12 years ago|reply
[+] [-] Serow225|12 years ago|reply
[+] [-] nraynaud|12 years ago|reply
[+] [-] raxen|12 years ago|reply
[+] [-] dodders|12 years ago|reply
[+] [-] sounds|12 years ago|reply
[+] [-] rob-alarcon|12 years ago|reply
[+] [-] merrua|12 years ago|reply
[+] [-] dferlemann|12 years ago|reply
[+] [-] Cthulhu_|12 years ago|reply
If users want you to fix a bug, they should assume you're an idiot and can't extrapolate what their problems is from the title alone.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] yread|12 years ago|reply
[+] [-] QuadDamaged|12 years ago|reply
[+] [-] jheriko|12 years ago|reply
what i find much more interesting than this kind of bug though is that there are several possible ways to expose vs bugs with one step after making a new project in the current version...
[+] [-] ygra|12 years ago|reply