(2014/01/16 2:07), ISHIKAWA, Chiaki wrote:
...
> Since refreshing my local copy of comm-central tree a couple of days
> ago (my previous update was around Dec 25+ last year), I have not been
> able to run the test suite |make mozmill| for TB (local DEBUG BUILD)
> under valgrind (Debian GNU/Linux, both under 32-bit and 64-bit
> versions).
>
> Simply put, although I lengthened the timeout value, all the tests
> timed out and no useful information could be obtained. This was not
> the case only a few weeks ago or so before the source update. I
> lengthened the timeout by 60 seconds, still no go. (That is, I
> had already set it to 330 before, and increased it this time
> to 390 to no avail.)
>
I could run valgrind more or less successfully with |make mozmill|
after lengthening the timeout values to 500 seconds
in some python script files, and one javascript file.
I changed the subject line to include "Firefox developer beware"
because the strange warning messages I saw in TB log
when I ran thunderbird |make mozmill| test suite under valgrind
showed up easily
when I ran local DEBUG BUILD of Firefox created using the source code of
M-C portion of C-C
tree ( ./mozilla subdirectory holds the copy of M-C.)
natively. That is without valgrind or anything.
They can be printed under normal CPU load conditions.
>From the original post.
> Please note the warning, "PRFileDescAutoLock cannot get fd!: 'mFd'",
> and "Security network blocking I/O on Main Thread"
>
> [... during startup...]
> JavaScript strict warning: chrome://messenger/content/tabmail.xml, line
> 352: reference to undefined property aTabType.panelId
> [30685] WARNING: PRFileDescAutoLock cannot get fd!: 'mFd', file
> /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsSocketTransport2.h,
> line 195
> [30685] WARNING: Security network blocking I/O on Main Thread: file
> /REF-COMM-CENTRAL/comm-central/mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp,
> line 423
The following is the output recorded on the tty console where firefox
DEBUG BUILD was run.
Note "Security network blocking I/O on Main Thread" and
"PRFileDescAutoLock cannot get fd!"
ishikawa@vm-debian-amd64:/REF-COMM-CENTRAL/comm-central/mozilla$
/WWW-DIR/ff-objdir-tb3/dist/bin/firefox
...
[30272] WARNING: dependent window created without a parent: file
/REF-COMM-CENTRAL/comm-central/mozilla/toolkit/components/startup/nsAppStartup.cpp,
line 650
++DOCSHELL 0x2cd6330 == 1 [pid = 30272] [id = 1]
++DOMWINDOW == 1 (0x2cc96b8) [pid = 30272] [serial = 1] [outer = (nil)]
++DOMWINDOW == 2 (0x2cc3388) [pid = 30272] [serial = 2] [outer = 0x2cc96b8]
Chrome file doesn't exist:
/WWW-DIR/ff-objdir-tb3/dist/bin/chrome/toolkit/skin/classic/mozapps/update/update.png
[30272] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result
0x80520012: file
/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsFileStreams.cpp,
line 210
[30272] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result
0x80520012: file
/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsFileStreams.cpp,
line 482
[30272] WARNING: Asking for app status on a principal with an unknown
app id: 'mAppId != nsIScriptSecurityManager::UNKNOWN_APP_ID', file
/REF-COMM-CENTRAL/comm-central/mozilla/caps/src/nsPrincipal.cpp, line 532
[30272] WARNING: Security network blocking I/O on Main Thread: file
/REF-COMM-CENTRAL/comm-central/mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp,
line 423
[30272] WARNING: Security network blocking I/O on Main Thread: file
/REF-COMM-CENTRAL/comm-central/mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp,
line 423
--DOCSHELL 0x2cd6330 == 0 [pid = 30272] [id = 1]
[30272] WARNING: No disk space watcher component available!: file
/REF-COMM-CENTRAL/comm-central/mozilla/dom/indexedDB/IndexedDatabaseManager.cpp,
line 224
GetSpecialSystemDirectory: aSystemSystemDirectory=4
++DOCSHELL 0x35599e0 == 1 [pid = 30272] [id = 2]
++DOMWINDOW == 3 (0x355d338) [pid = 30272] [serial = 3] [outer = (nil)]
++DOMWINDOW == 4 (0x355f6d8) [pid = 30272] [serial = 4] [outer = 0x355d338]
... later ...
[30272] WARNING: Could not get disk status from nsIDiskSpaceWatcher:
file
/REF-COMM-CENTRAL/comm-central/mozilla/uriloader/prefetch/nsOfflineCacheUpdateService.cpp,
line 325
JavaScript strict warning:
resource://gre/modules/devtools/dbg-server.jsm ->
resource://gre/modules/devtools/server/main.js ->
resource://gre/modules/devtools/server/actors/script.js, line 186:
reference to undefined property aSearchParams.url
++DOMWINDOW == 21 (0x2b60ed8) [pid = 30272] [serial = 32] [outer =
0x4eb2c38]
++DOCSHELL 0x5f87660 == 11 [pid = 30272] [id = 13]
++DOMWINDOW == 22 (0x5f87e78) [pid = 30272] [serial = 33] [outer = (nil)]
[30272] WARNING: Subdocument container has no frame: file
/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsDocumentViewer.cpp,
line 2405
++DOMWINDOW == 23 (0x5fb82b8) [pid = 30272] [serial = 34] [outer =
0x5f87e78]
[30272] WARNING: PRFileDescAutoLock cannot get fd!: 'mFd', file
/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsSocketTransport2.h,
line 195
[30272] WARNING: PRFileDescAutoLock cannot get fd!: 'mFd', file
/REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsSocketTransport2.h,
line 195
++DOCSHELL 0x828bf80 == 12 [pid = 30272] [id = 14]
++DOMWINDOW == 24 (0x828ca18) [pid = 30272] [serial = 35] [outer = (nil)]
[30272] WARNING: Subdocument container has no frame: file
/REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsDocumentViewer.cpp,
line 2405
++DOMWINDOW == 25 (0x82911a8) [pid = 30272] [serial = 36] [outer =
0x828ca18]
Whatever the meaning of warning about
Security network blocking I/O is, the original comment in the source
line suggests that we should not be calling the invoked function in main
thread, and so
it should be investigated I think.
From: C-C ./mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp
SECStatus
nsNSSHttpRequestSession::internal_send_receive_attempt(bool
&retryable_error,
...
if (running_on_main_thread)
{
// The result of running this on the main thread
// is a series of small timeouts mixed with spinning the
// event loop - this is always dangerous as there is so much main
// thread code that does not expect to be called re-entrantly. Your
// app really shouldn't do that.
NS_WARNING("Security network blocking I/O on Main Thread");
// let's process events quickly
wait_interval = PR_MicrosecondsToInterval(50);
}
Maybe violating the non-re-entrancy resulted in
the strange lock failure?
TIA
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
