1466097 - ASSERTION: "Input wasn't UTF8 or incorrect length was calculated" followed by Hit MOZ_CRASH(Hit fatal chromium sandbox condition.) at z:/build/build/src/security/sandbox/chromium-shim/base/logging.cpp:120

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I can reliably reproduce this assertion and crash on Windows when setting the MOZ_LOG_FILE environment variable containing an extended ASCII character, and starting a debug build of Firefox:

> set MOZ_LOG_FILE=mozlog_µ.log
> debug\firefox.exe -profile unicode_test

As result Firefox asserts and crashes:

> [Parent 5020, Gecko_IOThread] ###!!! ASSERTION: Input wasn't UTF8 or incorrect length was calculated: 'Error', file z:/build/build/src/xpcom/string/nsReadableUtils.cpp, line 380
> Hit MOZ_CRASH(Hit fatal chromium sandbox condition.) at z:/build/build/src/security/sandbox/chromium-shim/base/logging.cpp:120

Before the above assertion and crash some other assertions are visible which don't seem to cause this crash but should also not appear:

> [Parent 5020, Gecko_IOThread] ###!!! ASSERTION: Not a UTF-8 string. This code should only be used for converting from known UTF-8 strings.: 'Error', file z:\build\build\src\xpcom\string\nsUTF8Utils.h, line 463

> [Parent 5020, Gecko_IOThread] ###!!! ASSERTION: Not a UTF-8 string. This code should only be used for converting from known UTF-8 strings.: 'Error', file z:\build\build\src\xpcom\string\nsUTF8Utils.h, line 121

The exported environment variable may not contain a correctly encoded value (not sure what would be correct in this case), but it shouldn't crash Firefox.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Btw. this crash was added on bug 1445167. Owen, can you please have a look?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Sounds like the logging functionality expects UTF-8 as filename and you're giving it some random other character set?

It's really hard to say anything else about anything here without any stacks.

Comment 3

[Nathan Froyd [:froydnj]]

Windows environment variables are UTF16 (or the almost-UTF16 character set that Windows uses, whatever that's called).  The logging code uses getenv() to retrieve MOZ_LOG_FILE and then apparently treats that as UTF8, which as you might imagine doesn't work out very well.

Comment 4

[Bob Owen (:bobowen)]

I'd be particularly interested in the stack for the "MOZ_CRASH(Hit fatal chromium sandbox condition.)" message.

It may be a different issue or it could be the sandbox choking in some way because it's getting passed some corrupted string.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I don't get any stack printed. Sorry, that I cannot tell more details. But as I noticed right now, I missed to add that also MOZ_LOG needs to be set. So here the list of commands to issue from a command line to see this crash:

> set MOZ_LOG=nsHostResolver:5
> set MOZ_LOG_FILE=mozlog_µ.log
> debug\firefox.exe -profile unicode_test

Looks like that this only happens when the content process wants to write to its log file. The log file for the parent process actually gets created correctly.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Owen, could you try out those steps yourself? I don't know how to provide more details here.

Comment 7

[Bob Owen (:bobowen)]

The chromium code that handles the Environment seems to ignore that string, so we're passing an empty string into the policy rule.

Comment 8

[Andrei Purice]

Hey Henrik,
Can you still reproduce this issue or should we close it?

Comment 9

[Andrei Purice]

Marking this as Resolved > Incomplete as per reporter's lack of response.
If anyone can still reproduce this issue re-open it or file a new bug.