Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Youtube Bug Google

YouTube Video Causes Pixel Phones To Instantly Reboot (arstechnica.com) 55

Posted by BeauHD from the check-this-out dept.
An anonymous reader writes quotes a report from Ars Technica: Did you ever see that movie The Ring? People who watched a cursed, creepy video would all mysteriously die in seven days. Somehow Google seems to have re-created the tech version of that, where the creepy video is this clip of the 1979 movie Alien, and the thing that dies after watching it is a Google Pixel phone. As noted by the user 'OGPixel5" on the Google Pixel subreddit, watching this specific clip on a Google Pixel 6, 6a, or Pixel 7 will cause the phone to instantly reboot. Something about the clip is disagreeable to the phone, and it hard-crashes before it can even load a frame. Some users in the thread say cell service wouldn't work after the reboot, requiring another reboot to get it back up and running.

The leading theory floating around is that something about the format of the video (it's 4K HDR) is causing the phone to crash. It wouldn't be the first time something like this happened to an Android phone. In 2020, there was a cursed wallpaper that would crash a phone when set as the background due to a color space bug. The affected phones all use Google's Exynos-derived Tensor SoC, so don't expect non-Google phones to be affected by this. Samsung Exynos phones would be the next most-likely candidates, but we haven't seen any reports of that. According to CNET, the issue has been addressed and a full fix will be deployed in March.
This discussion has been archived. No new comments can be posted.

YouTube Video Causes Pixel Phones To Instantly Reboot More

YouTube Video Causes Pixel Phones To Instantly Reboot

Comments Filter:

  • Perhaps some payload is triggering a backdoor. This one set of frames likely has a super uncommon set of bytes that match some payload meant to trigger a backdoor.

    • Re:Some payload triggers a backdoor (Score:4, Interesting)

      by Rockoon ( 1252108 ) on Tuesday February 28, 2023 @08:59PM (#63331663)
      nah this is only evidence of a possible payload vector - youtube re-encodes everything - and by random chance the re-encode is causing .. something

      probably the encoder is choosing an encoding strategy that leads to a low level state-breaking bug when this device tries to decode it using its specialized driver/hardware combo - the reboot is likely last resort recovery

  • I can relate (Score:5, Funny)

    by Dictator For Life ( 8829 ) on Tuesday February 28, 2023 @07:15PM (#63331529) Homepage
    When I was 13 and watching Alien in a movie theater in 1979, in the front row, I too rebooted. Repeatedly.

  • something like this happen in an car
    https://entertainment.slashdot... [slashdot.org]

  • A buffer overflow in the compression hw probably would crash it.

    • Not too surprising. I've seen spontaneous reboots on my Pixed caused by the translate app when viewing text through the camera. I just figured it was some low-level buffer overflow or crash deep in a video codec somewhere. Pretty rare and hard to repro though.

      At least this gives a nice easily-reproducable repro step for the engineers, instead of a random rare crash reported by a random user. Sounded like they didn't have much trouble fixing it.

    • Codecs and compression algorithms are so complicated that they are easy fodder for buffer overflows. The requirements of speed combined with the complex math make it difficult to verify that you won't go off the end of your buffer.

      • And we're all good mathematicians who put assert()s in our code instead of being good engineers who put goto fail and don't exit out of a process that ends up crashing the phone.

        • Yeah, if you want to avoid buffer overflows, it's easy, all you have to do is do a check every time you increase the pointer, or every time you do a read or a write or something like that. Add asserts(), whatever.

          But if you do that, it's going to slow down the decompressor, sometimes significantly (depending on what technique you use).

          On the other hand, if you're just trying to not overflow strings, you can do that relatively simply and efficiently with a well-crafted and tested set of functions, even w

          • Yeah, if you want to avoid buffer overflows, it's easy, all you have to do is do a check every time you increase the pointer, or every time you do a read or a write or something like that.

            No, what you do is you make the buffer big enough.

      • Codecs and compression algorithms are so complicated that they are easy fodder for buffer overflows. The requirements of speed combined with the complex math make it difficult to verify that you won't go off the end of your buffer.

        I don't think this is a buffer overflow.

        It sounds more like the Pentium divide bug - a certain combination of input numbers causes the math hardware to freak out.

        • That's kind of hilarious. I think Intel actually uses formal verification of their chips to avoid that kind of thing, I guess that's what Google gets for using an in-house processor.
    • Sounds like someone at Google hasn't been keeping up their fuzz testing...

  • My circa 2017 Thinkpad plays it (Score:4, Interesting)

    by Powercntrl ( 458442 ) on Tuesday February 28, 2023 @07:32PM (#63331559) Homepage

    But it looks like utter shite. The only device I own which can properly display HDR without it looking like a too dark mess is my iPhone 13 Mini, and let's just say I don't really enjoy watching video much on such a tiny screen. I certainly understand the point behind HDR (though I'm personally not a fan), but much like the situation with bad downmixing algorithms for multichannel audio, trying to watch HDR content on a non-HDR or "fake HDR" (most budget TVs, basically) device usually leads to a worse experience than if the content had just been mastered for SDR to begin with.

    While some of the comments on YouTube seem to suggest that the HDR format is the problem (and given my feelings about HDR I'd love to scapegoat it), but I'd guess the real issue is probably something more mundane, like some corruption in the video encoding itself. That used to happen to a friend of mine back in the day when he'd encode his ripped DVDs to "DivX ;-)" on a computer with a crappy PCChips motherboard - the resulting files would sometimes crash Windows Media Player.

    • No problem playing it on my iPhone 8.

      • No problem playing it on my iPhone 8.

        If only the summary had a line saying "The affected phones all use Google's Exynos-derived Tensor SoC, so don't expect non-Google phones to be affected by this."

        It would have saved you all some time if they'd said something like that, but noooooo.

  • On brave browser. Still can't GPS my way out of a paper bag, play Bluetooth audio on a newer car stereo, or fingerprint unlock my phone, but the video plays fine.

  • Google Pixel 6 Affected Earlier Than This (Score:5, Insightful)

    by JakFrost ( 139885 ) on Tuesday February 28, 2023 @08:47PM (#63331657)

    I having crashing problems on my Google Pixel 6. Phone while watching YouTube videos with Firefox mobile browser.

    It would cause the video to stop playing the Firefox browser to become unresponsive and after a few minutes the phone would become unresponsive and either restart the GUI or reboot the entire phone.

    I submitted full crash dumps from Firefox through their feedback mechanism and heard nothing back. I even submitted a full developer crash dump for the Android OS and didn't hear anything back either .

    I'm just glad that somebody found a video that makes this happen consistently and that they are actually going to investigate this. Because obviously they don't listen to feedback requests on crashing apps or the Android OS. Since they don't reply.

    • Firefox and duckduckgo seem to crash constantly on all kinds of videos on my phone. Brave and chrome work fine. Brave filters all the ads and junk but blocks videos on many websites that use wildvines DRM, so if I really want to watch a CNN video or whatever, I open that one video in chrome.

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      I having crashing problems on my Google Pixel 6. Phone while watching YouTube videos with Firefox mobile browser.

      It would cause the video to stop playing the Firefox browser to become unresponsive and after a few minutes the phone would become unresponsive and either restart the GUI or reboot the entire phone.

      I submitted full crash dumps from Firefox through their feedback mechanism and heard nothing back. I even submitted a full developer crash dump for the Android OS and didn't hear anything back either .

      • What happens here is the phone instantly crashes - if you open the video in the YouTube app, before you see a frame of video (after the ads, of course), the phone instantly reboots.

        Doesn't work on my Pixel 7 Pro. Video plays just fine. I'm running the public release build, not an internal pre-release. I wonder what the difference is.

  • Are they fixing the phone or the video?

  • tries to change display mode or something
    asks for a configuration that is badly formed
    some function returns a value that is unexpected
    or some watchdog timer triggers
    and the sorry excuse for an operating system does the only thing it knows to get back to a known state: reboot

    it's the all-time classic "shit software"

    it is amazing how we're almost half a frickin' century into this and we _still_ do not have even barely decent system/process and interprocess isolation.

    • tries to change display mode or something
      asks for a configuration that is badly formed
      some function returns a value that is unexpected
      or some watchdog timer triggers
      and the sorry excuse for an operating system does the only thing it knows to get back to a known state: reboot

      it's the all-time classic "shit software"

      It only affects a certain chipset so I'm saying "nope".

      More likely that chipset has something similar to the Pentium divide bug. A certain set of input numbers makes it give wrong answers.

      • Re: (Score:2)

        by gTsiros ( 205624 )

        not sure how that does not fall under "some function returns a value that is unexpected" but ok

  • "Did you turn it off and on and again?" "Yes" "Excellent. Now, do it just one time." "Hey, it fixed it!" "Okay, bye-bye, now"
  • I have had a similar experience with my Sony Bravia TV with Android when playing 4K tv-shows. It happend during a few episodes of Willow on Disney+ and Foundation on Apple TV. I have not tried it yet with this clip from Aliens.
  • Could it help to have software designed for testing media and data files for potential parsing and processing issues before publishing? This could be viewed as debugging data as opposed to debugging software. Data which is "bug-free" and perhaps also in a file format designed to allow faster code, could speed up computers indirectly. The speed up would be due the processing algorithms not needing to continually check data for errors. There would need to be some flexibility in the data formats to allow for

  • I can't prove it, obviously, but I have to state to the group of brains here that I have a "smart, Google, whatever" TV "manufactured" by Sony. It's running Android OS (TV branch of it). When watching YouTube, about once every two weeks or so, the TV will pause for 3-4 seconds and reboot OR just instantly reboot. Doesn't happen when watching any source other than YouTube. I guess that means running through any other 'app' on the device.

    Also note that I power down the master power distribution strip ever

  • My 6a doesn't give it a damn. Next, please.

Slashdot Top Deals

Trap full -- please empty.

Close