Chrome bug



  • Just wanted to share a Chrome bug that took me HOURS to track down today: http://code.google.com/p/chromium/issues/detail?id=69297

    I figured I'd post it here, since I used the DailyWTF homepage as the background for the bug test-case, hah.



  • That's pretty bad.

    Fortunately I never use eval strings in timers.

    I imagine setInterval has the same issue?



  • @dhromed said:

    That's pretty bad.

    Fortunately I never use eval strings in timers.

    I imagine setInterval has the same issue?

    Good question, I didn't check setInterval but I imagine it does.

    Any clues as to what could *cause* a bug like this? I've been thinking about it for ages, and I'm totally stumped.



  • With the sort-of-compiled javascript engine like Webkit's , maybe strings fed to eval are behaving funny.

    It's a wild guess, probably wrong, and I really can't say anything else about it.

     



  • @dhromed said:

    With the sort-of-compiled javascript engine like Webkit's , maybe strings fed to eval are behaving funny.

    It's a wild guess, probably wrong, and I really can't say anything else about it.

     

    I thought of something in the shower, where I do all my best thinking. Maybe the int returned by setInterval is some kind of hashed version of the interval's eval string. Then as a result of some "optimization", Chrome doesn't actually run clearTimeout until the function ends... does that make sense? No not really.

    I'm sure whatever it was, someone was trying to "optimize" the browser without bothering to check if their optimization broke anything or not.



  • @blakeyrat said:

    I thought of something in the shower, where I do all my best thinking. Maybe the int returned by setInterval is some kind of hashed version of the interval's eval string. Then as a result of some "optimization", Chrome doesn't actually run clearTimeout until the function ends... does that make sense? No not really.

    I'm sure whatever it was, someone was trying to "optimize" the browser without bothering to check if their optimization broke anything or not.

     

    Just for curiosity, did you take a look at the actual int returned by setTimeout? I haven't Chrome installed right now, so I can't check, but I imagine that in IE and FF, those were basically handles that started at 1 and incremented with each setTimeout call. Definitely not a hash. Have you checked if that's the case with Chrome, too?

    But in general that doesn't sound that absurd to me. Whatever the internals of setTimeout on Chrome may be, I think it's pretty much certain they will do some kind of caching on the functions generated by the eval strings. They probably use the strings themselves as some kind of identifyer for that cache. 



  • @PSWorx said:

    Just for curiosity, did you take a look at the actual int returned by setTimeout?

    No, although I guess I could. It's kind of an implementation detail you're not really supposed to look at. (Even though you can).

    @PSWorx said:

    But in general that doesn't sound that absurd to me. Whatever the internals of setTimeout on Chrome may be, I think it's pretty much certain they will do some kind of caching on the functions generated by the eval strings. They probably use the strings themselves as some kind of identifyer for that cache.

    Well, what's absurd is how all these modern (meaning, not-IE) browsers constantly brag about how closely they follow web standards, and they support CSS3 and HTML5 and fancy-schmancy technology 11.0, etc... and then you find a glaringly obvious DOM bug right there. DOM1, even. (I've found similar basic bugs in Firefox.)

    Sure, it's great to get fancy-schmancy technologies, but could we maybe get the *basics* right first guys? It doesn't matter how pretty the car looks if you forgot to put in an alternator.



  • @blakeyrat said:

    No, although I guess I could. It's kind of an implementation detail you're not really supposed to look at. (Even though you can).
     

    I know it's an implentation detail, that's why I said "out of curiosity". I think it can be quite useful for better understanding to know about implementation details, even if you obviously shouldn't rely on them in any way.

    @blakeyrat said:

    Well, what's absurd is how all these modern (meaning, not-IE) browsers constantly brag about how closely they follow web standards, and they support CSS3 and HTML5 and fancy-schmancy technology 11.0, etc... and then you find a glaringly obvious DOM bug right there. DOM1, even. (I've found similar basic bugs in Firefox.)

    Sure, it's great to get fancy-schmancy technologies, but could we maybe get the *basics* right first guys? It doesn't matter how pretty the car looks if you forgot to put in an alternator.

     

    Well, again, there is the spec and there are the implementation details. If some browser vendor manages to find some awesome optimisation that implements the spec in some non-intuitive but efficient way, then go ahead. But I agree, optimisations like that should be tested enough to be sure that you're still actually complying to the spec.

    (Also, typo in the previous post:)

    @PSWorx said:

    ...so I can't check, but I imagine remember that in IE and FF

    (Incidentally, both IE and FF keep counting up even after timeouts have been executed or cancelled instead of filling the "gaps". So apparently they don't do a full cleanup either except very much later.)

     


  • Garbage Person

    @blakeyrat said:

    It doesn't matter how pretty the car looks if you forgot to put in an alternator.
    Stupid unrelated story time.

    At a race last year, my team ended up setting up shop next to some guys who were having all kinds of trouble with the absolute basics.

     

    The normal schedule for one of these races involves showing up on Thursday, parking your support vehicles/RVs/strippermobiles and then either leaving to go enjoy some hookers and blow at the hotel, setting up the camp/shop/whatever-it-is, finish building the car, whatever floats your boat, because nothing actually happens until Friday. Generally, everybody who's going to arrive on time has done so by 5AM Friday morning. This particular race, however, had moved entry back to Friday - coincident with such important things as testing and inspection.Whatever. There was a huge traffic jam outside the gates at 5AM, and the nearest 3 Walmarts had massive RV and truck parks in their parking lots Thursday night. No big deal.

    Meaningful shit starts happening at noon - when tech inspection starts. By 11, we've set up our encampment and are making light of our good fortune of not having any direct neighbors (we're parked up against a slope, and people have been avoiding the space next to us since it's on an intersection, has no direct power outlets, and is comparatively small). At that very moment, a Dodge Colt painted like the General Lee gets pulled into that space. One guy gets out, unloads the car, and the guy driving the SUV vanishes into the sunset, never to be seen again.

     Naturally, we come over and make nice with our new neighbor. He has no tools, no shelter, no food, no equipment, and no teammates to be seen. He seems VERY worried. As it turns out, none of his teammates are answering their phones. He doesn't even know for sure if his car is going to pass tech. We give him a quick, unofficial inspection - there are 3 or 4 borderline items, including a cage design that protects the unoccupied passenger seat against collapse better than it protects the occupied driver's side.

    Tech time starts, we rush off to be to the head of the line (our own car is brand new and has some questionable details of its own), while he opts to try to wait out his teammates. When we return he's still there - he's gotten in touch with one of his partners, and they thought they didn't have to show up until Saturday. We send him off to tech - the line is now a solid 3 hours long. Later in the afternoon, he returns - he failed tech on the cage. His welder isn't even on his way yet. We direct him to our cage builder (who has his own team and is parked nearby), who charges him a hilariously extortionate last-minute-fix rate (along with literally two dozen other teams). His fix takes well into the evening - he'll have to tech at 7AM before the event starts at 9.

    The next morning, he has a fixed rollcage, but still no team. We help him push the car through tech, since something seems to be wrong with the starter now. His team finally materializes 15 minutes before start. We use our car to bump-start theirs, and it's off to the track.... Except when he stalls it in front of the cute girl checking to make sure his seatbelts are tight and needs a fresh bump-start.

     

    It quickly becomes evident that something is wrong with their car's charging system - because they get towed in and have a flat battery. We let them use our spare and put the first on our charger (because even when everyone showed up, they didn't bring anything with them except personal safety gear). About an hour later, it's back - OUR battery is dead this time.  The alternator is clearly not charging as fast as draw-off. Shit. So they come up with perhaps the worst 'fix' in all of history for a bad alternator - they scrounge up all the batteries and chargers they can, and just rotate through them.

    A much, much better option would be to ask around for a spare alternator - any alternator would do, really. Perhaps that team that just blew up their fancy Northstar V8 and is putting in their spare motor doesn't need theirs anymore?

     

     

    The cycle of failure doesn't end there, though. On day 2, they've finally managed to ruin most of the batteries, and are stuck parked for half the day while they cycle a mere 2 proper Deep-Cycle batteries through the charger and car. At the end of the day, they can't get ahold of the guy with the SUV to come pick up the car. He seems to have disappeared. So they do the natural thing: Abandon the car where it sits.

     



  • No response yet on my bug... I bet Google works like an open source company, and it'll stay open for three years until it's closed for being "too old".



  • @blakeyrat said:

    No response yet on my bug... I bet Google works like an open source company, and it'll stay open for three years until it's closed for being "too old".
    Several Chrome bugs that were originally submitted in early 2009 have just been fixed, even though they were marked as "security" issues.  I would have thought a big company like Google would do better than that.  But, then again,  how much money is Chrome bringing in for them?  Is Chrome really that important to them or just a side project to keep some programmers amused?  On a related note,  within the last couple of months Firefox has fixed bugs that were originally submitted 8 and 10 years ago. 10 Years!!  Better late than never, I guess.

    In all fairness, I don't know that this has anything to do with being "open source".  How many non-open source applications have a publicly viewable bug tracking database where you can see every detail about every bug that was ever submitted?  If you find a bug in Internet Explorer is it even possible to know how long it takes them to fix it? (I don't know).



  • @El_Heffe said:

    On a related note,  within the last couple of months Firefox has fixed bugs that were originally submitted 8 and 10 years ago. 10 Years!!  Better late than never, I guess.

    Yeah, but still not the bug where a disabled control prevents event bubbling, making it impossible to capture a mouse event on a disabled (for example) radio button. Which I commented on in Firefox's bug database in... 2004? I think? That one's even worse than this Chrome bug, or the FF bug I submitted about removeEventHandler, because that bug is impossible to work around.

    @El_Heffe said:

    In all fairness, I don't know that this has anything to do with being "open source".  How many non-open source applications have a publicly viewable bug tracking database where you can see every detail about every bug that was ever submitted?

    When I did QA for Microsoft, we would never close a bug, no matter how old, without assuring that the bug no longer existed. I can't speak for other companies. Nor can I speak for the IE team. (I worked in the Xbox TNT group.) I can say that bugs I report on Microsoft Connect at least get read.

    You are right; having a publicly-visible bug tracker is definitely a good thing... closing un-triaged bugs is definitely a bad thing.

    But what really bothers me is:

    1) Groups that expend a lot of lip-service on how good they are at complying with standard, who *ignore* bugs related to standards-compliance for years at a time. (Firefox and it's disabled controls bug, for example. Oddly, the removeEventHandler bug was fixed in a timely manner and they gave me a t-shirt for reporting it. Which makes me think that the solution might just be to re-submit the same disabled control bug with a new number...) Time will tell if Chrome's in this group or not.

    2) Groups that ask people to participate by entering bugs, then *never* read their bug trackers. The absolute worst here is a not-really-open-source project, Slashdot... a few year ago I was bitching to a Slashdot mod about how buggy their site was after the new redesign. He told me they only fix things on the bug tracker. Fair enough. I put in about 15 bugs, none of which has been resolved, most of which haven't even been triaged. If you're not going to look at your fucking bug tracker, don't waste our time telling us to put the bugs in! Just admit you don't give a shit, and we can all move on with our lives.

    (Number 2 is by far my most common experience with open source bugs. To the extent I don't even bother participating in most open source projects anymore, just the ones I use daily at work.)



  • First bug isn't read.

    So here's a new one: Chrome notifications interrupt full-screen applications

    Notice how with each ignored bug, the snark level increases. With my ignored Slashdot bugs, the snark was dangerously high, but this one only has a small amount of snark.



  • Is it allowed to pass a function instead of a string to setInterval? It would make sense to do so.



  • @zzo38 said:

    Is it allowed to pass a function instead of a string to setInterval? It would make sense to do so.

    Yeah. But what I am doing in that code sample is perfectly cromulent. If you look, someone at Chrome has finally triaged the bug.



  •  i rarely used Chrome for browsing, always FF because FF has some Addon that i always need inmy entire browsing. What it is? FireFox Reminder because i am forgetful. (is my word correct?)



  • @juliaestelleo said:

     i rarely used Chrome for browsing, always FF because FF has some Addon that i always need inmy entire browsing. What it is? FireFox Reminder because i am forgetful. (is my word correct?)

    No it is Final Fantasy, learn your acronyms


Log in to reply