Closed Bug 585394 Opened 11 years ago Closed 11 years ago

random assertion on modules/plugin/test/reftest/pluginproblemui-direction-1.html due to non-null-terminated nsDependentCString


(Toolkit :: Crash Reporting, defect)

Not set





(Reporter: dbaron, Unassigned)



(Keywords: intermittent-failure)

We're seeing random assertions here:
REFTEST TEST-UNEXPECTED-FAIL | file:///home/cltbld/talos-slave/mozilla-central_fedora-debug_test-reftest/build/reftest/tests/modules/plugin/test/reftest/pluginproblemui-direction-1.html | assertion count 1 is more than expected 0 assertions

The most recent occurrence is:
Rev3 Fedora 12 mozilla-central debug test reftest

and a bunch of prior occurrences are in bug 567367 comment 4, through bug 567367 comment 11 (incorrectly placed).

The log mentioned above (most recent) has the following assertion and stack:

###!!! ASSERTION: nsTDependentString must wrap only null-terminated strings: 'mData[mLength] == 0', file ../../../../dist/include/nsTDependentString.h, line 67
nsDependentCString::AssertValid [nsTDependentString.h:68]
nsDependentCString::nsDependentCString [nsTDependentString.h:92]
CrashReporter::WriteExtraData [toolkit/crashreporter/nsExceptionHandler.cpp:1406]
CrashReporter::WriteExtraForMinidump [toolkit/crashreporter/nsExceptionHandler.cpp:1431]
CrashReporter::OnChildProcessDumpRequested [toolkit/crashreporter/nsExceptionHandler.cpp:1467]
google_breakpad::CrashGenerationServer::ClientEvent [toolkit/crashreporter/google-breakpad/src/client/linux/crash_generation/]
google_breakpad::CrashGenerationServer::Run [toolkit/crashreporter/google-breakpad/src/client/linux/crash_generation/]
google_breakpad::CrashGenerationServer::ThreadMain [toolkit/crashreporter/google-breakpad/src/client/linux/crash_generation/] + 0x5ab5

This makes me think that the problem is that the relevant code in crashreporter:
    time_t crashTime = time(NULL);
    char crashTimeString[32];
    XP_TTOA(crashTime, crashTimeString, 10);

is leaving crashTimeString not explicitly null-terminated, and the nsDependentCString code is finding a null at some point during its construction that is no longer null by the time we reach AssertValid because the null is somewhere random on the stack that gets stomped on by calling AssertValid (though I admit that seems rather odd given the stack growth direction, though maybe I'm getting confused).  It does appear that XP_TTOA is my_itos, which is defined here: and clearly does not null-terminate.
blocking2.0: --- → ?
It looks like the my_itos version of XP_TTOA is the only one of the XP_TTOA options that does not null-terminate.  That makes this Linux-only.
Please back out
when this is fixed.  (It's easy to forget, since it's marked as 0-1 so it won't start failing when the assertion goes away!)
And, to be clear, I nominated this for blocking since it's reading stack memory and sending it as a crash annotation; that's a potential privacy violation and a potential (though pretty unlikely to have no null bytes on the stack, I'd think) crash.
This is bug 584582, and it's already blocking.
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 584582
blocking2.0: ? → ---
(In reply to comment #3)
> Please back out
> when this is fixed.  (It's easy to forget, since it's marked as 0-1 so it won't
> start failing when the assertion goes away!)

Done, but only because I have a script that reads reftest.list files and tells me when they refer to resolved bugs.
Blocks: 438871
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.