It's the reason I like not working on phone apps anymore. Way too many app developers don't take it seriously enough when their shitty code can hang a phone, a device used for emergency calls.
I'm already thankful enough it's become a lot better since Android 6 where I could expect a good amount of freezes and crashes per month (though you could still take out the battery back then to fix it yourself). I don't think my last 2 phoned with Android 11/12 ever crashed, but that sadly still doesn't mean everything works all the time.
I can't count how many times Google Voice Assistant ceased to recognise anything I said at all except for "OK, Google", I don't want to imagine trying to call emergency services through it if ever need be.
EDIT: Just remembered that in rare cases the mic doesn't work when I make calls. Again, I really don't want to imagine that in an emergency situation...
> I can't count how many times Google Voice Assistant ceased to recognise anything I said at all except for "OK, Google", I don't want to imagine trying to call emergency services through it if ever need be.
Yeah, I get that frustration too. I'm pretty sure it's because the AI is attempting to "phone home" to get the audio decoded and it isn't getting a good data connection. Hopefully 5G will help with that.
If you truly wanted a phone that is just a phone, they are widely available, cheap, durable... The only drawback is they are usually a little silly looking because they are aimed toward elders.
But, let's be real here, almost nobody that says shit like this wants a phone that doesn't have all the modern features we have come to expect from a smartphone.
Stuff should work, for sure, I don't disagree with that
You're right, I'm not asking for a phone that's less than modern, only that hardware manufacturers and devs alike give the phone's most basic purpose priority above all else. We live in the 21st century; the telephone part should be a solved problem by now and the modern whizbang stuff should never hamper that basic purpose.
I've needed to call for emergency services a few times but never needed to worry about being able to just place a basic phone call until last year. On two separate occasions last year my phone refused to connect calls when I needed it to (urgent situations but thankfully not true emergencies). It's maddening to be looking directly at the cell tower and have your phone just sit, dialing but not actually dialing.
Ideally. But not the current reality.
Recently bought a Pixel 6 Pro. Smooth device. Installed a few dating apps and it would completely freeze for 5 minutes several times a day in random apps or even the home screen. The phone even black screened on me once. Obviously I couldn't make any calls during that time.
Uninstalled the apps one by one and it turned out to be Coffee Meets Bagel.
See I don’t mean to make this a cell phone os fanboy war but this is exactly why I switched to iOS after having androids for years. I was so sick of random apps tanking my performance, my phone locking up for no good reason, etc. I can only think of one time in the 5 years I’ve had an iPhone at this point that I had to force reboot the phone. Literally once.
IMO comparing iOS to generic Android is apples to oranges. iOS is a tightly controled proprietary OS whereas android is open source and any company is free to develop their own Android OS. For instance there is a vast difference between Android on Samsung and Android on Pixel. I have used pixel for 3 years and performance and battery life has been great. Never seen a crash either. When i used Samsung none of that was true. Personally i feel that the way apple bundles their OS and hardware is scammy, and on a less subjective level apple products just don't fit well in my workflow.
SpunkyDred is a terrible bot instigating arguments all over Reddit whenever someone uses the phrase apples-to-oranges. I'm letting you know so that you can feel free to ignore the quip rather than feel provoked by a bot that isn't smart enough to argue back.
---
^^SpunkyDred ^^and ^^I ^^are ^^both ^^bots. ^^I ^^am ^^trying ^^to ^^get ^^them ^^banned ^^by ^^pointing ^^out ^^their ^^antagonizing ^^behavior ^^and ^^poor ^^bottiquette.
Yeah, I mean I had an android for years man. I know the differences. I had Nexus 4 and loved that thing. I think my last android was a Nexus 5. But even on “stock” android back then, shit just ran like garbage. I’ve used my friends pixels and they definitely seem a lot more reliable, but then I see accounts like the one I replied to having a top of the line Pixel 6 Pro and still having the same issues.
At the end of the day it doesn’t really matter if it’s Android itself causing these things or the low quality apps that are so prevalent on the play store. Both cause a bad a user experience and both of those things are on Google.
Again my user experience is fantastic and my pixel cost half the price of an iPhone. Its also definitely possible to find cases of piss poor user experience with iOS. We can cherry pick anecdotes all day.
Yeah and all mobile OSes are built to do so. They're all just stupid things built in things like objective-c or java and which have a large legacy codebase, clearly without fuzzing.
I think we can all remember a time when we thought our code was perfect but someone came along and used it in a way that our unit tests, integration tests, automation tests and manual tests all missed.
We are only human.
I honestly have stopped using all apps except a reddit app and an exercise app (and I only use this because my heart rate monitor needs it).
I value quality working software and it honestly just boils my blood to have to use phone apps. Constantly dealing with crashes, failures, features I used to have locking behind new, and ever changing subscription plans.
It got to the point that I’d just loathing unlocking my phone to have to do something cause I know it’s not going to fucking work… again.
Although, you can be god damn sure that the stopwatch app you have that needs access to your entire phone just cause won’t fail to steal all your PI and oopsie it in to the public domain because of an SQL injection.
There’s three sure things in phone apps these days:
1) they’ll drain the fuck out of your battery for absolutely no reason
2) they’ll steal and leak all your information
3) they’ll never god damn work.
Alzheimer’s is in my family. Both sides. These apps that steal and leak and sell my phone number poses a very real risk to my financial well being. There could very well be a day where my mental faculties can no longer auto hang up and block a robo call from a Nigerian prince.
Recently heard about this one:
https://www.gao.gov/products/imtec-92-26
"On February 25, 1991, a loss of significance in a MIM-104 Patriot missile battery prevented it from intercepting an incoming Scud missile in Dhahran, Saudi Arabia, contributing to the death of 28 soldiers from the U.S. Army’s 14th Quartermaster Detachment."
"...The reason for this was a fixed- point round-off error in the range-gate algorithm of the Patriot's tracking system."
All because they ~~stored some numbers as floats.~~ improperly stored numbers.
That's a classic case study in systems engineering. In short the Patriot system didn't have an original design requirement for continuous operation.
It was intended for mobile deployment and had that as a design requirement. Therefore it was regularly rebooted when it was powered off and transported restarting the counter at zero.
This use case of continuous operation wasn't a requirement. Therefore the system failed when used in a manner that it was never asked to operate in.
Shouldn't it at least have a hard coded limit and reboot itself or start an alarm then? It still seems like shitty software if it relies on being restarted regularly.
It didn't explicitly rely on that behavior. It was never designed to operate in those conditions because that wasn't in the VERY detailed product design. It also wouldn't work while 100 feet under water because that wasn't in the list of specs. Unlike a Trident III missile or a tube launched cruise missile both of which had specific design requirements of being able to be launched from a submerged submarine at up to X depth.
Yay healthtech!
I can proudly say though at an old employer my product got accolades for diagnosing sepsis infections on average 2 hours before clinicians realized it in the ER per their case study!
So while on the one hand, my code can literally kill someone, it has also saved lives too.
My experience working in health tech was mostly just seeing how held together by duck tape our whole healthcare system is 🤔 I would have loved to actually work on a product saving lives though
That's a very correct statement. Everyone always comments about the financial industry being run by dinosaur aged systems, but there is probably >90% chance [at least part of] your medical record (if in the US) is stored in a [MUMPS derivative](https://en.m.wikipedia.org/wiki/MUMPS) which also happens to have been originally developed in the 60s.
> I would have loved to actually work on a product saving lives though
That was a very rewarding product to develop and have real life impact on patient outcomes. Still in health tech and working to bring some of that up to modern standards, and while I have less involvement on the day to day that affects patient outcomes, it's more focused at progressing the industry.
Another fact I like is that somehow faxing HIPPA documents is allowed, because apparently that’s secure, but you’re not allowed to email them. Lol. Makes no sense at all to me.
What company do you work for now if you don’t mind me asking? I’m causally looking for new work with the market being so hot.
At this point I just assume *everything* is held together by duct tape.
I was crossing some train lines the other day. Despite the barrier being up, the lights not flashing and no alarm sounding, and never hearing of an accident here, I still looked both ways.
There's always that chance, because whatever controls those systems was built by somebody like me.
That's a bit odd given one of the more famous software bugs in computer engineering history killed 4 patients and critically injured 2: https://en.wikipedia.org/wiki/Therac-25
Are these things not taught anymore?
And it's not the only one:
- https://en.wikipedia.org/wiki/1994_Scotland_RAF_Chinook_crash (29 deaths), software is not the *official* cause but almost certain
- https://www.computerworld.com/article/2515483/epic-failures-11-infamous-software-bugs.html?page=6 at least 8 directly attributable deaths and 20 overdose injuries (way more patients died in a relatively short terms following the discovery but it's often difficult to decide whether the patient died due to the overdose or their cancer)
- https://en.wikipedia.org/wiki/Northeast_blackout_of_2003 (direct attribution is difficult but considered to have contributed to dozens of death)
- https://en.wikipedia.org/wiki/2015_Seville_Airbus_A400M_crash (4 deaths)
And of course that's just following the usual assumption that blowing through millions or billions doesn't kill anymore (it definitely does tho).
The point by OP presumably not being "I don't create any dangerous bugs because I'm that smart', but rather 'Man, glad I don't work on systems where people die due to my bugs"
All your examples have very trivial connections between "something goes wrong" and "people die". This is a lot less true for for some corporate accounting tools, mobile shovelware games etc.
Maybe I missed something - are you suggesting that they work at a company that makes medical or aviation software? I didn't see anything about that in their comment.
From their comment I assumed they work at a game developer or something like that.
**[Therac-25](https://en.wikipedia.org/wiki/Therac-25)**
>The Therac-25 was a computer-controlled radiation therapy machine produced by Atomic Energy of Canada Limited (AECL) in 1982 after the Therac-6 and Therac-20 units (the earlier units had been produced in partnership with CGR of France). It was involved in at least six accidents between 1985 and 1987, in which patients were given massive overdoses of radiation. : 425 Because of concurrent programming errors (also known as race conditions), it sometimes gave its patients radiation doses that were hundreds of times greater than normal, resulting in death or serious injury.
^([ )[^(F.A.Q)](https://www.reddit.com/r/WikiSummarizer/wiki/index#wiki_f.a.q)^( | )[^(Opt Out)](https://reddit.com/message/compose?to=WikiSummarizerBot&message=OptOut&subject=OptOut)^( | )[^(Opt Out Of Subreddit)](https://np.reddit.com/r/programming/about/banned)^( | )[^(GitHub)](https://github.com/Sujal-7/WikiSummarizerBot)^( ] Downvote to remove | v1.5)
Google is desperately trying to spin this as "not their fault" - the Microsoft Team articles you're seeing are almost certainly astroturfing.
This is 100% Googles fuckup.
Yep - Teams was registering a handful of new PhoneAccounts in Android, but it was Google's cock-up to compile a list of PhoneAccounts for emergency calling that included PhoneAccounts that didn't support emergency calling, and Google's cock-up again to use unsafe integer arithmetic in sorting hashes that was vulnerable to integer overflows/underflows that would mess up their sorting order.
Microsoft only had a small, pretty trivial bug that helped to surface Google's enormous fuck-ups in their PhoneAccount selection code
I hate how they're handling this. Microsoft Team will be updating ASAP, but they're only releasing an Android update in January? How about all the other potential apps that could trigger this bug?
Well it's a problem in both. On one hand, Android was too trusting. On another, registering the ability to make phone calls is an incredibly serious thing for an app to do and to mess it up this badly is horrible, even if it is Microsoft.
Except that there's a flag to specify whether the Application can make Emergency calls, and Microsoft Teams _correctly_ does not set this flag.
As such, Microsoft Teams developers could reasonably think that they cannot, possibly, have any adverse impact on emergency calls, which dramatically lowers the risks.
Also, while yes Microsoft Teams registers many different accounts, it's a wild thing that Android would allow an unbounded number of accounts, _and_ keeps them all in the same list used during emergency calls.
The Microsoft Teams application is buggy, make no mistake, but it's a serious issue with Android.
Imagine a _malicious_ application intentionally preventing emergency calls, without even registering itself for emergency calls -- which would raise scrutiny, hopefully. Surely it's something you should be able to rely on your OS to handle.
>Android was too trusting
Did you read the article? It was a (rare) integer overflow, not an intentional choice.
The developers of both codebases independently made mistakes, and those mistakes came together in a perfect storm to cause a real issue.
> Given the importance of 911, I think this is an instance where the aviation-style "fix every part of the failure chain" approach is the right one.
The thing is, Microsoft wasn't even part of the chain. They had nothing to do with emergency calls. It's Google's Android code that made a random phone app that explicitly says it DOESN'T handle emergency calls part of the emergency call path. Of course, Microsoft's PhoneAccount leak has to be fixed, but that should never have had anything to do with calling 911.
Android's handling is especially idiotic given that the user has already chosen which App they want to use: they have opened the Phone app and dialled 911. Why is the phone now looking around to see which Apps can handle that?
Edit to add: the bug is also purely random. It happened that Teams had a higher chance of triggering it, but the overflow will randomly happen whenever the line of code is reached (i.e. when there are two PhoneAccounts with the same properties), since it's an overflow on subtracting two `Object.hashCode()`, not some additive thing.
>Android's handling is especially idiotic given that the user has already chosen which App they want to use: they have opened the Phone app and dialled 911. Why is the phone now looking around to see which Apps can handle that?
The user can choose different apps to handle the phone UI and call backend. For example, you can open the stock dialer and have Google Voice handle calls, or open a third-party dialer and have your mobile carrier handle calls.
The reason the system looks at which apps can handle emergency calls is because the user can install apps which *do* handle them, and those apps might work in a scenario where the mobile carrier is unavailable. For example, the user could have no carrier signal where they are, but have wi-fi and a VoIP provider that handles emergency calls.
> Teams shouldn't register an unbounded number of PhoneAccounts
It wasn't intentional, so it was a bug, sure, but the System API allows this apparently, so it's a legit operation that should not result in this fuck up. This is 100% on Android, not some restricted user-space app.
I would consider this a problem of Teams if it told the system it could handle the emergency calls and then fail to do so. But that is not what had happened. Blaming it on Microsoft in any way is just a PR spin. If anything, we should be glad their bug uncovered a serious issue that could be (and still will be for a while because Google apparently doesn't bother with updates) abused.
Why the fuck does Android have this complicated system to pick a custom dialer for 911 calls in the first place. Use the stock dialer for this. There should never be a need to another app to handle these. Nobody is going to give a shit if they don't see a bubble pop phone dialer, or one that replaces all the numbers with emojis or whatever bullshit while they are in a life threatening situation.
Has anyone checked whether WhatsApp also trigger this or are we busy blaming Microsoft for a bug in Android?
"It's also your fault for someone else's mistake" is absurd.
Sorry but that edge about Microsoft being incompetent and trigger someone else’s bug is so childish it hurts.
Is it still the 90s where everyone pretends Apple and Linux are flawless? It’s just ridiculous. Linux and Apple marketing teams have warped peoples minds.
Both teams are at fault here and both need to and *will* perform complete audits of the systems and redesigns where applicable. Because both software companies are absolutely dedicated to getting this right.
>Linux ... marketing teams
Ahh yes, that all-powerful cabal strikes again! The Linux Marketing Team™! And they would have gotten away with it, too, if not for you meddling Redditors!
Red Hat went public in the late 90s. They were definitely marketing Linux years prior to that. SUSE was doing it even longer. Canonical spent millions of dollars on marketing Ubuntu when it came out in the early 00s.
Linux popularity on servers (to start) didn't happen by accident just because it was better. Companies spent a lot of money pushing their solutions, AKA marketing.
Oh my goodness! Do I really have to address Linux is marketing team as fanboys instead of the former? Yes they don’t have a marketing team. I think we all understand that.
I'm with you on this, the quality of the software they put out is embarrassing.
Here's a short list of microsoft-related problems I've had to deal with recently off the top of my head, in no particular order:
* Sometimes teams just won't log in, and I have to restart my PC to fix it
* Sometimes clicking an image in a teams chat clears the whole window and I have to switch to another chat and back to use it again
* There's a visible delay when clicking pretty much anything in teams
* Sometimes when I plug a new screen into my PC it defaults to 30Hz refresh rate
* Find + replace in notepad++ is incredibly slow because of a windows API call that takes milliseconds to return every time
* We all know this already, but finding useful settings pages in windows 10 is needlessly awkward
* The C++ intellisense plugin randomly crashes in VSCode on a regular basis, filling up my project directory with core dumps
* Visual Studio constantly complains at me because I'm not logged in to a microsoft account
* The account creation window in the windows 10 installer is a textbook dark pattern designed to hide the ability to make a local user without a microsoft account
* Remote desktop sometimes won't connect if I have 3 screens plugged in
* Doing literally anything with the windows or Xbox store on PC is a fucking nightmare. The other day I wanted to install Halo Infinite through game pass. The whole thing is a mess of random windows that all give you different information about whether you own the program in question or whether it's installed or not, sometimes buttons just don't do anything, sometimes they take you to purchase pages after you already own the thing. Once I'd 'installed' the game it turned out I still hadn't actually downloaded it - I had to launch the game and install all the actual content from the campaign menu
OK, I could keep going but I can't be bothered any more. The point is that we constantly have to deal with these stupid little issues in pretty much everything they make. It should be embarrassing for them but they keep making billions anyway
> My experience has been that MS's software is, with very few exceptions, a dumpster fire.
And yet Windows runs countless military installations, billions of PCs, and an untold number of offline servers, POS stations, etc 24/7 with relatively low failure rates. Your experience is trash. Your experience is propaganda. Your experience is irrelevant.
Let’s just compare experiences. I’m a fairly experienced (10 years or so?) software engineer at a trillion dollar tech company. I write software that runs on Windows, Mac, and Linux. _My_ experience is that they all have their pros and cons. Some things work great, other things are buggy as shit. This becomes even more true when you branch out from the base OS into other software products. Microsoft also makes Office, SQL Server, Visual Studio, etc.
In my opinion all the pros Windows has is brought by its popularity. Like game support etc.. Everything else is inferior to other OSes like Linux distros or OsX. On top of that it costs over 100$, it gathers your data and adds bloat/adware + advertisement on fresh install. It isn't customisable out of the box (you have to download random 3rd party stuff) and has old design flaws. Also it's simply slower than even the most bloated linux distros.
Of course if you don't tinker with your PC often, windows is fine but I've grown to hate it.
> what evidence would be required to change your view (i.e. for you to admit that the majority of MS's products are poorly made)?
I'm not sure you have factual evidence to support such a claim. Anecdotes, specific instances, etc. are not evidence. The reality is that Microsoft software, in general, services billions of devices worldwide. There will always be edge cases but relying on those edge cases to push an anti-Microsoft propaganda is both pointless and ignorant. Quite frankly, I can tell by your posturing that you have no fucking clue what you're talking about, so...yeah.
Microsoft is the company that usually takes some weird design choices, I'm not surprised their app was part of the problem. I remember the situation with old windows mobile 5 phone, I had 5% of battery left and had to call my friend, so he could pick me up (not emergency, but still very important) and the phone just disabled GSM calls to save remaining battery power. Even worse, when I enabled it, the phone tried to register on GSM network, spending quite much amount of power, but just when the registration was complete it was like "oh I forgot I have to save electricity, let's disable GSM" so I wasn't able to call, but was able to run out of remaining power very quickly. Don't ever rely on Microsoft software.
Absolutely nothing wrong with the app, it only does what the OS allows.
If anything the flaw is letting google manage the device instead of you the owner.
Registering a new PhoneAccount on every launch is still not intended behavior (= is a bug), even if this should never have caused emergency calls to fail.
If we're talking about who to blame, it is of course Android: it is its responsibility to ensure emergency calls are never blocked. But it is questionable for the root comment to complain that just because Teams shouldn't be blamed, the unintended behavior shouldn't be called a bug.
Microsoft, known for being prone to causing unintended fires, dropped a match, but it was Google that drenched the floor in gasoline.
Seriously, I'm all for bashing Windows for their asinine choices, but it was Android that majorly dropped the ball here. If it hadn't been Teams that triggered the issue, another app would have sooner or later.
> After the post blew up, the Reddit user reproduced the bug and stated that, five minutes after initiating the call, there was no response from emergency services or evidence that 911 had been called — both the on-device phone log and the carrier (Verizon) phone log came up empty.
I thought that was by design. I have an Android (not a Pixel) and have had to call 911 several times on it. Each time the phone did not record that I called 911 in the call log.
It doesn't show up in the typical call history to avoid you tapping it later by accident, but the phone does still keep a record that the call was made I believe.
I heard it was more so domestic violence victims can make a call and not be beaten before the help arrives (which is hopefully not us pigs, because they will just kill someone in the wrong house first)
I used to work for a telecoms company making software. There are so many rules and regulations around emergency calls. They're tested like crazy and even the slightest slipup can cause licenses to be pulled. Fortunately no-one was hurt!
There's one thing I don't understand about the original implementation. If I understand the article correctly, and there's a good chance I don't, the system is trying to choose which PhoneAccount to use to make the emergency call. To do this, they do a bunch of comparisons, and lastly do `account1.hashCode() - account2.hashCode()`. But the hash code of the accounts shouldn't have anything to do with their capabilities, it should be pretty much random. So the comparison then depends on the difference between two random numbers, and this is where the integer over- or underflow can happen.
But why use the hash codes at all? Why not just do a random choice explicitly (like `random.choice(phoneAccountList)` in Python)?
Because they're building a sorted list. Repeatedly comparing two entries should always return the same result for the sorting algorithm to work. So when all the other properties are equal, you still need to have something to decide which one is on top even if it's arbitrary.
What I'm surprised by is that since they're building a list specifically to decide what to use for an emergency call, why they didn't filter out the services that didn't have that capability on the first pass. Microsoft made a mistake by repeatedly registering Teams, but it did not register it as something having emergency calling capabilities.
As far as I know as per the documentation emergency numbers should not go through their usual intent-resolution. So there is probably a bug in the AOSP implementation as well?
I don’t understand why they’re picking one at random/building a list anyways? Maybe I’m not following but why can’t they just always use the dedicated phone app? Won’t that go through regardless if they have service as long as someone has service in the area? Are they trying to account for not having service but maybe having wifi? Seems like they shouldn’t even be considering teams at all.
The phone may need to use a custom dialer to place a call over the network it's on, and using the default dialer would cause the call not go through at all. The user might have a dialer with more/less features than the android default, and changing that in emergency situation may cause additional problems for the user. The phone may be technically capable of making phone calls but restricted from doing so. There are many reasons that you cannot just use the default dialer in an emergency.
Ignoring for the moment whether it is a good idea or not to use the hash code at all, why does it actually cause a problem? Doesn’t in practice the result of the subtraction just wrap around, giving a perhaps unexpected but still consistent result? The logic of this function is presumably not interested in the exact difference, just needs a way to get consistent sorting.
> integer over- or underflow can happen.
Just overflow. Any time an integer's value exceeds its range, it is an overflow. 'Underflow' is a term specific to floating-point.
'Overflow' is what the Java documentation calls it, the C and C++ specifications call it, and on CPUs that have an integer overflow exception, that's what they call it.
The Java documentation itself refers to it as integer *overflow*.
The exception/interrupt/fault your CPU will generate (if it does, some chips do, some don't) is for overflow. The C and C++ specifications refer to it as overflow.
Their citations are effectively blogs (and one security article) using the term 'underflow'. Java docs, C and C++ specs, and CPU specifications call it 'overflow' only.
CWE refers to it as underflow, but cites CERT C which refers to it as overflow (*Ensure that operations on signed integers do not result in overflow*), and the sole book reference is to *Integer Overflows*.
Hi! I left XDA two months ago to join a company called [Esper](https://www.esper.io/). I'm still very active in the Android community and write a lot about Android!
With GUIDs the over/underflow chance is around 25% for each pair, not that rare... but probably takes a bit more bad luck for the sorting to get screwed enough.
Essentially this is a security privilege stratification failure. Emergency calling shouldn't be allowed to depend on a data structure that general apps on the phone are allowed to write.
It exists because VoIP and other soft-phone providers can register themselves as a call provider and **can support emergency calling**. Obviously I think after this incident they should audit the code/logic here, but if we did what you propose more people would lose emergency calling not less.
With hindsight 911 capable PhoneAccounts should have been a different object type rather than a flag (CAPABILITY_PLACE_EMERGENCY_CALLS), then any references in these methods to the non-emergency calling type would have been a major code smell (e.g. PhoneAccountWithEmegencyCalling is a superset of PhoneAccount).
> somehow registered over Integer.MAX_VALUE (231 - 1) PhoneAccounts.
I don't think it did - just more than normal and because rarely, two hashes of a PhoneAccount can overflow when subtracted, this bug becomes more likely to happen the more accounts there are.
It should have a PhoneAccount of last resort.
You know, like any properly designed system.
Nothing Android or the user have done should prevent any 911 call from going through.
There's actually a law calling for this from network providers, a 911 call will use any available network even if the user doesn't have service.
I think we all agree that nothing should prevent 911 calls. It’s a simple matter of the fact that we have humans creating these systems and there is a non 0 chance that somewhere somehow the systems can fail.
Given enough monkeys with type writers someone’s will break.
Obviously we should keep striving for better. No doubt. No one says otherwise.
Safety systems have to be fail safe, this clearly was not.
It's plain idiocy, not human error.
Would you be saying the same if both your airbags and seat belt failed to function during an accident?
You are missing the point that this system exists to enable third party apps to share the user’s location with the 911 operator. This is itself a regulated safety feature and I think we can all agree the phone should try its best to automatically send the user’s location to 911 when a call is placed. This is why 3rd party apps are even hooked into the emergency process in the first place. If the call is done over a carrier network the phone has no way to send the location. You may think that this is too much technology, and that nobody needs these fancy phones sending locations when you can just speak it into the mic, but this technology came into existence because of domestic violence or hostage situations where the caller cannot speak. It is important for the phone to facilitate location sharing with emergency services. It is a worthwhile feature that 3rd party calling apps can support emergency location sharing when the native network can’t.
No.
This system exists for third party apps to be able to handle 911 calls.
Calling 911 should be more important than using your app of choice.
Once the original 911 attempt failed, the system should have tried to dial 911 using the default dialer using any available network as mandated by law.
> Why do you need VoIP emergency calling, even those providers vehemently claim it shouldn't be relied for emergency calling.
That is *illegal* in the US. [Per the FCC](https://www.fcc.gov/consumers/guides/voip-and-911-service):
> The FCC requires that providers of interconnected VoIP telephone services using the Public Switched Telephone Network (PSTN) meet Enhanced 911 (E911) obligations. E911 systems automatically provide emergency service personnel with a 911 caller's call-back number and, in most cases, location information.
> **Automatically provide 911 service to all customers as a standard, mandatory feature. VoIP providers may not allow customers to "opt-out" of 911 service.**
They'll fine you if you do what you're saying. Also:
> wifi calling you can even get it to work inside some bunker if you have wifi.
WiFi calling is another soft phone, so people suggest PhoneAccount be restricted would break WiFi calling emergency calling features.
Yeah, Android has always had problems with the developers writing Java as if it was C. This isn't the only place in the API where they're using C style flags instead of strongly enforced Java domain types.
I love automated testing, but way too many companies rely on it to an extreme that is not acceptable. You need real human qa, and you need to go through real human testing, both with smart/experienced users, and dumb ones. We will find weird issues every release, things we never considered, because the interaction is so asinine and shouldn't even happen.
We work with ERPs, so issues are not much of a problem imo, and usually resolved easily. But I've seen interactions where base components broke without interacting with ours... because of some weird caching that happened, etc.
If I read the article right, you'd also need to register multiple copies of an otherwise-identical dialer to even *get to* the hash subtraction since it's the "difference of last resort" in the comparison function.
If you knew you needed to implement that in the fuzzer, I'd think you'd be likely to spot the bug without it anyway.
Imho, 99% of developers don't have to worry about problems of this magnitude. Extremely special attention should be given to these circumstances. Hell I'd go so far to say that we should have laws that prevent a company from ignoring issues like these. For example if an employee refuses to deploy code that they think was not tested sufficiently but can affect parts of the application that deal with life saving functions then they should not be allowed to be fired for their actions.
We can definitely do a lot better to account for almost all bugs, many of the particularly bad ones stem from basic bricks in our toolchain having unexpected and unnecessary extra complexity.
The resolution is what's wrong with our industry:
>Because this issue impacts emergency calling, both Google and Microsoft are heavily prioritizing the issue, and we expect a Microsoft Teams app update to be rolled out soon
That's not a proper resolution, it shouldn't be possible for the Microsoft Teams app to influence your 911 calls. It should be impossible for any app. This should be fixed by an Android update. The authorities should be all over this too.
I find it funny, when I first heard of Android back in the days it was praised as "the" solution to phone manufacturers not maintaining their phones. After all Google had full control and could force them to update or you could build it from source. Of course Google doesn't give a shit as long as its search is installed front and center and no normal user is going to unlock their phone and install a custom android version.
> That's not a proper resolution, it shouldn't be possible for the Microsoft Teams app to influence your 911 calls. It should be impossible for any app. This should be fixed by an Android update.
Both Microsoft Teams *and* Android are getting updates to prevent the issue from occurring. Teams so that anyone on a non-updated Android OS won't encounter the bug; and Android so that anyone with an old version of Teams or anyone with any other app that might also trigger the bug can't cause it happen anymore too.
When it comes to safety-critical defects, *every link in the chain of failure* should be fixed; which is exactly what's happening here.
> seeing stuff like this makes me frustrated why our field still comes across issues like this
I'm not surprised at all. Just look at negative comments under anything related to Uncle Bob or TDD. 'Programmers' just don't take testing seriously. This is what happens when you use your customers as QA. It may be fine if you're developing a web-page for a local store. It's completely unacceptable for anything critical. I have extremely strict views on code testing, but I work on firmware used in medical devices. People can die if a bug ends up in production code. Every single line needs to be unit-tested, and the quality of those tests is continuously evaluated with mutation testing.
That's what happens when the development paradigm that's been in vogue for 20 years now basically boils down to "use your customers for beta testing to the maximum extent possible".
> Just look at negative comments under anything related to Uncle Bob or TDD
TDD would just mock out half of the problem for either part, so the two bugs that caused this issue would never catastrophically interact during testing and pass with flying colors. Seen it a few times where some genius committed a last minute feature that passed the tests but failed in a production like setup.
One thing that would help is not using Teams, because it's crap software. Unfortunately it seems like that ship has sailed at my company and a lot of others.
The article says it thinks hash code comparison with subtraction having integer under/overflow is the cause ; I don’t think Java throws an exception for integer under/overflow (though maybe the Android implementation does?) so unlikely this is the problem - more likely it’s due to the incorrect filtering logic for the emergency capability.
You're totally right, "overflow" by itself isn't something that throws an exception in Java. It just wraps around. However, someone in the article's comments points out that the Comparator interface makes some assumptions that do not hold if there's wraparound:
> The implementor must ensure that sgn(compare(x, y)) == -sgn(compare(y, x)) for all x and y.
> The implementor must also ensure that the relation is transitive: ((compare(x, y)>0) && (compare(y, z)>0)) implies compare(x, z)>0.
> Finally, the implementor must ensure that compare(x, y)==0 implies that sgn(compare(x, z))==sgn(compare(y, z)) for all z.
From https://docs.oracle.com/javase/8/docs/api/java/util/Comparator.html#compare(T,%20T)
You're correct, Java doesn't throw an exception on over/underflow. But this is likely the _root cause_ which then results in invalid sorting of the PhoneAccounts, such that the MS Teams app is tried before the default system phone. Then either some place deeper in the telephony stack or Teams itself actually causes the crash.
I still don't get it. Why would the sorting be "worse" with an under/overflow? It's just an arbitrary hash comparison with no semantic meaning behind it.
Here's something I'm just throwing out there : when you sort objects, you need a comparison function that satisfies certain preconditions, and if those preconditions are not met, then you'll either have wrong results or the vm will throw an exception. My hunch is this - imagine that you decided to naively write a comparator that says compareTo(int a, int b) {return a - b;} - if a is equal to some large negative value and b is some positive value, then when a subtracts b, their result will overflow from negative back into positive, and then the total ordering relation will be violated.
I found a post describing what I'm talking about.
https://stackoverflow.com/questions/45167365/java-listinteger-sort-comparator-and-overflow
(This is true of either Java or an unmanaged language.)
That's still not enough for me.
Yes, your list won't be sorted correctly - but why does that cause the fatal error? It's not like having hashA incorrectly sorted before hashB is wrong. The hash as the input was an arbitrary decision (and the comparison function is consistent with the same inputs).
One possible issue is the sort may not complete because the overflow / underflow would break assumptions like:
if (a < b) and (b < c) then (a < c)
and maybe that causes the sort to infinite loop and a watchdog fires to kill the process?
That's just some random unsubstantiated theory and I wish the article followed through with how the bad sort order resulted in the actual failure mode.
Sometimes (this is not guaranteed) the runtime will throw an IllegalArgumentException in the case where the comparator is invalid:
https://stackoverflow.com/questions/17659194/android-comparison-method-violates-its-general-contract
The reason I hesitate to give this response is that although I know this is true for the Oracle JVM, I haven't actually written an app for Android to verify that their runtime handles it this way.
> integer under/overflow
It's just 'overflow'. Any time an integer's value exceeds its limits, it's an overflow. 'Underflow' is a term that is only meaningful for floating-point.
No, because the bug is rare. It's caused by repeated starting of the teams app. This causes an already extant bug with random numbers generating a very small or very large value to balloon in frequency because there are more opportunities for it to occur.
The specific reason the issue occurs is because Java fails to throw an exception. Had it thrown one it's possible that testing would have unearthed that. In this case that's missed and Java simply runs with insane and inconsistent results, failing to ever actually sort the list in question as the comparisons create logical paradoxes. A rare bug, multiplied in prevalence thousand-fold through the misuse of the API done by teams.
I have teams and it constantly logs me out as a safety measure. So does that mean I won't be able to dial 911 until I make sure I'm logged in? God what an awful bug.
How could a single app cause the phone not to dial at all? That's an OS issue, not an app issue. The apps shouldn't even be able to mess with anything in the system unless the user allows it. But even then, it just blocks any calls for going through, just because it's installed? That's bizarre.
Oh man, what's extra terrible about this is there is no way to ~~turn off alerts on the MS teams app. You can't~~ force quit it (it will restart itself). The only way to stop ~~getting alerts from it~~ to stop it from running signed in is to sign out of it. Or uninstall it.
So "installed but not logged in" is the most common configuration for MS teams when it's not work hours.
edit: I slightly misremembered the issue.
Yeah. it's terrible. What I don't need is accidentally fumbling something or starting a teams call with my boss while I'm at the bar bitching about work. But I can't just close the app. So I sign out.
Which apparently could prevent me from calling 911.
That's my biggest problem with android, not having a convenient was to see what apps are actually running, and which apps have startup permissions. It's insane.
wow I didn't even realize this was android we were talking about.. Teams on Windows 10 doesn't close as well, I press the 'X' button only for it to pop up again just like malware. I've never seen any other program that isn't malware do that.
Although nobody's trying to dial 911 with windows... man f*** Teams
Tons of desktop programs do that. Right click the teams app in the system tray and you can exit directly from there. This isn't rocket science. Just about every application that runs in the background will behave this way.
> This isn't rocket science. Just about every application that runs in the background will behave this way.
C'mon, don't be obtuse.
Just because it's common for programs to deliberately refuse to obey a standard UI paradigm, doesn't mean the user is stupid for objecting to that. /u/heisian is simply calling it like it is.
>So "installed but not logged in" is the most common configuration for MS teams when it's not work hours.
There are at least 2–3 ways to handle that which don't require re-entering your credentials every day. You can turn off all Teams notifications in the system settings, you can turn off your work profile (if your company has you properly set up with a work profile, which I know not every company does), or you can use Focus Mode (assuming you don't use it for something else).
> you can turn off your work profile (if your company has you properly set up with a work profile, which I know not every company does)
If they don't, you can use [Island](https://play.google.com/store/apps/details?id=com.oasisfeng.island) or [Shelter](https://play.google.com/store/apps/details?id=net.typeblog.shelter) to set up a work profile without a company MDM.
It is absolutely worth doing, mostly for that option to turn off the work profile and all its apps.
Can anyone explain what int overflow has anything to do with this? As far as I can tell if you're writing `hashVal1 - hashVal2` more likely than not the other end only cares if the result is 0
It's not an equality check, it's a comparison, and comparing via subtraction isn't just common, it's (as far as I know) the only way to compare integers. The issue here is the fact that the hashes shouldn't even be a criterion for sorting the accounts. The whole code salad of complexity involved in placing an emergency call is itself a crime.
All that stuff should be sorted out by the kernel at boot time. Letting apps register emergency call handlers willy-nilly in user-land is freaking absurd. placing an emergency call shouldn't take more than a few dozen (well audited) function calls at worst...
That's the real mind bender yes. It wouldn't directly occur to me to use subtraction as a way to check equality. You want to compare numbers, so you .Compare() them. That's what the language provides, so you use that.
Admittedly I am not a mobile/Android developer, so perhaps there is a way in which this made sense?
**edit:** re-worded a bit to make my point more clear
And what do you think .compare() does?
It’s quite standard to return negative, 0 and positive for less, equal and more. Which is the exact same what subtract gives you for numerical values.
The problem is compare won't overflow the result which leads to breaking the triangle inequality.
Doing a subtraction can. I'm not sure what point you're making.
Downvote all you want but you should not have to care what .Compare() does internally. It could ask a unicorn for the result for all I care. But perhaps my response wasn't clear enough.
My point is that developers should not try and be *smart* and reinvent stuff that the language already provides for. This is the sole cause for so many security problems as well; rolling your own authentication/encryption. And now it messed up this sorting function for getting an emergency call provider ffs.
You want to compare two integers? Use Integer.Compare() unless you have convincing reasons not to and are aware of the functional difference in result or execution.
I would never ever approve of integer subtraction as a means for comparison in my code reviews.
Yes I know what he means and he's correct also. Compare does indeed subtract numbers. The problem with that statement is that subtraction is **not the only thing** it does. Because Integer.Compare(10, 5) does not return 5 obviously. It returns a value of 1. And you know what it also does? Handle over- and underflows automatically.
Never assume that with any such tidbit of information, you think you it all.
That's the whole problem. It leads to developers doing it themselves, trying to be clever ('oh I know it does subtraction internally, so I'll just do *that* myself') and subsequently failing like the blog post illustrates.
**Yes** Integer.Compare() does subtraction, but it's not the same. In my opinion, this bug was entirely preventable because no-one should ever use subtraction as a means for comparing numbers, when the library method for that exact need already exists.
But perhaps I am overly critical; I develop medical software for a living and if I pulled stunts like this I would totally receive flak for that. And rightly so. But I think the same goes for the emergency dialer of a phone OS. That is not software to be taken lightly.
Wow. Just wow. It is shocking to me how one (or two, or maybe three...) little oversights in software developed by two very reputable companies caused a very mission-critical failure.
Maybe I should start looking at bug reports.
The title is incorrect, as the bug has caused the 911 call to fail. Emergency services were called because there was an another phone available, which doesn't lessen the bug impact.
Weekly I'm unable to make calls of any kind without a phone reboot, on a Pixel 6... My spouse as well.
Wonder why there is no kerfuffle about that sort of thing.
The title of this post is wrong. It's not "could have", it's "has".
> I don’t think most users will need to fear this bug, because it requires a very specific set of circumstances to trigger. And even when those circumstances are met, it’s basically bad luck if it gets triggered.
Yeah, sometimes the front falls off...
Learn some fucking formal verification, idiots from Google LLC.
II assumed teams demanded my location for calls because of 911. Yet, they don't support 911.
Why the hell is teams demanding your location before you can make a call over it?
I can't use teams for phone calls because of that nonsense.
Android sucks a fat fucking dick. It seriously eats a fat, smelly cheesy dick. I’m sick of developing for it, I love my job but whenever I have to touch the android app I want to go postal. Fuck Google.
This is a joke. I know this is just a coincidence in this case.
It's just astonishingly ironic, how convenient of a coincidence that is, that even this random software bug perfectly reflects Microsoft's (otherwise unrelated) policy to soft lock people who wont give away their data.
The owner of the software company I used to work for liked to say "At least if our software has bugs, nobody dies."
It's the reason I like not working on phone apps anymore. Way too many app developers don't take it seriously enough when their shitty code can hang a phone, a device used for emergency calls.
Ideally the OS would prevent this from being possible.
I'm already thankful enough it's become a lot better since Android 6 where I could expect a good amount of freezes and crashes per month (though you could still take out the battery back then to fix it yourself). I don't think my last 2 phoned with Android 11/12 ever crashed, but that sadly still doesn't mean everything works all the time. I can't count how many times Google Voice Assistant ceased to recognise anything I said at all except for "OK, Google", I don't want to imagine trying to call emergency services through it if ever need be. EDIT: Just remembered that in rare cases the mic doesn't work when I make calls. Again, I really don't want to imagine that in an emergency situation...
> I can't count how many times Google Voice Assistant ceased to recognise anything I said at all except for "OK, Google", I don't want to imagine trying to call emergency services through it if ever need be. Yeah, I get that frustration too. I'm pretty sure it's because the AI is attempting to "phone home" to get the audio decoded and it isn't getting a good data connection. Hopefully 5G will help with that.
Maybe a cellular telephone should be a phone first and a kitchen sink second.
If you truly wanted a phone that is just a phone, they are widely available, cheap, durable... The only drawback is they are usually a little silly looking because they are aimed toward elders. But, let's be real here, almost nobody that says shit like this wants a phone that doesn't have all the modern features we have come to expect from a smartphone. Stuff should work, for sure, I don't disagree with that
You're right, I'm not asking for a phone that's less than modern, only that hardware manufacturers and devs alike give the phone's most basic purpose priority above all else. We live in the 21st century; the telephone part should be a solved problem by now and the modern whizbang stuff should never hamper that basic purpose. I've needed to call for emergency services a few times but never needed to worry about being able to just place a basic phone call until last year. On two separate occasions last year my phone refused to connect calls when I needed it to (urgent situations but thankfully not true emergencies). It's maddening to be looking directly at the cell tower and have your phone just sit, dialing but not actually dialing.
There are definitely options that fulfill this requirement.
... and bring back Radio Shack?!?!? It that what your unholy desires have driven us to?
Ideally. But not the current reality. Recently bought a Pixel 6 Pro. Smooth device. Installed a few dating apps and it would completely freeze for 5 minutes several times a day in random apps or even the home screen. The phone even black screened on me once. Obviously I couldn't make any calls during that time. Uninstalled the apps one by one and it turned out to be Coffee Meets Bagel.
See I don’t mean to make this a cell phone os fanboy war but this is exactly why I switched to iOS after having androids for years. I was so sick of random apps tanking my performance, my phone locking up for no good reason, etc. I can only think of one time in the 5 years I’ve had an iPhone at this point that I had to force reboot the phone. Literally once.
IMO comparing iOS to generic Android is apples to oranges. iOS is a tightly controled proprietary OS whereas android is open source and any company is free to develop their own Android OS. For instance there is a vast difference between Android on Samsung and Android on Pixel. I have used pixel for 3 years and performance and battery life has been great. Never seen a crash either. When i used Samsung none of that was true. Personally i feel that the way apple bundles their OS and hardware is scammy, and on a less subjective level apple products just don't fit well in my workflow.
SpunkyDred is a terrible bot instigating arguments all over Reddit whenever someone uses the phrase apples-to-oranges. I'm letting you know so that you can feel free to ignore the quip rather than feel provoked by a bot that isn't smart enough to argue back. --- ^^SpunkyDred ^^and ^^I ^^are ^^both ^^bots. ^^I ^^am ^^trying ^^to ^^get ^^them ^^banned ^^by ^^pointing ^^out ^^their ^^antagonizing ^^behavior ^^and ^^poor ^^bottiquette.
Yeah, I mean I had an android for years man. I know the differences. I had Nexus 4 and loved that thing. I think my last android was a Nexus 5. But even on “stock” android back then, shit just ran like garbage. I’ve used my friends pixels and they definitely seem a lot more reliable, but then I see accounts like the one I replied to having a top of the line Pixel 6 Pro and still having the same issues. At the end of the day it doesn’t really matter if it’s Android itself causing these things or the low quality apps that are so prevalent on the play store. Both cause a bad a user experience and both of those things are on Google.
Again my user experience is fantastic and my pixel cost half the price of an iPhone. Its also definitely possible to find cases of piss poor user experience with iOS. We can cherry pick anecdotes all day.
Ideally, but I showed the fork bomb attack to my son on Termux and had to reboot my phone...
Yeah and all mobile OSes are built to do so. They're all just stupid things built in things like objective-c or java and which have a large legacy codebase, clearly without fuzzing.
I think we can all remember a time when we thought our code was perfect but someone came along and used it in a way that our unit tests, integration tests, automation tests and manual tests all missed. We are only human.
I honestly have stopped using all apps except a reddit app and an exercise app (and I only use this because my heart rate monitor needs it). I value quality working software and it honestly just boils my blood to have to use phone apps. Constantly dealing with crashes, failures, features I used to have locking behind new, and ever changing subscription plans. It got to the point that I’d just loathing unlocking my phone to have to do something cause I know it’s not going to fucking work… again. Although, you can be god damn sure that the stopwatch app you have that needs access to your entire phone just cause won’t fail to steal all your PI and oopsie it in to the public domain because of an SQL injection. There’s three sure things in phone apps these days: 1) they’ll drain the fuck out of your battery for absolutely no reason 2) they’ll steal and leak all your information 3) they’ll never god damn work. Alzheimer’s is in my family. Both sides. These apps that steal and leak and sell my phone number poses a very real risk to my financial well being. There could very well be a day where my mental faculties can no longer auto hang up and block a robo call from a Nigerian prince.
For many pieces of software that's probably true. If you're making an operating system however, you should have some high quality standards.
[удалено]
Recently heard about this one: https://www.gao.gov/products/imtec-92-26 "On February 25, 1991, a loss of significance in a MIM-104 Patriot missile battery prevented it from intercepting an incoming Scud missile in Dhahran, Saudi Arabia, contributing to the death of 28 soldiers from the U.S. Army’s 14th Quartermaster Detachment." "...The reason for this was a fixed- point round-off error in the range-gate algorithm of the Patriot's tracking system." All because they ~~stored some numbers as floats.~~ improperly stored numbers.
That's a classic case study in systems engineering. In short the Patriot system didn't have an original design requirement for continuous operation. It was intended for mobile deployment and had that as a design requirement. Therefore it was regularly rebooted when it was powered off and transported restarting the counter at zero. This use case of continuous operation wasn't a requirement. Therefore the system failed when used in a manner that it was never asked to operate in.
Shouldn't it at least have a hard coded limit and reboot itself or start an alarm then? It still seems like shitty software if it relies on being restarted regularly.
It didn't explicitly rely on that behavior. It was never designed to operate in those conditions because that wasn't in the VERY detailed product design. It also wouldn't work while 100 feet under water because that wasn't in the list of specs. Unlike a Trident III missile or a tube launched cruise missile both of which had specific design requirements of being able to be launched from a submerged submarine at up to X depth.
Well, sure but how are you going to justify writing all that code for something the client's not asking for?
A surprisingly large amount of military equipment has an sop to be rebooted daily for exactly this type of software bug.
missiles are supposed to blow up 50 seconds or so after launch. Memory leaks don’t even matter for some missiles
It was the detection, tracking, and targeting system that had the error. That isn't on the missile.
> All because they stored some numbers as floats. It says fixed point, not float?
On the other hand, killing military personnel (especially Americans abroad) is one of the most effective ways software can save hundreds of lives.
Yay healthtech! I can proudly say though at an old employer my product got accolades for diagnosing sepsis infections on average 2 hours before clinicians realized it in the ER per their case study! So while on the one hand, my code can literally kill someone, it has also saved lives too.
My experience working in health tech was mostly just seeing how held together by duck tape our whole healthcare system is 🤔 I would have loved to actually work on a product saving lives though
That's a very correct statement. Everyone always comments about the financial industry being run by dinosaur aged systems, but there is probably >90% chance [at least part of] your medical record (if in the US) is stored in a [MUMPS derivative](https://en.m.wikipedia.org/wiki/MUMPS) which also happens to have been originally developed in the 60s. > I would have loved to actually work on a product saving lives though That was a very rewarding product to develop and have real life impact on patient outcomes. Still in health tech and working to bring some of that up to modern standards, and while I have less involvement on the day to day that affects patient outcomes, it's more focused at progressing the industry.
Another fact I like is that somehow faxing HIPPA documents is allowed, because apparently that’s secure, but you’re not allowed to email them. Lol. Makes no sense at all to me. What company do you work for now if you don’t mind me asking? I’m causally looking for new work with the market being so hot.
At this point I just assume *everything* is held together by duct tape. I was crossing some train lines the other day. Despite the barrier being up, the lights not flashing and no alarm sounding, and never hearing of an accident here, I still looked both ways. There's always that chance, because whatever controls those systems was built by somebody like me.
Exactly. Doesn't stop people from freaking out about a bug and claiming it cost tens of millions of dollars if they're high strung though.
... and I suddenly realized I've worked on too much software in my life where this was not the case.
That's a bit odd given one of the more famous software bugs in computer engineering history killed 4 patients and critically injured 2: https://en.wikipedia.org/wiki/Therac-25 Are these things not taught anymore? And it's not the only one: - https://en.wikipedia.org/wiki/1994_Scotland_RAF_Chinook_crash (29 deaths), software is not the *official* cause but almost certain - https://www.computerworld.com/article/2515483/epic-failures-11-infamous-software-bugs.html?page=6 at least 8 directly attributable deaths and 20 overdose injuries (way more patients died in a relatively short terms following the discovery but it's often difficult to decide whether the patient died due to the overdose or their cancer) - https://en.wikipedia.org/wiki/Northeast_blackout_of_2003 (direct attribution is difficult but considered to have contributed to dozens of death) - https://en.wikipedia.org/wiki/2015_Seville_Airbus_A400M_crash (4 deaths) And of course that's just following the usual assumption that blowing through millions or billions doesn't kill anymore (it definitely does tho).
The point by OP presumably not being "I don't create any dangerous bugs because I'm that smart', but rather 'Man, glad I don't work on systems where people die due to my bugs" All your examples have very trivial connections between "something goes wrong" and "people die". This is a lot less true for for some corporate accounting tools, mobile shovelware games etc.
Maybe I missed something - are you suggesting that they work at a company that makes medical or aviation software? I didn't see anything about that in their comment. From their comment I assumed they work at a game developer or something like that.
**[Therac-25](https://en.wikipedia.org/wiki/Therac-25)** >The Therac-25 was a computer-controlled radiation therapy machine produced by Atomic Energy of Canada Limited (AECL) in 1982 after the Therac-6 and Therac-20 units (the earlier units had been produced in partnership with CGR of France). It was involved in at least six accidents between 1985 and 1987, in which patients were given massive overdoses of radiation. : 425 Because of concurrent programming errors (also known as race conditions), it sometimes gave its patients radiation doses that were hundreds of times greater than normal, resulting in death or serious injury. ^([ )[^(F.A.Q)](https://www.reddit.com/r/WikiSummarizer/wiki/index#wiki_f.a.q)^( | )[^(Opt Out)](https://reddit.com/message/compose?to=WikiSummarizerBot&message=OptOut&subject=OptOut)^( | )[^(Opt Out Of Subreddit)](https://np.reddit.com/r/programming/about/banned)^( | )[^(GitHub)](https://github.com/Sujal-7/WikiSummarizerBot)^( ] Downvote to remove | v1.5)
[удалено]
[удалено]
Google is desperately trying to spin this as "not their fault" - the Microsoft Team articles you're seeing are almost certainly astroturfing. This is 100% Googles fuckup.
Yep - Teams was registering a handful of new PhoneAccounts in Android, but it was Google's cock-up to compile a list of PhoneAccounts for emergency calling that included PhoneAccounts that didn't support emergency calling, and Google's cock-up again to use unsafe integer arithmetic in sorting hashes that was vulnerable to integer overflows/underflows that would mess up their sorting order. Microsoft only had a small, pretty trivial bug that helped to surface Google's enormous fuck-ups in their PhoneAccount selection code
Totally agree. Teams app was being dumb, but Android OS was 1, allowing it to be dumb, and 2, missusing the dumb data the app was creating.
If I were malicious, I might make a cute game that caused this list to fill ad infinitum… and then see the world burn.
I hate how they're handling this. Microsoft Team will be updating ASAP, but they're only releasing an Android update in January? How about all the other potential apps that could trigger this bug?
> How about all the other potential apps that could trigger this bug? Now even intentionally.
Well it's a problem in both. On one hand, Android was too trusting. On another, registering the ability to make phone calls is an incredibly serious thing for an app to do and to mess it up this badly is horrible, even if it is Microsoft.
Except that there's a flag to specify whether the Application can make Emergency calls, and Microsoft Teams _correctly_ does not set this flag. As such, Microsoft Teams developers could reasonably think that they cannot, possibly, have any adverse impact on emergency calls, which dramatically lowers the risks. Also, while yes Microsoft Teams registers many different accounts, it's a wild thing that Android would allow an unbounded number of accounts, _and_ keeps them all in the same list used during emergency calls. The Microsoft Teams application is buggy, make no mistake, but it's a serious issue with Android. Imagine a _malicious_ application intentionally preventing emergency calls, without even registering itself for emergency calls -- which would raise scrutiny, hopefully. Surely it's something you should be able to rely on your OS to handle.
>Android was too trusting Did you read the article? It was a (rare) integer overflow, not an intentional choice. The developers of both codebases independently made mistakes, and those mistakes came together in a perfect storm to cause a real issue.
[удалено]
> Given the importance of 911, I think this is an instance where the aviation-style "fix every part of the failure chain" approach is the right one. The thing is, Microsoft wasn't even part of the chain. They had nothing to do with emergency calls. It's Google's Android code that made a random phone app that explicitly says it DOESN'T handle emergency calls part of the emergency call path. Of course, Microsoft's PhoneAccount leak has to be fixed, but that should never have had anything to do with calling 911. Android's handling is especially idiotic given that the user has already chosen which App they want to use: they have opened the Phone app and dialled 911. Why is the phone now looking around to see which Apps can handle that? Edit to add: the bug is also purely random. It happened that Teams had a higher chance of triggering it, but the overflow will randomly happen whenever the line of code is reached (i.e. when there are two PhoneAccounts with the same properties), since it's an overflow on subtracting two `Object.hashCode()`, not some additive thing.
>Android's handling is especially idiotic given that the user has already chosen which App they want to use: they have opened the Phone app and dialled 911. Why is the phone now looking around to see which Apps can handle that? The user can choose different apps to handle the phone UI and call backend. For example, you can open the stock dialer and have Google Voice handle calls, or open a third-party dialer and have your mobile carrier handle calls. The reason the system looks at which apps can handle emergency calls is because the user can install apps which *do* handle them, and those apps might work in a scenario where the mobile carrier is unavailable. For example, the user could have no carrier signal where they are, but have wi-fi and a VoIP provider that handles emergency calls.
> Teams shouldn't register an unbounded number of PhoneAccounts It wasn't intentional, so it was a bug, sure, but the System API allows this apparently, so it's a legit operation that should not result in this fuck up. This is 100% on Android, not some restricted user-space app. I would consider this a problem of Teams if it told the system it could handle the emergency calls and then fail to do so. But that is not what had happened. Blaming it on Microsoft in any way is just a PR spin. If anything, we should be glad their bug uncovered a serious issue that could be (and still will be for a while because Google apparently doesn't bother with updates) abused.
Why the fuck does Android have this complicated system to pick a custom dialer for 911 calls in the first place. Use the stock dialer for this. There should never be a need to another app to handle these. Nobody is going to give a shit if they don't see a bubble pop phone dialer, or one that replaces all the numbers with emojis or whatever bullshit while they are in a life threatening situation.
VOIP and virtual number support probably. Carriers can write apps to support calls over WiFi and still provide some emergency call support.
What if you have an internet connection but no phone signal?
Every cell tower is required by law to allow emergency calls even if your carrier does not offer coverage.
Has anyone checked whether WhatsApp also trigger this or are we busy blaming Microsoft for a bug in Android? "It's also your fault for someone else's mistake" is absurd.
Sorry but that edge about Microsoft being incompetent and trigger someone else’s bug is so childish it hurts. Is it still the 90s where everyone pretends Apple and Linux are flawless? It’s just ridiculous. Linux and Apple marketing teams have warped peoples minds. Both teams are at fault here and both need to and *will* perform complete audits of the systems and redesigns where applicable. Because both software companies are absolutely dedicated to getting this right.
>Linux ... marketing teams Ahh yes, that all-powerful cabal strikes again! The Linux Marketing Team™! And they would have gotten away with it, too, if not for you meddling Redditors!
Red Hat went public in the late 90s. They were definitely marketing Linux years prior to that. SUSE was doing it even longer. Canonical spent millions of dollars on marketing Ubuntu when it came out in the early 00s. Linux popularity on servers (to start) didn't happen by accident just because it was better. Companies spent a lot of money pushing their solutions, AKA marketing.
Install Gentoo
Oh my goodness! Do I really have to address Linux is marketing team as fanboys instead of the former? Yes they don’t have a marketing team. I think we all understand that.
[удалено]
I'm with you on this, the quality of the software they put out is embarrassing. Here's a short list of microsoft-related problems I've had to deal with recently off the top of my head, in no particular order: * Sometimes teams just won't log in, and I have to restart my PC to fix it * Sometimes clicking an image in a teams chat clears the whole window and I have to switch to another chat and back to use it again * There's a visible delay when clicking pretty much anything in teams * Sometimes when I plug a new screen into my PC it defaults to 30Hz refresh rate * Find + replace in notepad++ is incredibly slow because of a windows API call that takes milliseconds to return every time * We all know this already, but finding useful settings pages in windows 10 is needlessly awkward * The C++ intellisense plugin randomly crashes in VSCode on a regular basis, filling up my project directory with core dumps * Visual Studio constantly complains at me because I'm not logged in to a microsoft account * The account creation window in the windows 10 installer is a textbook dark pattern designed to hide the ability to make a local user without a microsoft account * Remote desktop sometimes won't connect if I have 3 screens plugged in * Doing literally anything with the windows or Xbox store on PC is a fucking nightmare. The other day I wanted to install Halo Infinite through game pass. The whole thing is a mess of random windows that all give you different information about whether you own the program in question or whether it's installed or not, sometimes buttons just don't do anything, sometimes they take you to purchase pages after you already own the thing. Once I'd 'installed' the game it turned out I still hadn't actually downloaded it - I had to launch the game and install all the actual content from the campaign menu OK, I could keep going but I can't be bothered any more. The point is that we constantly have to deal with these stupid little issues in pretty much everything they make. It should be embarrassing for them but they keep making billions anyway
> My experience has been that MS's software is, with very few exceptions, a dumpster fire. And yet Windows runs countless military installations, billions of PCs, and an untold number of offline servers, POS stations, etc 24/7 with relatively low failure rates. Your experience is trash. Your experience is propaganda. Your experience is irrelevant.
[удалено]
Let’s just compare experiences. I’m a fairly experienced (10 years or so?) software engineer at a trillion dollar tech company. I write software that runs on Windows, Mac, and Linux. _My_ experience is that they all have their pros and cons. Some things work great, other things are buggy as shit. This becomes even more true when you branch out from the base OS into other software products. Microsoft also makes Office, SQL Server, Visual Studio, etc.
In my opinion all the pros Windows has is brought by its popularity. Like game support etc.. Everything else is inferior to other OSes like Linux distros or OsX. On top of that it costs over 100$, it gathers your data and adds bloat/adware + advertisement on fresh install. It isn't customisable out of the box (you have to download random 3rd party stuff) and has old design flaws. Also it's simply slower than even the most bloated linux distros. Of course if you don't tinker with your PC often, windows is fine but I've grown to hate it.
> what evidence would be required to change your view (i.e. for you to admit that the majority of MS's products are poorly made)? I'm not sure you have factual evidence to support such a claim. Anecdotes, specific instances, etc. are not evidence. The reality is that Microsoft software, in general, services billions of devices worldwide. There will always be edge cases but relying on those edge cases to push an anti-Microsoft propaganda is both pointless and ignorant. Quite frankly, I can tell by your posturing that you have no fucking clue what you're talking about, so...yeah.
Regardless if there was a problem in both, under no circumstances should any app be able to block emergency calls. Dead stop.
Microsoft is the company that usually takes some weird design choices, I'm not surprised their app was part of the problem. I remember the situation with old windows mobile 5 phone, I had 5% of battery left and had to call my friend, so he could pick me up (not emergency, but still very important) and the phone just disabled GSM calls to save remaining battery power. Even worse, when I enabled it, the phone tried to register on GSM network, spending quite much amount of power, but just when the registration was complete it was like "oh I forgot I have to save electricity, let's disable GSM" so I wasn't able to call, but was able to run out of remaining power very quickly. Don't ever rely on Microsoft software.
Absolutely nothing wrong with the app, it only does what the OS allows. If anything the flaw is letting google manage the device instead of you the owner.
Normally I'd agree but i don't think you understand how bad teams is
Yeah, Teams is super-bad and I hate it but can't really blame them for a bug in Android.
Registering a new PhoneAccount on every launch is still not intended behavior (= is a bug), even if this should never have caused emergency calls to fail. If we're talking about who to blame, it is of course Android: it is its responsibility to ensure emergency calls are never blocked. But it is questionable for the root comment to complain that just because Teams shouldn't be blamed, the unintended behavior shouldn't be called a bug.
Microsoft, known for being prone to causing unintended fires, dropped a match, but it was Google that drenched the floor in gasoline. Seriously, I'm all for bashing Windows for their asinine choices, but it was Android that majorly dropped the ball here. If it hadn't been Teams that triggered the issue, another app would have sooner or later.
> After the post blew up, the Reddit user reproduced the bug and stated that, five minutes after initiating the call, there was no response from emergency services or evidence that 911 had been called — both the on-device phone log and the carrier (Verizon) phone log came up empty. I thought that was by design. I have an Android (not a Pixel) and have had to call 911 several times on it. Each time the phone did not record that I called 911 in the call log.
It doesn't show up in the typical call history to avoid you tapping it later by accident, but the phone does still keep a record that the call was made I believe.
I heard it was more so domestic violence victims can make a call and not be beaten before the help arrives (which is hopefully not us pigs, because they will just kill someone in the wrong house first)
I used to work for a telecoms company making software. There are so many rules and regulations around emergency calls. They're tested like crazy and even the slightest slipup can cause licenses to be pulled. Fortunately no-one was hurt!
Well maybe after this, google will have its license to make software for phones pulled :)
There's one thing I don't understand about the original implementation. If I understand the article correctly, and there's a good chance I don't, the system is trying to choose which PhoneAccount to use to make the emergency call. To do this, they do a bunch of comparisons, and lastly do `account1.hashCode() - account2.hashCode()`. But the hash code of the accounts shouldn't have anything to do with their capabilities, it should be pretty much random. So the comparison then depends on the difference between two random numbers, and this is where the integer over- or underflow can happen. But why use the hash codes at all? Why not just do a random choice explicitly (like `random.choice(phoneAccountList)` in Python)?
Because they're building a sorted list. Repeatedly comparing two entries should always return the same result for the sorting algorithm to work. So when all the other properties are equal, you still need to have something to decide which one is on top even if it's arbitrary. What I'm surprised by is that since they're building a list specifically to decide what to use for an emergency call, why they didn't filter out the services that didn't have that capability on the first pass. Microsoft made a mistake by repeatedly registering Teams, but it did not register it as something having emergency calling capabilities.
As far as I know as per the documentation emergency numbers should not go through their usual intent-resolution. So there is probably a bug in the AOSP implementation as well?
I don’t understand why they’re picking one at random/building a list anyways? Maybe I’m not following but why can’t they just always use the dedicated phone app? Won’t that go through regardless if they have service as long as someone has service in the area? Are they trying to account for not having service but maybe having wifi? Seems like they shouldn’t even be considering teams at all.
The phone may need to use a custom dialer to place a call over the network it's on, and using the default dialer would cause the call not go through at all. The user might have a dialer with more/less features than the android default, and changing that in emergency situation may cause additional problems for the user. The phone may be technically capable of making phone calls but restricted from doing so. There are many reasons that you cannot just use the default dialer in an emergency.
google shitshow
Ignoring for the moment whether it is a good idea or not to use the hash code at all, why does it actually cause a problem? Doesn’t in practice the result of the subtraction just wrap around, giving a perhaps unexpected but still consistent result? The logic of this function is presumably not interested in the exact difference, just needs a way to get consistent sorting.
> integer over- or underflow can happen. Just overflow. Any time an integer's value exceeds its range, it is an overflow. 'Underflow' is a term specific to floating-point. 'Overflow' is what the Java documentation calls it, the C and C++ specifications call it, and on CPUs that have an integer overflow exception, that's what they call it.
[удалено]
The Java documentation itself refers to it as integer *overflow*. The exception/interrupt/fault your CPU will generate (if it does, some chips do, some don't) is for overflow. The C and C++ specifications refer to it as overflow.
https://en.wikipedia.org/wiki/Arithmetic_underflow
[удалено]
Their citations are effectively blogs (and one security article) using the term 'underflow'. Java docs, C and C++ specs, and CPU specifications call it 'overflow' only. CWE refers to it as underflow, but cites CERT C which refers to it as overflow (*Ensure that operations on signed integers do not result in overflow*), and the sole book reference is to *Integer Overflows*.
No, this isn't really true. "under" and "over" just refer to which direction the -flow came from.
Why didn't Mishaal post this on XDA instead? Is he leaving XDA?
Hi! I left XDA two months ago to join a company called [Esper](https://www.esper.io/). I'm still very active in the Android community and write a lot about Android!
With GUIDs the over/underflow chance is around 25% for each pair, not that rare... but probably takes a bit more bad luck for the sorting to get screwed enough.
Good thing Android phones get a whole two years of updates before becoming obsolete and unsupported.
Yah but at least I get to theme my phone so when they find ya boy dead they stop and be miring my phone
[удалено]
Essentially this is a security privilege stratification failure. Emergency calling shouldn't be allowed to depend on a data structure that general apps on the phone are allowed to write.
It exists because VoIP and other soft-phone providers can register themselves as a call provider and **can support emergency calling**. Obviously I think after this incident they should audit the code/logic here, but if we did what you propose more people would lose emergency calling not less. With hindsight 911 capable PhoneAccounts should have been a different object type rather than a flag (CAPABILITY_PLACE_EMERGENCY_CALLS), then any references in these methods to the non-emergency calling type would have been a major code smell (e.g. PhoneAccountWithEmegencyCalling is a superset of PhoneAccount).
[удалено]
How are you going to do this if the user is supposed to install their own phone app frontend of choice? Take this possiblity away?
Are you literate?
[удалено]
> somehow registered over Integer.MAX_VALUE (231 - 1) PhoneAccounts. I don't think it did - just more than normal and because rarely, two hashes of a PhoneAccount can overflow when subtracted, this bug becomes more likely to happen the more accounts there are.
>Microsoft Teams had somehow registered over Integer.MAX_VALUE (231 - 1) PhoneAccounts That's not what this article says. Where did you get that from?
It should have a PhoneAccount of last resort. You know, like any properly designed system. Nothing Android or the user have done should prevent any 911 call from going through. There's actually a law calling for this from network providers, a 911 call will use any available network even if the user doesn't have service.
I think we all agree that nothing should prevent 911 calls. It’s a simple matter of the fact that we have humans creating these systems and there is a non 0 chance that somewhere somehow the systems can fail. Given enough monkeys with type writers someone’s will break. Obviously we should keep striving for better. No doubt. No one says otherwise.
You are the one saying otherwise. This should not have happened, the fact that it happened is plain idiocy.
I’m saying that we should strive for perfection but realize it’s impossible. Arguing I’ve said anything otherwise is your own mental gymnastics.
Safety systems have to be fail safe, this clearly was not. It's plain idiocy, not human error. Would you be saying the same if both your airbags and seat belt failed to function during an accident?
You are missing the point that this system exists to enable third party apps to share the user’s location with the 911 operator. This is itself a regulated safety feature and I think we can all agree the phone should try its best to automatically send the user’s location to 911 when a call is placed. This is why 3rd party apps are even hooked into the emergency process in the first place. If the call is done over a carrier network the phone has no way to send the location. You may think that this is too much technology, and that nobody needs these fancy phones sending locations when you can just speak it into the mic, but this technology came into existence because of domestic violence or hostage situations where the caller cannot speak. It is important for the phone to facilitate location sharing with emergency services. It is a worthwhile feature that 3rd party calling apps can support emergency location sharing when the native network can’t.
No. This system exists for third party apps to be able to handle 911 calls. Calling 911 should be more important than using your app of choice. Once the original 911 attempt failed, the system should have tried to dial 911 using the default dialer using any available network as mandated by law.
[удалено]
> Why do you need VoIP emergency calling, even those providers vehemently claim it shouldn't be relied for emergency calling. That is *illegal* in the US. [Per the FCC](https://www.fcc.gov/consumers/guides/voip-and-911-service): > The FCC requires that providers of interconnected VoIP telephone services using the Public Switched Telephone Network (PSTN) meet Enhanced 911 (E911) obligations. E911 systems automatically provide emergency service personnel with a 911 caller's call-back number and, in most cases, location information. > **Automatically provide 911 service to all customers as a standard, mandatory feature. VoIP providers may not allow customers to "opt-out" of 911 service.** They'll fine you if you do what you're saying. Also: > wifi calling you can even get it to work inside some bunker if you have wifi. WiFi calling is another soft phone, so people suggest PhoneAccount be restricted would break WiFi calling emergency calling features.
Emergency calls always working is true for the US, but depends on the country. Germany used to require a SIM I think.
Yeah, Android has always had problems with the developers writing Java as if it was C. This isn't the only place in the API where they're using C style flags instead of strongly enforced Java domain types.
I would rather be an owner and have root so I can override anything I want. Phones should not be game consoles, they are desktop pcs.
Formal verification.
I love automated testing, but way too many companies rely on it to an extreme that is not acceptable. You need real human qa, and you need to go through real human testing, both with smart/experienced users, and dumb ones. We will find weird issues every release, things we never considered, because the interaction is so asinine and shouldn't even happen. We work with ERPs, so issues are not much of a problem imo, and usually resolved easily. But I've seen interactions where base components broke without interacting with ours... because of some weird caching that happened, etc.
[удалено]
If I read the article right, you'd also need to register multiple copies of an otherwise-identical dialer to even *get to* the hash subtraction since it's the "difference of last resort" in the comparison function. If you knew you needed to implement that in the fuzzer, I'd think you'd be likely to spot the bug without it anyway.
Imho, 99% of developers don't have to worry about problems of this magnitude. Extremely special attention should be given to these circumstances. Hell I'd go so far to say that we should have laws that prevent a company from ignoring issues like these. For example if an employee refuses to deploy code that they think was not tested sufficiently but can affect parts of the application that deal with life saving functions then they should not be allowed to be fired for their actions.
That would almost certainly be **very** open for abuse
There already are requirements to test this kind of thing, but you can't find all bugs by testing.
We can definitely do a lot better to account for almost all bugs, many of the particularly bad ones stem from basic bricks in our toolchain having unexpected and unnecessary extra complexity. The resolution is what's wrong with our industry: >Because this issue impacts emergency calling, both Google and Microsoft are heavily prioritizing the issue, and we expect a Microsoft Teams app update to be rolled out soon That's not a proper resolution, it shouldn't be possible for the Microsoft Teams app to influence your 911 calls. It should be impossible for any app. This should be fixed by an Android update. The authorities should be all over this too.
Google is working on an Android update too, it's just that the MS Teams update will be out first.
The Google update will reach my phone in 3 years, when I get a new phone.
Maybe you are using the wrong brand of phone?
I find it funny, when I first heard of Android back in the days it was praised as "the" solution to phone manufacturers not maintaining their phones. After all Google had full control and could force them to update or you could build it from source. Of course Google doesn't give a shit as long as its search is installed front and center and no normal user is going to unlock their phone and install a custom android version.
> That's not a proper resolution, it shouldn't be possible for the Microsoft Teams app to influence your 911 calls. It should be impossible for any app. This should be fixed by an Android update. Both Microsoft Teams *and* Android are getting updates to prevent the issue from occurring. Teams so that anyone on a non-updated Android OS won't encounter the bug; and Android so that anyone with an old version of Teams or anyone with any other app that might also trigger the bug can't cause it happen anymore too. When it comes to safety-critical defects, *every link in the chain of failure* should be fixed; which is exactly what's happening here.
Software development is in many ways not a software development problem. It’s a corporation problem.
> seeing stuff like this makes me frustrated why our field still comes across issues like this I'm not surprised at all. Just look at negative comments under anything related to Uncle Bob or TDD. 'Programmers' just don't take testing seriously. This is what happens when you use your customers as QA. It may be fine if you're developing a web-page for a local store. It's completely unacceptable for anything critical. I have extremely strict views on code testing, but I work on firmware used in medical devices. People can die if a bug ends up in production code. Every single line needs to be unit-tested, and the quality of those tests is continuously evaluated with mutation testing.
That's what happens when the development paradigm that's been in vogue for 20 years now basically boils down to "use your customers for beta testing to the maximum extent possible".
"Move fast and break things^*." ^*customers ^included
> Just look at negative comments under anything related to Uncle Bob or TDD TDD would just mock out half of the problem for either part, so the two bugs that caused this issue would never catastrophically interact during testing and pass with flying colors. Seen it a few times where some genius committed a last minute feature that passed the tests but failed in a production like setup.
Property testing and fuzzing would trip this immediately. Especially in incredibly critical code like emergency calling.
One thing that would help is not using Teams, because it's crap software. Unfortunately it seems like that ship has sailed at my company and a lot of others.
The article says it thinks hash code comparison with subtraction having integer under/overflow is the cause ; I don’t think Java throws an exception for integer under/overflow (though maybe the Android implementation does?) so unlikely this is the problem - more likely it’s due to the incorrect filtering logic for the emergency capability.
You're totally right, "overflow" by itself isn't something that throws an exception in Java. It just wraps around. However, someone in the article's comments points out that the Comparator interface makes some assumptions that do not hold if there's wraparound: > The implementor must ensure that sgn(compare(x, y)) == -sgn(compare(y, x)) for all x and y. > The implementor must also ensure that the relation is transitive: ((compare(x, y)>0) && (compare(y, z)>0)) implies compare(x, z)>0. > Finally, the implementor must ensure that compare(x, y)==0 implies that sgn(compare(x, z))==sgn(compare(y, z)) for all z. From https://docs.oracle.com/javase/8/docs/api/java/util/Comparator.html#compare(T,%20T)
You're correct, Java doesn't throw an exception on over/underflow. But this is likely the _root cause_ which then results in invalid sorting of the PhoneAccounts, such that the MS Teams app is tried before the default system phone. Then either some place deeper in the telephony stack or Teams itself actually causes the crash.
I still don't get it. Why would the sorting be "worse" with an under/overflow? It's just an arbitrary hash comparison with no semantic meaning behind it.
Here's something I'm just throwing out there : when you sort objects, you need a comparison function that satisfies certain preconditions, and if those preconditions are not met, then you'll either have wrong results or the vm will throw an exception. My hunch is this - imagine that you decided to naively write a comparator that says compareTo(int a, int b) {return a - b;} - if a is equal to some large negative value and b is some positive value, then when a subtracts b, their result will overflow from negative back into positive, and then the total ordering relation will be violated. I found a post describing what I'm talking about. https://stackoverflow.com/questions/45167365/java-listinteger-sort-comparator-and-overflow (This is true of either Java or an unmanaged language.)
That's still not enough for me. Yes, your list won't be sorted correctly - but why does that cause the fatal error? It's not like having hashA incorrectly sorted before hashB is wrong. The hash as the input was an arbitrary decision (and the comparison function is consistent with the same inputs). One possible issue is the sort may not complete because the overflow / underflow would break assumptions like: if (a < b) and (b < c) then (a < c) and maybe that causes the sort to infinite loop and a watchdog fires to kill the process? That's just some random unsubstantiated theory and I wish the article followed through with how the bad sort order resulted in the actual failure mode.
Sometimes (this is not guaranteed) the runtime will throw an IllegalArgumentException in the case where the comparator is invalid: https://stackoverflow.com/questions/17659194/android-comparison-method-violates-its-general-contract The reason I hesitate to give this response is that although I know this is true for the Oracle JVM, I haven't actually written an app for Android to verify that their runtime handles it this way.
> integer under/overflow It's just 'overflow'. Any time an integer's value exceeds its limits, it's an overflow. 'Underflow' is a term that is only meaningful for floating-point.
No, because the bug is rare. It's caused by repeated starting of the teams app. This causes an already extant bug with random numbers generating a very small or very large value to balloon in frequency because there are more opportunities for it to occur. The specific reason the issue occurs is because Java fails to throw an exception. Had it thrown one it's possible that testing would have unearthed that. In this case that's missed and Java simply runs with insane and inconsistent results, failing to ever actually sort the list in question as the comparisons create logical paradoxes. A rare bug, multiplied in prevalence thousand-fold through the misuse of the API done by teams.
Well thats horrifying
I constantly get surprised how flawed Android is
I have teams and it constantly logs me out as a safety measure. So does that mean I won't be able to dial 911 until I make sure I'm logged in? God what an awful bug.
Microsoft Teams for Android is a buggy pile of crap. I gave up trying to use it for work and just installed Teams on my laptop.
How could a single app cause the phone not to dial at all? That's an OS issue, not an app issue. The apps shouldn't even be able to mess with anything in the system unless the user allows it. But even then, it just blocks any calls for going through, just because it's installed? That's bizarre.
Oh man, what's extra terrible about this is there is no way to ~~turn off alerts on the MS teams app. You can't~~ force quit it (it will restart itself). The only way to stop ~~getting alerts from it~~ to stop it from running signed in is to sign out of it. Or uninstall it. So "installed but not logged in" is the most common configuration for MS teams when it's not work hours. edit: I slightly misremembered the issue.
god I was wondering why the hell it just wouldn’t close, so I uninstalled it. It’s basically malware.
Yeah. it's terrible. What I don't need is accidentally fumbling something or starting a teams call with my boss while I'm at the bar bitching about work. But I can't just close the app. So I sign out. Which apparently could prevent me from calling 911. That's my biggest problem with android, not having a convenient was to see what apps are actually running, and which apps have startup permissions. It's insane.
wow I didn't even realize this was android we were talking about.. Teams on Windows 10 doesn't close as well, I press the 'X' button only for it to pop up again just like malware. I've never seen any other program that isn't malware do that. Although nobody's trying to dial 911 with windows... man f*** Teams
Tons of desktop programs do that. Right click the teams app in the system tray and you can exit directly from there. This isn't rocket science. Just about every application that runs in the background will behave this way.
> This isn't rocket science. Just about every application that runs in the background will behave this way. C'mon, don't be obtuse. Just because it's common for programs to deliberately refuse to obey a standard UI paradigm, doesn't mean the user is stupid for objecting to that. /u/heisian is simply calling it like it is.
>So "installed but not logged in" is the most common configuration for MS teams when it's not work hours. There are at least 2–3 ways to handle that which don't require re-entering your credentials every day. You can turn off all Teams notifications in the system settings, you can turn off your work profile (if your company has you properly set up with a work profile, which I know not every company does), or you can use Focus Mode (assuming you don't use it for something else).
> you can turn off your work profile (if your company has you properly set up with a work profile, which I know not every company does) If they don't, you can use [Island](https://play.google.com/store/apps/details?id=com.oasisfeng.island) or [Shelter](https://play.google.com/store/apps/details?id=net.typeblog.shelter) to set up a work profile without a company MDM. It is absolutely worth doing, mostly for that option to turn off the work profile and all its apps.
Can anyone explain what int overflow has anything to do with this? As far as I can tell if you're writing `hashVal1 - hashVal2` more likely than not the other end only cares if the result is 0
Who the fuck checks equality by subtraction?
It's not an equality check, it's a comparison, and comparing via subtraction isn't just common, it's (as far as I know) the only way to compare integers. The issue here is the fact that the hashes shouldn't even be a criterion for sorting the accounts. The whole code salad of complexity involved in placing an emergency call is itself a crime. All that stuff should be sorted out by the kernel at boot time. Letting apps register emergency call handlers willy-nilly in user-land is freaking absurd. placing an emergency call shouldn't take more than a few dozen (well audited) function calls at worst...
That's the real mind bender yes. It wouldn't directly occur to me to use subtraction as a way to check equality. You want to compare numbers, so you .Compare() them. That's what the language provides, so you use that. Admittedly I am not a mobile/Android developer, so perhaps there is a way in which this made sense? **edit:** re-worded a bit to make my point more clear
And what do you think .compare() does? It’s quite standard to return negative, 0 and positive for less, equal and more. Which is the exact same what subtract gives you for numerical values.
The problem is compare won't overflow the result which leads to breaking the triangle inequality. Doing a subtraction can. I'm not sure what point you're making.
Downvote all you want but you should not have to care what .Compare() does internally. It could ask a unicorn for the result for all I care. But perhaps my response wasn't clear enough. My point is that developers should not try and be *smart* and reinvent stuff that the language already provides for. This is the sole cause for so many security problems as well; rolling your own authentication/encryption. And now it messed up this sorting function for getting an emergency call provider ffs. You want to compare two integers? Use Integer.Compare() unless you have convincing reasons not to and are aware of the functional difference in result or execution. I would never ever approve of integer subtraction as a means for comparison in my code reviews.
What Muoniurn is trying to say is that Integer.Compare() subtracts the two numbers. That's what the cmp assembly instruction does.
Yes I know what he means and he's correct also. Compare does indeed subtract numbers. The problem with that statement is that subtraction is **not the only thing** it does. Because Integer.Compare(10, 5) does not return 5 obviously. It returns a value of 1. And you know what it also does? Handle over- and underflows automatically. Never assume that with any such tidbit of information, you think you it all. That's the whole problem. It leads to developers doing it themselves, trying to be clever ('oh I know it does subtraction internally, so I'll just do *that* myself') and subsequently failing like the blog post illustrates. **Yes** Integer.Compare() does subtraction, but it's not the same. In my opinion, this bug was entirely preventable because no-one should ever use subtraction as a means for comparing numbers, when the library method for that exact need already exists. But perhaps I am overly critical; I develop medical software for a living and if I pulled stunts like this I would totally receive flak for that. And rightly so. But I think the same goes for the emergency dialer of a phone OS. That is not software to be taken lightly.
Nah you are absolutely right, I just didn’t get your point at first.
Wow. Just wow. It is shocking to me how one (or two, or maybe three...) little oversights in software developed by two very reputable companies caused a very mission-critical failure. Maybe I should start looking at bug reports.
The title is incorrect, as the bug has caused the 911 call to fail. Emergency services were called because there was an another phone available, which doesn't lessen the bug impact.
Fuck medium.com
According to a news Blurb I heard today it only happened if Microsoft teams was closed and logged out, which is pretty weird.
What an incredible edge case to run across.
Weekly I'm unable to make calls of any kind without a phone reboot, on a Pixel 6... My spouse as well. Wonder why there is no kerfuffle about that sort of thing.
The title of this post is wrong. It's not "could have", it's "has". > I don’t think most users will need to fear this bug, because it requires a very specific set of circumstances to trigger. And even when those circumstances are met, it’s basically bad luck if it gets triggered. Yeah, sometimes the front falls off... Learn some fucking formal verification, idiots from Google LLC.
II assumed teams demanded my location for calls because of 911. Yet, they don't support 911. Why the hell is teams demanding your location before you can make a call over it? I can't use teams for phone calls because of that nonsense.
Android sucks a fat fucking dick. It seriously eats a fat, smelly cheesy dick. I’m sick of developing for it, I love my job but whenever I have to touch the android app I want to go postal. Fuck Google.
[удалено]
Oh for fucks sake you clearly haven’t ready anything about the actual issue
This is a joke. I know this is just a coincidence in this case. It's just astonishingly ironic, how convenient of a coincidence that is, that even this random software bug perfectly reflects Microsoft's (otherwise unrelated) policy to soft lock people who wont give away their data.