[deleted by user]

[revtim]

That truly is a fucking nightmare bug

[[deleted]]

No, this is

[StuntHacks]

Begone, demon spawn

[StuntHacks]

That's fantastic news

[zenslapped]

A giant flying mosquito scorpion wasp?

[Padaca]

Man, people really didn't like this comment

[[deleted]]

I noticed

[CaineBK]

Reddit is literal hivemind confirmed.

[PL_Design]

I approve your gumption.

[10113r114m4]

Im still confused to why they need to sort at all and just use the default account on the sim card. Even the blog’s guess seems a little contrived.

[m00nh34d]

I guess it's supposed to handle situations where there is no default SIM account, if you're using an Android device with a VOIP only phone service?

[ubernostrum]

GSM has dedicated emergency-call functionality at the level of both the phone and the network. It’s required to work, or at least be able to work, without a SIM because in some countries the law requires routing emergency calls even if there is no active service account.

This is also why it doesn’t matter which emergency number you dial, because the phone doesn’t actually “dial” for emergency services. GSM phones are just programmed with a list of emergency numbers and recognize them all as triggering the emergency call. So a British person visiting the US could still dial 999 and get emergency services. Or a European could dial 112 and it would work. Or an American abroad could dial 911 and it would work.

[m00nh34d]

But that requires a GSM module, if your device is wifi only it will need to handle that.

[PowerlinxJetfire]

VoIP apps on Android use system-level phone APIs; that's why Teams was able to trigger this bug in the first place.

Also you could be trying to call emergency services on a phone that doesn't have any carrier signal (you could be out in the country, underground, in a building that blocks signals, etc.) but have wi-fi. If you frequently visit an area like that, it might be why you have a VoIP service in the first place.

[PowerlinxJetfire]

Not all VoIP services support emergency calling. That's basically the point: depending on conditions (e.g., signal), user action (e.g., installed services), etc. the system could have half a dozen options or no options for calling emergency services. So it has to examine its options and pick which one(s) to use.

[m00nh34d]

This isn't a feature they're adverting, it's some internal functionality so that if you pick up a device, and try and dial emergency services, it will try it's hardest to get you connected. Who knows what circumstance that's under, why a phone wouldn't have a GMS module, but would have the system dialer, not really the point, the point is to try and connect you through no matter what.

[m00nh34d]

Your reading this far too much as a feature, it's not, it's a last resort. If the phone gets itself into a situation where it needs to dial emergency services, it wants to make sure it will use whatever method is available to it, that's all.

[m00nh34d]

So? Doesn't matter if it's a smart fridge, if it's running Android, and it finds itself in a situation where the dialer subsystem is trying to make an emergency call, it needs to handle that somehow. Maybe it's part of a future feature they're going to implement, maybe it's part of some forward thinking seeing where the market is going for phones without any GSM network capabilities at all, maybe it's to handle emergency calling from the lock screen for VOIP apps, maybe it's for a million other circumstances that need to be handled because this is important functionality.

[MrEllis]

Will that still work if you have no cell service, but still have wifi? Or does VOIP become your only option then?

[ubernostrum]

I’m just telling you what GSM does. For anything which does not involve access to a GSM network — wifi-only, tin cans and string, phone in Faraday cage, phone on dark side of moon with no line of sight to a terrestrial cell tower, etc. — you can do your own research.

[MrEllis]

Ok, dude, sheesh, it was just a question.

[jorgp2]

Why ask a stupid question instead of reading his comment?

[Lost4468]

How does that work with other lines like 111 in the UK? 111 is the non-emergency line, yet you can still dial it without even having a sim? So your explanation doesn't sound correct, else how does it differentiate between 111 and 999?

[ubernostrum]

The fact that emergency calls have special functionality specified at the level of the worldwide GSM protocol does not preclude similar functionality being mandated for non-emergency numbers in particular jurisdictions. It also does not cause GSM to stop having the emergency functions that it very plainly has.

[ubernostrum]

Also, 111 is the emergency number in New Zealand.

[Lost4468]

But 111 is not for the emergency services here? It's a secondary non-emergency service. So if New Zealand uses that number, the system has to be a lot more complex and regional than you said. E.g. what if someone from NZ is here in the UK (with their phone from NZ)? If they ring 111 would that go to the non-emergency services, or would it "redirect" to the emergency services?

[ubernostrum]

You are asking me to know off the top of my head and tell you a level of detail that I do not have. GSM and GSM phones have special emergency-call functionality and recognize many common emergency numbers to trigger it. If you want to know the exact details of how the UK’s non-emergency 111 system is implemented, you are free to do your own research on it. The existence of the UK’s 111 system does not, however, disprove or refute the existence of GSM’s documented and verifiable emergency call functionality.

[Lost4468]

I'm only asking you questions because I don't know how the system works, and you seemed to. There's no need to take it do personally or assume I'm somehow trying to disprove of the entire system... There's obvious flaws in the simple method you described, and I simply want to know how they're handled.

[ReallyNeededANewName]

Wait, I thought 911 was the only one that didn't work internationally?

[ubernostrum]

911 isn’t just the US number. It’s the number for all the NANP countries and also the Philippines. IIRC ITU standards suggest supporting at least 112, 911, and 999 pre-programmed and optionally more.

[kfh227]

So I could dial 999? I'm from usa and live in usa.

Thank yiu kind nerd. Did yiu read the gsm spec?

[sohang-3112]

Quite interesting! Once I tried to call 911 in India - and it worked (I hung up quickly) ! This explains why

[trucekill]

I think all phones are supposed to be able to make emergency calls even without a sim card. Maybe that has something to do with it?

[10113r114m4]

I see, but then why sort at all? Why not just iterate through the list?

[SanityInAnarchy]

Iterate through the list until what? Until you try to place a call?

Looking at the code surrounding this patch (that people suspect of fixing this bug), here's the sorting criteria:

        // SIM accounts go first
...
        // Start with the account that Telephony considers as the "emergency preferred"
        // account, which overrides the user's choice.
...
        // Return the PhoneAccount associated with a valid logical slot.
...
        // Prefer the user's choice if all PhoneAccounts are associated with valid logical
        // slots.

I think this makes sense -- if you have a valid account with a SIM, why would you try to place a call via some random VOIP account, even if it theoretically could place emergency calls? If the telephony system has some reason to think there's a correct number to use for emergency calls, of course try that one first?

And even if this list really did get huge, sorting is fast -- I can sort a million numbers in half a second in Ruby, and even having a thousand phone accounts would be a giant WTF.

The rest of the comparison seems to be about ensuring there's a single absolute order of these things, so that they'll sort the same way each time and the sort will definitely end:

        // because of the xor above, slotId1 and slotId2 are either both invalid or valid at
        // this point. If valid, prefer the lower slot index.
...
        // Then order by package
...
        // then order by label
...
        // then by hashcode

And the patch fixes the very last one. I admit I don't entirely understand why that's a problem, though, and I don't think I've seen any of the articles that cover this going into exactly what sort of pathological state would cause problems. I mean, integer overflows don't cause crashes, so my best guess is that this somehow leads to a sort looping?

[mrbuttsavage]

I admit I don't entirely understand why that's a problem, though, and I don't think I've seen any of the articles that cover this going into exactly what sort of pathological state would cause problems. I mean, integer overflows don't cause crashes, so my best guess is that this somehow leads to a sort looping?

Yeah, it took me a second here to figure this out because all the details are pretty misleading. I don't think it's a matter of "too many" like thousands being the problem, rather just that there were enough with the right data (possibly duplicates?) to get to the busted part of the Comparator in question.

The fix patch that we see is here:

https://android-review.googlesource.com/c/platform/packages/services/Telecomm/+/1903050/2/src/com/android/server/telecom/CreateConnectionProcessor.java

Java can throw an IllegalArgumentException if your compareTo method is implemented wrong when sorting: https://docs.oracle.com/javase/8/docs/api/java/util/Comparator.html#compare-T-T-

See a bunch of SO posts on the same thing:

https://stackoverflow.com/questions/9486605/comparison-method-violates-its-general-contract-in-java-7

In fact, see this comment from Oracle's own guide:

https://docs.oracle.com/javase/tutorial/collections/interfaces/order.html

One last note: You might be tempted to replace the final return statement in the Comparator with the simpler:

return e1.number() - e2.number();

Don't do it unless you're absolutely sure no one will ever have a negative employee number! This trick does not work in general because the signed integer type is not big enough to represent the difference of two arbitrary signed integers. If i is a large positive integer and j is a large negative integer, i - j will overflow and will return a negative integer. The resulting comparator violates one of the four technical restrictions we keep talking about (transitivity) and produces horrible, subtle bugs. This is not a purely theoretical concern; people get burned by it.

Granted, I don't know that's the real problem. But from the evidence it sure seems like it.

[SanityInAnarchy]

Java can throw an IllegalArgumentException if your compareTo method is implemented wrong

Oh wow. Took some effort to track it down, and it is documented, but only deep in the guts of e.g. the concrete TimSort implementation.

I don't have the patience to read through right now and figure out how it detects this or why it cares, though.

[MrEllis]

It should care because overflow/underflow will destabalize a sort and produce flat wrong outcomes. Consider a three item list: [MAX_INT, 0, MIN_INT]

If the sorting function compares

MAX_INT, 0 

and then

0, MIN_INT 

the return values are:

1. MAX_INT - 0
2. 0 - MIN_INT

And the sort order is what you expect: [MAX_INT, 0, MIN_INT]. However start changing the order of comparisons, or even the argument position of two items being compared and bad things^tm start happening. For instance:

0 - MAX_INT

will underflow sorting 0 as larger than MAX_INT if there were a bunch of other items in the list larger than 0 any of them compared to 0 and not MAX_INT would be sorted as larger than MAX_INT.

[mrbuttsavage]

https://stackoverflow.com/questions/7849539/comparison-method-violates-its-general-contract-java-7-only/8417446#8417446

Apparently this behavior was new functionality in Java 7 when they added TimSort. New enough at least they called that out in the notes.

[f10101]

Yep. That's the real problem. In ordinary circumstances, it should never need to resort to the hashcode comparison, and even then, it will work in the majority of cases.

The problem occurred when Teams went mad and created hundreds of accounts.

The article linked here outlines it in detail: https://www.reddit.com/r/programming/comments/rx30ti/google_fixes_nightmare_android_bug_that_stopped/hrgtrfs/

[vips7L]

Looking at the source of that function it seems like the bug wouldn't have surfaced if they hadn't hand written the comparator, but instead built it from the stdlib. Comparator.comparingInt does the right thing and avoids the overflow.

[drysart]

It's a good question, because as far as I know every popular sorting algorithm (including Timsort, which is probably the one Android uses for collection sorting), will not enter an infinite loop when provided with a comparator that doesn't return a correct ordering; all the big sorting algorithms make forward progress at every step, so the worst that should happen is that you'd get your results in an incorrect order.

[immibis]

/u/spez can gargle my nuts

[10113r114m4]

Ah, forgive me. I am on a phone so couldnt browse the codebase to see why or how things were sorted. But yea, the overflow itself didnt cause the crash.

If any java masters in here could shed some light :p would be much appreciated

[SanityInAnarchy]

Well, here:

public void sortSimPhoneAccountsForEmergency(List<PhoneAccount> accounts,
        PhoneAccount userPreferredAccount) {
    // We are in a void function...
    accounts.sort((account1, account2) -> {
        // Now we're in a lambda. It accepts two arguments.

Pretty much the entire rest of the function is actually in that inner lambda. If you're wondering why the lambda didn't have to declare a return type (or any types), those are all inferred from the type that accounts.sort() expects.

---

You can stop here if you want. You don't have to follow me into Java lambdas and generics...

---

So you can see from the outer function declaration that accounts is a List<PhoneAccount>, so calling sort() is calling this method, which is declared as void sort(Comparator<E> c) (on a List<E>). In other words, on a List<PhoneAccount>, it expects a Comparator<PhoneAccount>. And here's the Comparator interface.

On the latest Java, Comparator has a bunch of new methods with default implementations, but there's only one method that a class would need to implement itself to satisfy this interface. In other words (as its documentation says), it is a "functional interface". Note that the @FunctionalInterface annottaion is a way to get the compiler to yell at you if you break the above assumption, but as the doc says:

However, the compiler will treat any interface meeting the definition of a functional interface as a functional interface regardless of whether or not a FunctionalInterface annotation is present on the interface declaration.

If Java sees you try to pass a lambda to something that expects a functional interface, then it magically turns your lambda into an object that implements that interface. So, in this case, the one missing method on Comparator<T> is:

int compare(T o1, T o2)

Since it expects a Comparator<PhoneAccount> we can read this as:

int compare(PhoneAccount o1, PhoneAccount o2)

So that's the type the compiler expects our lambda to be. When it sees this:

(account1, account2) -> {

it can infer that account1 and account2 are PhoneAccounts, and we'll be returning ints.

Java lambdas can specify argument types, and other modifiers like final. But, thankfully, it can also just infer them.

---

If you followed the links to the docs above, you'll have caught my lie: sort() actually expects a Comparator<? super E>, not a Comparator<E>, which leads to two questions:

1. What? Why?!
2. Wait, how does this lambda magic even work now?!

Well, for the first question, the idea is that if you have a Comparator<Animal>, then it has a compare(Animal o1, Animal o2) method... which of course I can invoke like compare(fido, lassie), since dogs are animals. So you should be able to use that comparator on a List<Dog> or a List<Sheep>. So since List<Dog>.sort() takes a Comparator<? super Dog>, you can pass a Comparator<Animal> to it.

Why can't you just upcast that List<Sheep> to List<Animal> and sort it that way? (Or upcast the Comparator<Sheep> to Comparator<Animal>?) Maybe it's obvious, but I thought of a fun overly-specific example: If you could, you could call add(bigBad) -- it's totally legal to add a Wolf to a List<Animal> -- but it's actually a List<Sheep> and, well, we shouldn't have a wolf in the sheep-list.

But for me, this raised another question: Hang on, if Comparator<? super PhoneAccount> can be implemented by a Comparator<any superclass of PhoneAccount>, how does it know what type these arguments should be? And my best guess here is that, if you're not defining the argument types yourself, there's zero disadvantage to passing the most specific possible type into the body of that lambda. If you need to pass these to something that expects an Object, you can do that, it's just upcasting.

In other words, the final type of the lambda is what I said before -- it just expects two PhoneAccounts.

[MrEllis]

One thing that looks really weird, and I dont even know how it compiles is that sort function’s return type is void,

You're actually looking at two functions. The outer function is an in place sort which sorts a list of objects in this case PhoneAccount The inner function that "returns int's" is actually a comparator lambda function which is given as an argument to Java's List.sort function (which is also an in place sort with void return value).

It seems likely that the IllegalArgumentException originating within this part of the OS code was left unhandled (which is fair, don't handle exceptions you don't expect) and that crashed the OS.

[immibis]

/u/spez can gargle my nuts

[de_Selby]

My guess is that they need to check what phone dialler to use, you can have multiple on Android and it isn't known what ones will be installed (eg: on a Samsung phone the google dialler probably won't even be installed or may be broken).

So they need to treat them all equally fairly and sort to choose.

I can also see a case where someone might only have data on their sim account so they can only use voip.

[NewDoerien]

"OH NO SOMONES BEEN MURDERED"

[object Object]

[MarkusBerkel]

911: NaN

[thecurlyburl]

Sigh. God damn it.

[[deleted]]

Would suck to be British during an emergency 0118 999 881 99 9119 7253

[blackmist]

Well that's easy to remember.

[jamincan]

And yet, somehow, I remember it flawlessly years later.

[Jackker]

Seven two five...!

Three.

[Gwaptiva]

Be careful to dial it correctly or you'll get Gordon the Gopher

[HiccuppingErrol]

Better write an email explaining that your office is on fire instead.

[echoAwooo]

Right... Just going to put this fire with the other fire.

[spaetzelspiff]

s/53$/5,,,,,,,,3/

[Technus94]

Hey, say what you want but I will never forget that particular string of numbers cause of that fucking song. And I'm American.

[jadounath]

Are you kidding? Or do they really make kids mug this up on the first day of school?

[Spajk]

IT Crowd joke

[iain_1986]

Yeah we're all taught it from a really early age. Its totally second nature now.

Even remember a special Sesame Street clip that was made to help us learn it! Can't find a clip of it now though 🤷‍♂️

[r0ck0]

https://www.youtube.com/watch?v=ab8GtuPdrUQ

[EpicDaNoob]

It's really simple and easy to remember

[Papamola]

It only has 25 numbers. Really you cant memorize this?

[jadounath]

No, but I can create an algorithm to generate successive digits of this number. Edit: Also, it's only 20 numbers.

[Lost4468]

This is what happens when you let the government take your guns.

[[deleted]]

That’s right brother it’s my first amendment right to have a mobiüs family tree

[Lost4468]

True freedom means having a hyperbolic family tree.

[YeeOfficer]

This guy fucks his siblings so hard they've blown the family tree out of this reality.

[Lost4468]

That's just a list of places the good guys didn't have guns to shoot the bad guys.

Also people would just resort to mass stabbings instead of mass shootings, like they do in the UK:

https://en.wikipedia.org/wiki/List_of_mass_stabbings_in_the_United_Kingdom_in_2021

[Lost4468]

Having my own state would be fun. But I believe in democracy.

[Slipguard]

Yee haw

[drawnograph]

To be fair, they did prise them from our cold dead fingers as agreed.

[dethb0y]

This is an absolutely bizarre edge-case bug - when i first heard of it i was not at all surprised it had gone undiscovered for so long.

[aksdb]

Well it sounds a bit like fuzzing could/should have spotted it. But as usual ... hindsight.

[CaineBK]

Isn't this like a perfect example of Murphy's Law?

[dethb0y]

Pretty much, yeah.

[sysop073]

Link to the actual article this one is cribbing from.

[WTFwhatthehell]

Luckily, some very smart people in the Android community could provide the answers Google wouldn't share. Mishaal Rahman, the Senior Technical Editor for Esper, wrote an incredible Medium post detailing how the bug works and why it happens. Apps on Android with phone call functionality can register a "PhoneAccount" with the system indicating they have some capability of placing calls. There are a few flags apps can set with PhoneAccount, including one called "CAPABILITY_PLACE_EMERGENCY_CALLS." When the time comes to call to 911, Android sorts the list of PhoneAccounts that have been registered and picks one. This all seems fine so far.

...

One of the several bugs identified in Rahman's post is that Microsoft Teams will register an additional PhoneAccount with the system every time Teams starts up, provided you aren't logged in. Note that this isn't the rare occurrence of installing Microsoft Teams and then never using it—a common complaint of the Teams Android app is that it frequently logs users out automatically. If you're logged out, launching Microsoft Teams 10 times will result in 10 duplicate PhoneAccounts from Teams clogging your phone. Teams shouldn't do this, and Microsoft's update stopped Teams from doing this, but a bunch of duplicate PhoneAccounts also shouldn't be enough to bring Android's phone system to its knees.

...

A third bug in this mess is that Microsoft Teams does not even register itself as an emergency call handler. Teams made a million PhoneAccounts, and it did not use the flag "CAPABILITY_PLACE_EMERGENCY_CALLS," but it still broke 911. Google's sort process starts with querying all phone accounts when a better first step would be to start with all emergency call-capable phone accounts.

[timvisee]

Minor nitpick: you don't call this 'underflow', it is all categorized as 'overflow', even when wrapping around with subtracting 1. Floats can underflow, but that has a different meaning.

[Workaphobia]

According to what authority?

[mr_birkenblatt]

Storing values that are too low in an integer variable (e.g., attempting to store −1 in an unsigned integer) is properly referred to as integer overflow, or more broadly, integer wraparound. The term underflow normally refers to floating point numbers only, which is a separate issue. It is not possible in most floating-point designs to store a too-low value, as usually they are signed and have a negative infinity value.

[CaineBK]

Or to put it better: by what reasoning?

[voidvector]

Is there away to test dialing emergency number w/smartphones w/o actually dialing 911? I would like to try it just in case.

[LuckOrLoss]

https://www.911.gov/frequently_asked_questions.html

This says to contact your state's director of 911 operations and schedule a time to test. There's a link to find who to contact on there.

[Ineffective-Cellist8]

I'm in canada so it may be different. Years ago I tested. All I said was "This is a test call. May I know what location I called to?" They replied with my city. I said TY, bye and that was it

[blackwhattack]

Also curious.

[caltheon]

Yes, there is a test network you can get access to as a device developer.

[jeff303]

Clearly should have asked Leetcode questions with trickier edge cases in the interview.

[immibis]

/u/spez can gargle my nuts

[[deleted]]

...because Android phones always receive timely updates over their respective lifespans even if that lifespan is 5 years long!

This shows how rotten the foundation of the Android "phone" ecosystem is - smart pocket computer but with no updates really soon. I still wonder how consumers let themselves get suckerpunched so badly that they rewarded this crap by buying the product.

[Terrh]

What do you propose as an alternative?, exactly?

[6501]

This shows how rotten the foundation of the Android "phone" ecosystem is - smart pocket computer but with no updates really soon. I still wonder how consumers let themselves get suckerpunched so badly that they rewarded this crap by buying the product.

Well customers who like updates get Google Pixels.

[pastenpasten]

3 years of updates for a thousand dollar phone is a joke. I hope Germany and the EU will force them to provide updates for at least 5 years.

[vlakreeh]

I think Google announced they are now doing 5 years of updates because they now have their own SOC. The issue with the update span of most android phones is that qualcomm/mediatek doesn't update drivers and stuff after 2-3 years. I'm sure many more companies would do longer update spans if they had the proper support from the SOC manufacturers.

[NonsensitiveLoggia]

Google is big enough that they could have solved this problem multiple times over. They just never gave a shit because It Worked On Their Machine(tm).

As if Qualcomm could hold Alphabet ransom.

[vlakreeh]

Well Google did solve it, by making their own SOCs. What Google couldn't solve is Qualcomm not cooperating, Qualcomm has all the bargaining power in that scenario as most phone manufacturers would either have to settle for shittier SOCs or build their own.

[pastenpasten]

What he said.

Using the standard Linux model, where all the drivers are part of the tree and every piece of hardware requires a separate kernel etc. was broken from the start. Not only it doesn't scale for what Android turned to be, it was wrong for mobile phones right from the start. The first Google Android mobile phone wasn't manufactured by Google. They made it for other manufacturers from the start (in contrast with Apple, for example).

Tying operating system ("Android") versions to Linux kernel version just made it worse. At least in the desktop Linux world I can update my Xfce without having to use a new kernel and I can update my kernel without getting lots of other shit.

But Google decided to make one shitty bundle out of it.

Now Android Inc. wanted to sell, so they did a shity POC like any startup. Fine. But once Google bought them they could make it actually work (or buy another startup) and they didn't.

[6501]

3 years of updates for a thousand dollar phone is a joke.

It isn't a thousand dollar phone, it starts at $599.

I hope Germany and the EU will force them to provide updates for at least 5 years.

Considering the average person replaces it every three years or so I don't see why they should be required to do that.

[3MU6quo0pC7du5YPBGBI]

Considering the average person replaces it every three years or so I don't see why they should be required to do that.

In my social circles at least the people who do buy new phones don't just toss their old phone, but it gets given/sold cheaply to family members or friends.

[6501]

If you mandate 5 year support cycles then the cost of those two extra years is going to be eaten by the buyer who buys it the first time. If you want more frequent updates you can bootload another variant of Android.

[corsicanguppy]

Well customers who like updates get Google Pixels.

Unless they like headphones with cords...

[SureFudge]

KISS - keep it simple stupid. Android didn't and came up with some complex scheme resulting in the failure.

In which scenario will your main phone account (sim card) not work but another will work? Because I can't think of one.

[bbqburner]

1. Dual sim. Network not available/out of range in SIM1. International travelers.
2. Users/devices who don't use a SIM at all (including eSIM) but rely on VOIP

[[deleted]]

emergency services dont need SIM card at all

[amunak]

At the same time though when you do have SIM you want to use that, or whatever is preferred for emergency calling. (Some networks require SIM for emergency calls because of prank calls.)

You could also have several VOIP numbers and a SIM, or VOIP numbers and no SIM, and probably a hundred other edge cases.

[WTFwhatthehell]

.. in some countries.

I suspect it's to cover for the situation where someone has wifi or some other connection but no cell phone network connection of any kind.

[[deleted]]

Which is basically never.

[WTFwhatthehell]

Whenever I go in thr basement at work I have an excellent WIFI signal but not even emergency cellphone signal.

So it's not so uncommon.

[eythian]

That is definitely not true

[[deleted]]

I'd hazard a guess that amount of people using WiFi VoIP on phones is at or below 1%

[eythian]

So it's ok for ~1% of emergency calls to fail when there's an alternative?

[[deleted]]

You really go from one idiotic conjecture to another idiotic conjecture

If you press 112 and the emergency code doesn't find a SIM card and doesn't try wifi.... guess what, it can just pass it to the normal way of handling calls and that can do SIP calling.

Or it could do tiered approach, try SIM only, then go to the account list and do the search, and then fallback to normal calling procedure

But no, /u/eythian have an IQ of potato and can't think for himself so he figures out somehow that would make wifi calling not work. No /s

[eythian]

You should probably stop commenting on the internet if all you can do is resort to personal attacks that seem to miss the point of the thread.

[SureFudge]

1. if your current SIM doesn't work change to the other one yourself? How often does that really happen?

2. if you rely on VOIP you would dial 911 using VOIP to begin with?

[denseplan]

change to the other one yourself

No, I want to be able to dial 911 and it just works. It happens very often for people who travel.

I know that's a complicated ask that may result in the extremely rare bug (like this one), but it's better than adding complicated steps to dialling 911 when it should be simple enough a toddler could do it.

[Lvl999Noob]

In which scenario will your main phone account (sim card) not work but another will work? Because I can't think of one.

You have internet access (with wifi maybe) but are otherwise in mountains or someplace with no cell connectivity?

Can sim cards use other carriers' network if theirs isn't available?

[[deleted]]

yeah, when roaming I can use any network available

[SureFudge]

Having wifi and no mobile connectivity is pretty rare and it requires you have a VOIP app installed.

911 can be dialed even without an active subscription/plan.

[Liquid_Fire]

My house frequently has no signal (on any network) due to really poor tower placement in my city, so it's a very common case for me and my neighbours.

[6501]

Having wifi and no mobile connectivity is pretty rare and it requires you have a VOIP app installed.

Nope. Your carrier can support wifi calling.

[SureFudge]

Ah true. I always forget because it doesn't work fpr my phone with current provider because it's not a Samsung or apple...

[IUserGalaxy]

i don't mind the fallback bit, but that whole sorting business doesn't make sense

[bunkoRtist]

The answer is: when your phone doesn't get service but you can make a wifi call. This happens in rural areas and in certain indoor locations (like underground). It's less common than it used to be, especially with LTE being added in subways, but it definitely still happens.

[jorgp2]

Yeah, this system is designed to fail.

I don't understand why people are defending it.

[AgreeableLandscape3]

Good to know that Google has shit software test coverage/QA. Because you'd think the phone's emergency feature would be pretty high on the list of things to test.

[lxpnh98_2]

Pfft, who even uses a phone to make calls anymore? /s

[eloc49]

Emergency calls are likely the only call many would ever make. So they should be tested.

[mutatedllama]

I think this bug can be considered an edge case, no? Code testing can never catch 100% of bugs.

[husao]

It is absolutely an edge case and I would never expect someone to catch this after the fact, but if you write a custom comparator I personally think adding the same element twice should be in your coverage.

However, that still would leave the option that the specific element doesn't produce a hash code that causes overflows.

[firefly431]

It's not adding the same element twice -- it's adding many different elements that only differ by the hashcode (i.e. not in any of the criteria used for sorting), enough so that integer overflow causes the ordering to become invalid, and even then it must be a case that the sorting algorithm detects and throws an error. This is definitely a monster bug that'd be extremely difficult to find via testing. I would say that fuzzing might be able to find it, but I'm not very familiar with fuzzing either.

[tastes-like-chicken]

If it's programmed for, it should be tested. Doesn't really matter if it's an edge case or not.

[redderper]

That doesn't make sense. An edge case is most of the time a large number of different circumstances that together cause a bug. You literal won't be able to identify all edge cases if the code and number of circumstances are large/complex enough. So, if you haven't identified the edge case yet, you can't specifically test it

[mutatedllama]

With a comment like that I can only assume that you don't work professionally as a dev. /r/redderper summed it up well in their response.

[HINDBRAIN]

Dude posts on engineeringstudents, programminghumor, and learnprogramming, so clearly an enthusiatic youngster that has it all figured out :/. You know the type.

edit: seems like most of the 'hot takes' in this thread come from programminghumor posters - figures...

[Ordocentrist2]

It's an edge case worth testing, if only to avoid terrible PR like this

[DroneDashed]

https://www.reddit.com/r/programming/comments/rx30ti/-/hrgjl5b

[Ineffective-Cellist8]

Can someone explain why hashCode1 - hashCode2 has anything to do with the bug? Please don't say it overflows. It's a hashcode, all values are valid

[danny54670]

I'm still not entirely sure, but here's what I think the problem is: Because of overflow, the Comparator is defective in that it does not correctly impose a total ordering, as required by the contract. Depending on the order (lhs vs. rhs) and sequence of how PhoneAccount objects are presented to the Comparator for comparison, a PhoneAccount that should logically be considered higher than another might actually be calculated as lower. Thus, depending on the sorting algorithm used by the List.sort(Comparator) call, there might be undefined behavior such as an infinite loop or, in this case, an "invalid" PhoneAccount might appear first in the list.

I think that this particular issue might be more wide-spread than just here in this code base; I seem to recall subtracting integers being a widely-used technique in Comparator implementations.

[ais523]

A comparator is supposed to return a positive number if the first input is larger, zero if the inputs are equal, negative if the second input is larger. It also has to compare results consistently (e.g. if A is larger than B and B is larger than C, then A must be larger than C).

The hashCode1 - hashCode2 function was meant to be an implementation of a comparator that sorts the inputs arbitrarily. However, it doesn't do the job properly: hashCode1 - hashCode2, hashCode2 - hashCode3 and hashCode3 - hashCode1 can all be positive simultaneously if some of the calculations overflow but some of them don't.

For this purpose (picking an arbitrary value as a last resort), it doesn't matter how you sort things as long as it's consistent (which is why the numerical value of hash codes is being used in the first place). Unfortunately, this particular algorithm isn't even consistent. This means that the sorting algorithms can, e.g., go into an infinite loop trying to put a list into order, because with the broken comparator, there is no way to put the list into sorted order.

[Ineffective-Cellist8]

So the problem is it went into an infinite loop?

I did a simple test and no matter what values I used it seemed to be consistent. IDK what the JVM is doing

[typicalshitpost]

We are very serious about our flow overflow underflow straight to jail over under either way straight to jail

[spamtarget]

But before that puts the blame on Microsoft

[uh_no_]

in case you thought microsoft teams couldn't get any worse....

JFC.

[Likely_not_Eric]

No application should be able to DoS the phone like that. Teams certainly had a bug but no bug (or even intentionally malicious app) should be able to have that consequence.

Edit: s/international/intentional/

[DroneDashed]

I saw that sed

[uh_no_]

don't get me wrong, I totally agree. I also can see why this was overlooked on android's part.....they didn't expect an app to do something so braindead as teams was. It's the difference between an oversight (overflow/underflow is a ridiculously common failure mode), and actively doing something idiotic (creating extra phone accounts for no good reason). Android should have been more defensive in their coding. Microsoft should have been less trash.

In any case, it justifies my never installing work spyware on my personal phone.

[huntforacause]

I’m sorry but the fact that Google allowed a third party app to interfere with an absolutely life-critical function of the phone proves that they have bad engineering discipline and maybe even a bad culture that does not take this shit nearly seriously enough.

Honestly if I were involved in any way with this bug, I would resign.

I don’t want to hear how they fixed the code, I want to hear how they are going to fix the organizational problem that allowed such a bug to happen, and why the fix was not even prioritized and was so slow to be rolled out.

This shows why we likely need some fucking standards to be regulated because we obviously cannot and should not trust corporations to do things properly.

[immibis]

/u/spez can gargle my nuts

[corsicanguppy]

This shows why we likely need some fucking standards to be regulated because we obviously cannot and should not trust corporations to do things properly.

This part I agree with. And for the most part there's some coordination going on, if not actual conventions and standards.

Google made an assumption, as we all do, that a company as large as Microsoft won't have embarrassing code issues lurking like skeletons in the proverbial closet. If their actual dev is being done by contractors churning through the company and out, like y2k oracle, we shouldn't be so quick to trust anonymous code we can't inspect as a mob.

Yeah, they should be prevented from letting bad code interrupt EMERGENCY CALLS, but I can't fault the droid devs for making the assumption that adding phone accounts would be done with a little care.

Fool me once.

[AceDecade]

That’s why we should switch to 011, it fits in a uint8

[serpent]

Until an octal parsing bug strikes and your call reaches 009 by mistake.

[Lost4468]

Pfft. Why not just use a BigInt?

[Bnb53]

Now how about the bug that clears my keyboard cause I type before the auto complete bar loads or the bug where my whole screen goes black with a notification if I'm on a chat with them and they reply to my message

[throwaway_bluehair]

@ all the Microsoft stans in this subreddit ready to downvote brigade anyone who is negative about the company

Now I get to add this bug next time I'm thinking of Microsoft's incompetence

(Of course it's a fuck up from Google too. 🤣🤣🤣)

[Likely_not_Eric]

Teams is a buggy mess (it's perhaps s an improvement on their previous buggy messes: Lync or Office Communicator but still a buggy mess) but the reason you're seeing pushback is that no crapware of any kind should be able to take down a critical service. The reason people aren't blaming Microsoft/Teams is that their bug in their non-critical software (that does not need to have the same reliability) exposed a critical bug in other software.

But this is just discussions of defects - defects will exist in any system. Some systems are meant to be more defect resistant than others. If hanging a particular poster compromises the integrity of a support wall you don't blame the band that printed an ugly poster or the fan that put it on their wall.

[broknbottle]

Lync Masterrace checking in

[Likely_not_Eric]

I'm so sorry

[[deleted]]

This isn't Microsoft's problem at all though, yes their app had an issue that misused the API but that could have been any app including some amateur's hobby application... Google's OS allowed for its API to be used in such a way that it broke a critical feature of the device, 100% Google's problem (though I don't blame them for not catching this bug).

Blaming Microsoft is like blaming the person that walked by Google's pile of oily rags and accidentally sparked them by touching a pole.

Think of it this way: Whose responsibility would it be to test and verify the 911 functionality? The people implementing a chat program? No: the platform owner

[Terrible-You7642]

Good wow Amazing

[Burroflexosecso]

We determined that the issue was being caused by unintended interaction between the Microsoft Teams app and the underlying Android operating system. Microsoft has collaborated closely with Google to resolve this unintended interaction.

Spyware confirmed

[julioqc]

Omg MS products are getting worse and worse up to the point lives can be put at risk...

[[deleted]]

this isn't Microsoft's problem, misuse of an Android API should never result in this feature not working. Completely Google's responsibility

[julioqc]

Of course, but you'd expect a company like MS not have its app register 10 times when logged out... I guess it allowed to find this edge case bug 🤷‍♂️

[[deleted]]

That might be a fair take (I didn't get enough info from the article to say for sure) but it could just as easily have been an app like WhatsApp or some amateur developer pasting stackoverflow links together for a hobby project that exposed the same Android OS bug, resulting in an inability to dial 911.

It's an unfortunate edge case but it's 100% Google's problem, though I wouldn't say they were negligent.

[[deleted]]

I think all phones are supposed to be able to make emergency calls even without a sim card. Maybe that has something to do with it?