“Artery chokes after 70 copies of Visual Studio”

https://connect.microsoft.com/VisualStudio/feedback/details/812643/artery-chokes-after-70-copies-of-visual-studio

by distilled • 12 years ago

155 93 12 years ago

connect.microsoft.com

mnichloo2• 12 years ago

What I want to know is this, what hellish workflow led to the discovery of this bug?

larsberg• 12 years ago

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.

mnichloo2• 12 years ago

That makes sense... I was imagining that there was some build process that froze VS 99% of the time and some poor developer was sitting at his desk silently crying into his coffee trying over and over to get his project to build so that he can go home for the weekend.

raverbashing• 12 years ago

One of my personal corollaries: all build systems suck

Some suck more, some less

And most of the time it's overcomplicated.

masklinn2• 12 years ago

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.

prawks• 12 years ago

Any more than 5 instances of VS running on one machine gives me pause. I can't imagine going into double-digits, let alone 50+.

I can see 70 files or projects open, but not in VS.

EDIT: Ah, seems I skipped the part where the additional instances are closed.

atesti• 12 years ago

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

yread2• 12 years ago

Why is this interesting?

QuadDamaged2• 12 years ago

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).

yread2• 12 years ago

Yes, but do you shut them down ungracefully?

Do you expect to read interesting bug reports on HN?

Serow2253• 12 years ago

Now that's how bug reports should be written!

raxen• 12 years ago

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?

ygra4• 12 years ago

The bug report frontend is for both. The Thank you is just an automated response that it was seen. Generally, lots of the official replies on Connect seem to be either text building blocks or canned responses. Not terribly surprising, either, I might add.

petilon• 12 years ago

The Developer Division at Microsoft is responsible for both and this is their boilerplate response.

Zenst• 12 years ago

in 1998 I was working with VS and had a bug with OCX and was told that the bug was due to VS not working with the current IE version as well in places and was fixed in the new release of VS due out.

So I'd say very interweaved if history has its design legacy mantra.

nraynaud• 12 years ago

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.

Serow2253• 12 years ago

Agree, I should have made that clear in my comment. in fact I've found that a) the product devs should be able to find the cause much faster than you can, b) it's more effective for you to spend your time developing a repro script/code/etc, because unlike describing a bug, this is unambiguous and the devs can run it very quickly to verify tat the issue can be reproduced on their end.

patio11• 12 years ago

they pay you for a bug free product

A nitpick but it's really important that HNers understand it: users do not, in fact, pay for bug free products. They pay for products which achieve the benefits promised to them, bugs and all. If they wanted to buy bug-free products, they'd a) make decisions about software adoption driven primarily by externally visible indicia of bug-freeness and b) pay prices similar to that paid by e.g. the Space Shuttle or flight control systems. Users do neither of these things for most software.

jheriko• 12 years ago

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...

ygra4• 12 years ago

The issue has already been closed as Fixed.

bananas• 12 years ago

Based on my experience with connect that doesn't mean it was fixed in the product version you reported it against or any future version.

stackcollision• 12 years ago

Is there a repository somewhere of really great bug reports like this? Something along the lines of "commits from last night".

mburst• 12 years ago

Not quite the same but there is http://www.commitlogsfromlastnight.com/

thejosh• 12 years ago

Hilarious, does this search for common swearwords?

dferlemann• 12 years ago

Instead, I had to hunt down the person who wrote bugs with only titles and severity level critical....

Cthulhu_• 12 years ago

"unable to reproduce / not enough information" -> close.

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.

jerf• 12 years ago

"It depends". If I'm getting this out of a user support case, I can't really do that. The support person in question might get an earful... actually, tense correction, support people have gotten earfuls from me on the virtues of filing the moral equivalent of "it doesn't work"... but for the customer's sake I can't just smash the bug report closed and smile smugly.

kohanz• 12 years ago

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?

jenscow• 12 years ago

The bounty "prize" is you will eventually have a working product to use.

If you don't report it, then there is slim chance of the bug being fixed.

rbanffy3• 12 years ago

The bounty "prize" is you will eventually have a working product to use.

While an IDE running under Windows is hardly what I would like to work with, a bug that manifests itself only on such extreme circumstances cannot be called a showstopper.

I would worry more about other instances where this Peek() method is being misused like this, perhaps on other situations that happen more frequently than Visual Studio 2013 starts.

As a prize, a Microsoft T-Shirt, a gift card and some public recognition wouldn't hurt. The person who reported this bug did a great job of pinpointing its cause.

evan_3• 12 years ago

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.

droopybuns3• 12 years ago

Repectfully, you are incorrect that bounties exist to make it more profitable to disclose than to sell.

Corporate bug bounties will never be able to compete with the budgets of nation states.

They are basically a way of paying respect for a moral approach to a discovery that takes great skill.

Serow2253• 12 years ago

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 :)

dodders• 12 years ago

From the workarounds tab: "Do not open more than 70 copies of Visual Studio..."

rob-alarcon• 12 years ago

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?"

luke-stanley• 12 years ago

They might be wanting to run automated tests to find some other problem, and find after 70 tests, they get an error. So it's sensible to want to fix it.

sounds• 12 years ago

But only 2 are ever open at once.

Locke1689• 12 years ago

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.

It's like having another tester on the C# team :)

dev360• 12 years ago

Or like having an aspbergers stalker?

merrua3• 12 years ago

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?

“Artery chokes after 70 copies of Visual Studio”

Related Stories