Closed Bug 7393 Opened 25 years ago Closed 25 years ago

Assertion failure: !"I/O method is invalid", at priometh.c:86

Categories

(Core :: Networking, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: andreas.otte, Assigned: gagan)

Details

Attachments

(1 file)

Current Build (05-31-99) dies on startup with this messages when not connected to the internet. When connected all works well. Doing Startup... Creating browser app core BrowserAppCore has been created. Adding app core to AppCoreManager in the base initialization. Setting content window Assertion failure: !"I/O method is invalid", at priometh.c:86 Aborted Seems similar to bug 7387
QA Contact: leger → phillip
Commercial build is ok for 06/01 build. Is this a mozilla build, or the commercial build?
It´s the mozilla build.
Assignee: don → chofmann
Component: Apprunner → other
Chris, this appears to be an assert inside of NSPR. But I can't reproduce the problem. Who the heck gets this one?
Maybe it has something todo with building with debug enabled or not.
Okay it only happens when debug enabled. When build with --disable-debug the assertion is not happening. Maybe this has something to do with the latest changes to NS_ASSERT, I remember the endless discussion.
Assignee: chofmann → wtc
wtc's name is in the lxr log comments for piometh.c... http://cvs-mirror.mozilla.org/webtools/bonsai/cvslog.cgi?file=mozilla/nsprpub/pr /src/io/priometh.c do we just need to remove the assert, or should the problem be fixed elsewhere...
Is there a stack trace? There are two programming errors that can cause this assertion failure: 1. Invoking an I/O function that is invalid for the particular kind of file descriptor. For example, invoking PR_Seek on a TCP socket or PR_Connect on a disk file. 2. Invoking any I/O function on a file descriptor that has been closed. This programming error can be in NSPR or in SeaMonkey, but without a stack trace I can't tell. If you examine the core file in a debugger, look at the value of fd (the file descriptor in question), in particular: - fd->identity: see if it's PR_INVALID_IO_LAYER - fd->methods: see if it's &_pr_faulty_methods - fd->secret->state: see if it's _PR_FILEDESC_FREED.
There is an attached stack trace, if that is not enough, tell me what I have to do with gdb to get the information you need.
Sorry, I didn't notice the attachment. Looking at the stack trace, I think it's very likely that the fd is closed twice. Can you examine the contents of fd (in stack frame #5), especially fd->identity, fd->methods, and fd->secret->state, as I described earlier? The macro PR_INVALID_IO_LAYER is defined in prio.h with the value -1. The macro _PR_FILEDESC_FREED is defined in private/pprio.h with the value 0x11111111.
But why does it only happen when debug is enabled? Is PR_Assert trying to close the already closed file descriptor? I will try to examine the core.
Okay, here are the requested values: (gdb) frame 5 #5 0x405187f3 in PR_Close (fd=0x806c4b0) at priometh.c:109 109 return (fd->methods->close)(fd); (gdb) print fd $1 = (PRFileDesc *) 0x806c4b0 (gdb) print fd->identity $2 = -1 (gdb) print fd->methods $3 = (PRIOMethods *) 0x40549560 (gdb) print fd->secret->state $4 = 286331153 Hope this helps
Assignee: wtc → gagan
Component: other → Networking Library
So fd->identity is PR_INVALID_IO_LAYER (-1) and fd->secret->state is _PR_FILEDESC_FREED (0x11111111). I'll bet that fd->methods (0x40549560) is _pr_faulty_methods. Can you verify that too? > But why does it only happen when debug is enabled? > Is PR_Assert trying to close the already closed > file descriptor? PR_ASSERT (a macro) is compiled away in optimized build. In debug build, PR_ASSERT calls PR_Assert if the boolean expression evaluates to false. PR_Assert merely prints the boolean expression and aborts. NSPR uses assertions to catch programming errors. Developers should build with debug enabled to take advantage of these assertions. I am reassigning this bug to the Network Library component based on the stack trace.
> So fd->identity is PR_INVALID_IO_LAYER (-1) > and fd->secret->state is _PR_FILEDESC_FREED > (0x11111111). I'll bet that fd->methods > (0x40549560) is _pr_faulty_methods. Can you > verify that too? That question is definitly beyond my current scope of understanding of the code. If this is a netlib problem it will hopfuly vanish with necko.
Target to M8.
This is a patch from Jason Heirztler. Maybe someone can have a look at it: If the very first URL Mozilla tries to fetch has problems for some reason, it asserts. Assertion failure: !"I/O method is invalid", at priometh.c:86 The cause seems to be PR_Close() is called twice on the same PRFileDesc. This sounds like it will fix bug 7393 too. -- Jason Heirtzler Silicon Graphics, Inc *** mozilla/network/main/mkconect.c.bak Thu Jun 10 18:03:35 1999 --- mozilla/network/main/mkconect.c Thu Jun 10 18:34:40 1999 *************** *** 1271,1278 **** if(status < 0) { net_connection_failed(host); ! PR_Close(*sock); ! *sock = NULL; } FREE_AND_CLEAR(host_string); --- 1271,1277 ---- if(status < 0) { net_connection_failed(host); ! *sock = NULL; } FREE_AND_CLEAR(host_string); *************** *** 1394,1401 **** { net_connection_failed(host); TRACEMSG(("mktcp.c: Error during connect %d\n", PR_GetError())); ! PR_Close(*sock); ! *sock = NULL; } FREE_AND_CLEAR(host_string); --- 1393,1399 ---- { net_connection_failed(host); TRACEMSG(("mktcp.c: Error during connect %d\n", PR_GetError())); ! *sock = NULL; } FREE_AND_CLEAR(host_string);
I'm moving this to target M9, Necko will be enabled somewhere during late M8 or early M9. We will need to get on this and it cannot be postponed past the M9 milestone.
The file descriptor is being closed twice. This causes an assertion if the page cannot be fetched during startup. For example, in my case, there is always a firewall in the way so the browser always fails to fetch the first page and asserts. Can someone apply this patch? I just verified that it's still relevant.
Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)
With NECKO switched on, this bug should no longer be relevant since this code is no longer build.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed with Necko landing. Pl. verify.
Status: RESOLVED → VERIFIED
Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: