[debug builds only] PR_ASSERT [@SocketConnectContinue]

RESOLVED INCOMPLETE

Status

()

Core
Networking
--
critical
RESOLVED INCOMPLETE
16 years ago
2 years ago

People

(Reporter: timeless, Unassigned)

Tracking

({crash})

Trunk
x86
Windows 2000
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [need testcase], crash signature)

(Reporter)

Description

16 years ago
What was I doing? starting mozilla.

Console:
Type Manifest File: F:\build\mozilla\dist\WIN32_D.OBJ\bin\components\xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
WARNING: dependent window created without a parent, file 
F:\build\mozilla\xpfe\bootstrap\nsWindowCreator.cpp, line 116
WEBSHELL+ = 1
Note: verifyreflow is disabled
Note: styleverifytree is disabled
Note: frameverifytree is disabled
New location for profile registry and user profile directories is -> 
\\cen\sored\Application Data\Mozilla
System has shaping
### nsCacheProfilePrefObserver::Observe [topic=profile-after-change 
data=startup]
WARNING: NS_ENSURE_TRUE(globalObject) failed, file 
f:\build\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 1066
WARNING: NS_ENSURE_TRUE(globalObject) failed, file 
f:\build\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 1066
WARNING: NS_ENSURE_TRUE(globalObject) failed, file 
f:\build\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 1066
WEBSHELL- = 0
WEBSHELL+ = 1
WEBSHELL+ = 2
WARNING: waaah!, file 
f:\build\mozilla\content\xul\document\src\nsXULPrototypeDocument.cpp, line 661

JavaScript strict warning:
chrome://communicator/content/findUtils.js line 106: function findAgainInPage 
does not always return a value

WARNING: waaah!, file 
f:\build\mozilla\content\xul\document\src\nsXULPrototypeDocument.cpp, line 661

JavaScript strict warning:
chrome://communicator/content/bookmarks/bookmarksOverlay.js line 862: anonymous 
function does not always return a value

WARNING: waaah!, file 
f:\build\mozilla\content\xul\document\src\nsXULPrototypeDocument.cpp, line 661

JavaScript strict warning:
chrome://navigator/content/navigator.js line 632: function OpenBookmarkGroup 
does not always return a value

WARNING: waaah!, file 
f:\build\mozilla\content\xul\document\src\nsXULPrototypeDocument.cpp, line 661

JavaScript strict warning:
chrome://navigator/content/navigator.js line 644: variable resource hides 
argument

JavaScript error:
chrome://wallet/content/walletOverlay.js line 1: redeclaration of const hide

Error reading file 
jar:resource:///chrome/calendar.jar!/skin/classic/calendar/calendarOverlay.css
WARNING: CSSLoaderImpl::DidLoadStyle: Load of URL 
'chrome://calendar/skin/calendarOverlay.css' failed.  Error code: 16389, file 
f:\build\mozilla\content\html\style\src\nsCSSLoader.cpp, line 997
WEBSHELL+ = 3
Start reading in bookmarks.html
warning: property cp1256 already exists
Finished reading in bookmarks.html  (150000 microseconds)
JavaScript strict warning:
http://www.peel.net/frames/PMNforce.js line 46: redeclaration of var ws

JavaScript strict warning:
http://www.peel.net/frames/PMNforce.js line 71: redeclaration of var ws

JavaScript strict warning:
http://www.peel.net/frames/PMNforce.js line 72: redeclaration of var pos1

JavaScript strict warning:
http://www.peel.net/frames/PMNforce.js line 74: redeclaration of var ws

JavaScript strict warning:
http://www.peel.net/frames/PMNforce.js line 75: redeclaration of var dot1

JavaScript strict warning:
http://www.peel.net/frames/PMNforce.js line 76: redeclaration of var dot2

JavaScript strict warning:
http://www.peel.net/frames/PMNforce.js line 78: redeclaration of var sd

JavaScript strict warning:
http://www.peel.net/frames/PMNforce.js line 87: redeclaration of var PMNexp

JavaScript strict warning:
http://www.peel.net/frames/PMNforce.js line 95: redeclaration of var Position

JavaScript strict warning:
http://www.peel.net/frames/PMNforce.js line 96: redeclaration of var Position

JavaScript strict warning:
http://www.peel.net/frames/PMNforce.js line 26: assignment to undeclared 
variable begin

JavaScript strict warning:
http://www.peel.net/frames/PMNforce.js line 3: assignment to undeclared 
variable _ver

WEBSHELL+ = 4
WEBSHELL+ = 5
###!!! ASSERTION: Wrong Document Channel: 'request == mDocumentRequest', file 
f:\build\mozilla\uriloader\base\nsDocLoader.cpp, line 1287
###!!! Break: at file f:\build\mozilla\uriloader\base\nsDocLoader.cpp, line 
1287

Stack:
NTDLL! 77fa018c()
SocketConnectContinue(PRFileDesc * 0x03f51a68, short 1) line 295 + 30 bytes
pl_DefConnectcontinue(PRFileDesc * 0x03f01f70, short 1) line 200 + 23 bytes
PR_ConnectContinue(PRFileDesc * 0x03f01f70, short 1) line 188 + 17 bytes
nsSocketTransport::doConnection(short 1) line 938 + 21 bytes
nsSocketTransport::Process(short 1) line 531 + 13 bytes
nsSocketTransportService::Run(nsSocketTransportService * const 0x0178ea54) line 
516 + 13 bytes
nsThread::Main(void * 0x0178f3f0) line 120 + 26 bytes
_PR_NativeRunThread(void * 0x00d39a10) line 433 + 13 bytes
_threadstartex(void * 0x00d128e8) line 212 + 13 bytes
KERNEL32! 77e8758a()

static PRStatus PR_CALLBACK SocketConnectContinue(
    PRFileDesc *fd, PRInt16 out_flags)
{
    PRInt32 osfd;
    int err;

    if (out_flags & PR_POLL_NVAL) {
        PR_SetError(PR_BAD_DESCRIPTOR_ERROR, 0);
        return PR_FAILURE;
    }
    if ((out_flags & (PR_POLL_WRITE | PR_POLL_EXCEPT | PR_POLL_ERR)) == 0) {
        PR_ASSERT(out_flags == 0); // <- Death here.

Variables:
	out_flags	1

Top of stack (note that code mutates this class after reading from it)
nsSocketTransportService::Run(nsSocketTransportService * const 0x0178ea54) line 
516 + 13 bytes
      if ((count > 0) && pfd->out_flags) {
        // Clear the out_flags for next time...
        out_flags = pfd->out_flags; // <- read before mutate
        pfd->out_flags = 0; // <- mutation

        if (transport) {
          rv = transport->Process(out_flags); // <- call site
Variables:
-	pfd	0x00d14030
|-	fd	0x03f01f70
||+	methods	0x300346b8 ipv6_to_v4_tcpMethods
||	secret	0x00000000
||-	lower	0x03f51a68
|||+	methods	0x30034498 tcpMethods
|||	secret	0x03f01b88
|||+	lower	0x00000000
|||+	higher	0x03f01f70
|||	dtor	0x00000000
||\	identity	0
||+	higher	0x00000000
||	dtor	0x300048b0 pl_FDDestructor(PRFileDesc *)
|\	identity	1
|	in_flags	7
\	out_flags	0

I'm going to leave this stack alive for the day, please ask questions, I'll 
provide more details if possible.

Comment 1

16 years ago
timeless: can you please describe the problem here?  is it that you are just
seeing an assertion fire?  or is mozilla crashing/mis-behaving?

why is this a critical bug?
(Reporter)

Comment 2

16 years ago
as I said on irc, the reason it's critical is that PR_ASSERTs are fatal.

Comment 3

16 years ago
reducing severity since this bug doesn't seem to be all that reproducible (i.e.,
talkback data doesn't show this crash).
Severity: critical → major
Keywords: crash
Whiteboard: [need testcase]
(Reporter)

Comment 4

16 years ago
it won't appear in talkback, PR_ASSERT is only fatal in debug (otherwise it's a 
NOOP)

Comment 5

16 years ago
well now, i knew that... doh! ;)

Comment 6

16 years ago
mass futuring of untargeted bugs
Target Milestone: --- → Future
(Reporter)

Comment 7

15 years ago
*** Bug 180155 has been marked as a duplicate of this bug. ***
*** Bug 183589 has been marked as a duplicate of this bug. ***
darin, the way I ran into this (bug #183589) was by using my debug build to read
my pop mail.

Comment 10

15 years ago
so, i suspect this is some kind of MT race condition biting.  i'm in the process
of rewriting the socket transport (see bug 176919) with a focus on getting the
multithreading right from the ground up.  perhaps that patch will solve this bug
as well.

Updated

15 years ago
Depends on: 176919
fwiw, cavin just saw this with imap.

Comment 12

15 years ago
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: major → critical
this might be fixed now, since darin landed his async io branch.
Summary: PR_ASSERT [@SocketConnectContinue] → [debug builds only] PR_ASSERT [@SocketConnectContinue]

Comment 14

14 years ago
timeless, can you still reproduce this problem? If not, can you resolve the bug?
(Reporter)

Comment 15

14 years ago
i haven't run a debug mail build in a while. i have no idea if this is fixed,
just because no one sees it doesn't mean it isn't there. i'm unlikely to run a
debug build of mail for a while.

Updated

12 years ago
Assignee: darin → nobody
QA Contact: benc → networking
Target Milestone: Future → ---

Updated

8 years ago
Keywords: testcase-wanted
(Assignee)

Updated

7 years ago
Crash Signature: [@SocketConnectContinue]

Comment 16

6 years ago
Technically still a crash. We have 8 of these on 10.0.2 in the past 4 weeks.

Comment 17

6 years ago
smooney: Thanks for the update.  SocketConnectContinue has
two PR_ASSERT statements:

272     if ((out_flags & (PR_POLL_WRITE | PR_POLL_EXCEPT | PR_POLL_ERR)) == 0) {
273         PR_ASSERT(out_flags == 0);
274         PR_SetError(PR_IN_PROGRESS_ERROR, 0);
275         return PR_FAILURE;
276     }

and

314     PR_ASSERT(out_flags & PR_POLL_WRITE);
315     return PR_SUCCESS;

Do you know which one failed?

Comment 18

6 years ago
(In reply to Wan-Teh Chang from comment #17)
> Do you know which one failed?

Actually, for one thing, if it's still true that PR_ASSERT is only fatal on debug, then those crashes are probably different, as they happen on opt builds. Also, the frames underneath are different from what we have in here, see https://crash-stats.mozilla.com/query/query?product=Firefox&version=ALL%3AALL&range_value=4&range_unit=weeks&query_search=signature&query_type=contains&query=SocketConnectContinue&do_query=1 so either the code changed a lot or those are different things anyhow.

In this light, is there still value in keeping this particular bug open?

Comment 19

6 years ago
kairo: yes, PR_ASSERT is only fatal on debug, unless you compile
your opt builds with -DFORCE_PR_ASSERT:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/pr/include/prlog.h&rev=3.19&mark=204,206,214#204

This MXR query shows Mozilla does not compile its code with
FORCE_PR_ASSERT defined:
http://mxr.mozilla.org/mozilla-central/search?string=FORCE_PR_ASSERT

Should we close this very old bug then?

Comment 20

6 years ago
Yes, let's close it. I'm marking incomplete as it has no info on if this applies to recent versions or not. Please reopen if you can reproduce and add info on how to do so with currently supported versions.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
Keywords: testcase-wanted
You need to log in before you can comment on or make changes to this bug.