My AB unit tests in ExQuilla were acting strangely, and I traced it to this core code, given here with the disassembly: (in nsDirPrefs.cpp): const char *prefname = NS_ConvertUTF16toUTF8(aData).get(); 5B49B8D1 mov eax,dword ptr [aData] 5B49B8D4 push eax 5B49B8D5 lea ecx,[ebp-6Ch] 5B49B8D8 call NS_ConvertUTF16toUTF8::NS_ConvertUTF16toUTF8 (597FAF02h) 5B49B8DD mov ecx,eax 5B49B8DF call nsCString::get (59891470h) 5B49B8E4 mov dword ptr [prefname],eax 5B49B8E7 lea ecx,[ebp-6Ch] 5B49B8EA call NS_ConvertUTF16toUTF8::~NS_ConvertUTF16toUTF8 (597C5375h) DIR_PrefId id = DIR_AtomizePrefName(prefname); What I see in the debugger is that aData makes sense, but *prefname is a long string containing only "Z". Stepping through the assembler, the conversion is done correctly but gets overwritten in NS_ConvertUTF16toUTF8::~NS_ConvertUTF16toUTF8 The code is not correct. You are trying to hold onto the reference to the internal buffer of a CString after the destruction of the CString. The destructor is zeroing that string (possibly because I am running in debug mode) so the net result is not correct. My symptoms of this are usually that the unit test simply stops without crashing, though sometimes I seem to get a breaking error in the DIR_AtomizePrefName call. Not sure if this is an issue during normal operation or not.
Created attachment 636735 [details] [diff] [review] Somebody needs to own the prefname storage The fix is pretty simple, and hopefully non-controversial, so I'll ask for it since I don't have a good workaround. The fix itself is obvious, but it may cause a feature that currently may not work to suddenly start working, which could have its own side effects. Not sure what those might be.