Critical Error!

message_die() was called multiple times.

Out of curiosity, I Googled `message_die() was called multiple times`

and it seems to be somehow related to phpBB.

What I found more interesting was there are lots and lots of people asking about this error, some going as far back as 2005, and yet I never found anyone providing any information about what causes the error -- not even on the official phpBB website, where they seem to be even more hostile to user problems than

]]>Critical Error!

message_die() was called multiple times.

Out of curiosity, I Googled `message_die() was called multiple times`

and it seems to be somehow related to phpBB.

What I found more interesting was there are lots and lots of people asking about this error, some going as far back as 2005, and yet I never found anyone providing any information about what causes the error -- not even on the official phpBB website, where they seem to be even more hostile to user problems than

]]>message_die() was called multiple times

I'd guess it's a error nested in the error handler (perhaps the database connection has gone awol) relevant-ish link More recent phpBB versions don't appear to include this *feature*.

**Status:** sufficiently bored that am resorting to googling phpBB source

@el_heffe said in I guess it could be worse. It could be phpBB.:

I guess it could be worse

Yes, it could be Firefox, which doesn't know how to do square-roots anymore (wasted ~1h yesterday over that)

]]>a new SQL injection vulnerability every week

How do you even do that? Every piece of software has only so many textboxes that need sanitization. Am I missing something?

]]>Yes, it could be Firefox, which doesn't know how to do square-roots anymore (wasted ~1h yesterday over that)

Windows calculator app has never done square roots properly either.

- Calculate the square root of any number
- Subtract a number that should result in an answer of zero
- You don't get zero

Yes, it could be Firefox, which doesn't know how to do square-roots anymore (wasted ~1h yesterday over that)

The comments on that ticket are made absolutely hilarious by the developers who are *so sure* it must not be their code. "Might depend on the page you have open." No, it happens on different pages. "Must be an extension." No, it happens in Safe Mode. "Must be system-wide." No, Edge and Calculator are fine. "Must be the version you have." No, it happens on latest. "Must be using a custom build." No, downloaded from Mozilla.org (by now wouldn't a *custom build* have come up?!). "Must be system-wide *on 32-bit*." No, IE is fine.

Have you tried reinstalling Windows? Do you use any anti-virus/anti-malware software? There must be something wrong with your machine/OS/CPU.

That's the point at which I would have lost my shit.

]]>@japonicus said in I guess it could be worse. It could be phpBB.:

Windows calculator app has never done square roots properly either.

- Calculate the square root of any number
- Subtract a number that should result in an answer of zero
- You don't get zero

The many joys of floating point math.

]]>@japonicus said in I guess it could be worse. It could be phpBB.:

Windows calculator app has never done square roots properly either.

- Calculate the square root of any number
- Subtract a number that should result in an answer of zero
- You don't get zero

It's just how binary floating-point numbers work. Windows calculator works perfectly, given the limitations of binary floating-point numbers. It follows the IEEE-754 precisely, and it's calculating the best square root of any number given the limitations of binary floating-point numbers. It just fails to inform the user about the limitations of binary floating-point numbers. Of course, they could have used arbitrary precision arithmetics instead of binary floats, but that sounds like work.

]]>@dragnslcr said in I guess it could be worse. It could be phpBB.:

a new SQL injection vulnerability every week

How do you even do that? Every piece of software has only so many textboxes that need sanitization. Am I missing something?

That's how good^{1} the phpBB developers were.

^{1} Unbelievably incompetent

Have you tried reinstalling Windows? Do you use any anti-virus/anti-malware software? There must be something wrong with your machine/OS/CPU.

To be fair, antivirus software is *typically* shitty, buggy, and intrusive.

Hell, there's a long and robust tradition on Windows of software-that-runs-as-Administrator hooking into system DLLs and injecting their own -often buggy- code for no good reason at all. I'll give it a 1:100 chance that this is some shitty Pro Gamer L33t Full System Speed Enhanzzer!!!-type software poking its nose into places where it shouldn't.

]]>To be fair, antivirus software is

typicallyshitty, buggy, and intrusive.

Pot, meet kettle:

```
DLL blocklist was unable to intercept AppInit DLLs
Assertion failure: false (MOZ_ASSERT_UNREACHABLE: Unrecognized opcode sequence), at [...]\nsWindowsDllInterceptor.h:1106
```

]]>]]>@bugmenot said in I guess it could be worse. It could be phpBB.:

To be fair, antivirus software is

typicallyshitty, buggy, and intrusive.Pot, meet kettle:

`DLL blocklist was unable to intercept AppInit DLLs Assertion failure: false (MOZ_ASSERT_UNREACHABLE: Unrecognized opcode sequence), at [...]\nsWindowsDllInterceptor.h:1106`

@bugmenot said in I guess it could be worse. It could be phpBB.:

To be fair, antivirus software is

typicallyshitty, buggy, and intrusive.Pot, meet kettle:

`DLL blocklist was unable to intercept AppInit DLLs Assertion failure: false (MOZ_ASSERT_UNREACHABLE: Unrecognized opcode sequence), at [...]\nsWindowsDllInterceptor.h:1106`

@blubar would be proud.

the rest of us want context

]]>@blubar would be proud.

the rest of us want context

That's an error message I get running a debug build of Firefox on my systems. Seems the DLL blocklist tries to... you guessed it, hook into system DLLs and inject a detour to do its job.

Exactly what anti-virus/anti-malware software was accused of above. Except worse, because this is *not a browser's job*. Firefox developers should admit that by now their project has totally gotten away from them.

The "MOZ" in the macro name and the rest of the error message made the context pretty obvious to me. ]]>

@el_heffe said in I guess it could be worse. It could be phpBB.:

@japonicus said in I guess it could be worse. It could be phpBB.:

Windows calculator app has never done square roots properly either.

- Calculate the square root of any number
- Subtract a number that should result in an answer of zero
- You don't get zero
It's just how binary floating-point numbers work. Windows calculator works perfectly, given the limitations of binary floating-point numbers. It follows the IEEE-754 precisely, and it's calculating the best square root of any number given the limitations of binary floating-point numbers. It just fails to inform the user about the limitations of binary floating-point numbers. Of course, they could have used arbitrary precision arithmetics instead of binary floats, but that sounds like work.

I'm really bad at math, and I know that binary floating point stuff is tricky, but I've pretty sure that the square root of 16 is exactly

4.00000000000000000000000000000000000000000000000000000000000

But the calculator says `(sq rt of 16) minus 4`

= -4.561669785727164e-20

Also, the calculator app in Windows 10 gives a different wrong answer than the calculator in Windows 7.

]]>@gąska said in I guess it could be worse. It could be phpBB.:

@el_heffe said in I guess it could be worse. It could be phpBB.:

@japonicus said in I guess it could be worse. It could be phpBB.:

Windows calculator app has never done square roots properly either.

- Calculate the square root of any number
- Subtract a number that should result in an answer of zero
- You don't get zero
It's just how binary floating-point numbers work. Windows calculator works perfectly, given the limitations of binary floating-point numbers. It follows the IEEE-754 precisely, and it's calculating the best square root of any number given the limitations of binary floating-point numbers. It just fails to inform the user about the limitations of binary floating-point numbers. Of course, they could have used arbitrary precision arithmetics instead of binary floats, but that sounds like work.

I'm really bad at math, and I know that binary floating point stuff is tricky, but I've pretty sure that the square root of 16 is exactly

4.00000000000000000000000000000000000000000000000000000000000But the calculator says

`(sq rt of 16) minus 4`

= -4.561669785727164e-20Also, the calculator app in Windows 10 gives a different wrong answer than the calculator in Windows 7.

Oh yeah, that reminds me: all these values should be exactly representable in standard floating point, so the answer should be correct, not wrong as it is.

]]>@accalia

The "MOZ" in the macro name and the rest of the error message made the context pretty obvious to me.

I figured it would, but certainly don't mind providing additional context.

]]>Of course, they could have used arbitrary precision arithmetics instead of binary floats, but that sounds like work.

It is a *lot* of work and detours through some of the wilder parts of computer arithmetic. The best solutions I've seen have involved using tensors where the terms are arbitrary precision integers (themselves not actually a trivial library if you want speed) and having the whole thing rigged up behind generators so that callers can just get the digits that they want. You can get a fair way with a simple digit sequence generator, but it's horribly vulnerable to problems where it can take an infinite amount of work decide what the next digit should be (IIRC, computing the square root of 4 is one of these problems!) unless you put in something to retract digits, which deeply screwy from the perspective of callers. There's also been work looking at doing it with continued fractions, but I think they've got other problems (though I forget what).

If you can possibly make do with IEEE `double`

s instead, please do that. Or something simple with fixed-point math. That's just brain-bending.

Pot, meet kettle:

`DLL blocklist was unable to intercept AppInit DLLs`

That's a Mozilla feature that prevents the loading of known-bad/buggy/troublesome DLLs. You can see the list of DLLs currently blocked and the justification for their inclusion on the list here: https://dxr.mozilla.org/mozilla-beta/source/mozglue/build/WindowsDllBlocklist.cpp#90

The initial rationale for the blocklist is mentioned in the description of this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=524904

It seems like a very good thing to me.

Were you running a *bleeding edge* development version? This bug has a comment that contains a stacktrace that looks related to yours: https://bugzilla.mozilla.org/show_bug.cgi?id=1322554#c96 . The bug in the *report* was fixed in Firefox 55. The bug in comment 96 was fixed by backing out a buggy change commited into source control.

If there's some other cause for the error you ran into, then Google doesn't seem to know about it.

]]>and it's calculating the best square root of any number given the limitations of binary floating-point numbers

So then. Root 4 is close to, but not exactly, 2?

]]>oh right, forgot about that. But now I remember Raymond Chen explained it in pretty good detail on his blog. Long story short, while both 4 and 16 are exactly representable as floats, e isn't.

I'm not sure this is a good excuse, since there are floating-point instructions which conform to IEEE-754 and will give the exact result:

```
#include <iostream>
inline float sqrt(float n)
{
__asm__ ("fsqrt" : "+t"(n));
return n;
}
int main()
{
std::cout << sqrt(16.0) << std::endl;
return 0;
}
```

]]>@gąska said in I guess it could be worse. It could be phpBB.:

oh right, forgot about that. But now I remember Raymond Chen explained it in pretty good detail on his blog. Long story short, while both 4 and 16 are exactly representable as floats, e isn't.

I'm not sure this is a good excuse, since there are floating-point instructions which conform to IEEE-754 and will give the exact result:

`#include <iostream> inline float sqrt(float n) { __asm__ ("fsqrt" : "+t"(n)); return n; } int main() { std::cout << sqrt(16.0) << std::endl; return 0; }`

Aha, so the spec *does* work in the right fashion, it's that the calculator's implementation decided to use the indirect ln method that causes the problem. I'd thought that ought to be the case, but in my cursory looking around, I'd only seen hints and not proof.