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)
Tracking
()
VERIFIED
FIXED
M9
People
(Reporter: andreas.otte, Assigned: gagan)
Details
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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
Commercial build is ok for 06/01 build. Is this a mozilla build, or the
commercial build?
Reporter | ||
Comment 2•25 years ago
|
||
It´s the mozilla build.
Chris, this appears to be an assert inside of NSPR. But I can't reproduce the
problem. Who the heck gets this one?
Reporter | ||
Comment 4•25 years ago
|
||
Maybe it has something todo with building with debug enabled or not.
Reporter | ||
Comment 5•25 years ago
|
||
Reporter | ||
Comment 6•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: chofmann → wtc
Comment 7•25 years ago
|
||
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...
Comment 8•25 years ago
|
||
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.
Reporter | ||
Comment 9•25 years ago
|
||
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.
Comment 10•25 years ago
|
||
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.
Reporter | ||
Comment 11•25 years ago
|
||
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.
Reporter | ||
Comment 12•25 years ago
|
||
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
Updated•25 years ago
|
Assignee: wtc → gagan
Component: other → Networking Library
Comment 13•25 years ago
|
||
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.
Reporter | ||
Comment 14•25 years ago
|
||
> 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.
Assignee | ||
Comment 15•25 years ago
|
||
Target to M8.
Reporter | ||
Comment 16•25 years ago
|
||
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);
Comment 17•25 years ago
|
||
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.
Comment 18•25 years ago
|
||
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.
Comment 19•25 years ago
|
||
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. ;-)
Reporter | ||
Comment 20•25 years ago
|
||
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
Assignee | ||
Comment 21•25 years ago
|
||
Fixed with Necko landing. Pl. verify.
Reporter | ||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 22•25 years ago
|
||
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.
Description
•