44412 - No window comes up under Tru64 Unix

Status: RESOLVED WORKSFORME

(Core :: XML, defect, P3)

Description

[jim_nance]

For at least the last 2 weeks I have been unable to get mozilla
to bring up a window under Tru64 Unix.  I have debugged this a
little, and I think its related to this message, which is the
last thing that appears on my console:

WARNING: not calling OnDataAvailable, file
/usr/users/jnance/mozilla/mozilla/netwerk/base/src/nsAsyncStreamListener.cpp,
line 404

Comment 1

[jim_nance]

Here is what I know.  The following call returns with a status of 2152596471
which causes the error message to be printed, and the OnDataAvailable call
to be skipped:

  nsresult rv = mChannel->GetStatus(&status);
  NS_ASSERTION(NS_SUCCEEDED(rv), "GetStatus failed");

  //
  // Only send OnDataAvailable(... ) notifications if all previous calls
  // have succeeded...
  //
  if (NS_SUCCEEDED(rv) && NS_SUCCEEDED(status)) {
    rv = receiver->OnDataAvailable(mChannel, mContext,
                                   mIStream, mSourceOffset, mLength);
  }
  else {  
          NS_WARNING("not calling OnDataAvailable");
  }

I did some digging through the code and GetStatus() is just reading a variable
that has already been set.  I traced through the code and to me it looks
like the cause of the failure is here:

(ladebug) where 1
>0  0x3ffbf84d9c8 in
((nsExpatTokenizer*)0x140422e00)->ParseXMLBuffer(aBuffer=0x140441020="<",
aLength=16384, aIsFinal=0)
"/usr/users/jnance/mozilla/mozilla/htmlparser/src/nsExpatTokenizer.cpp":438
(ladebug) w
    433 
    434     nsCOMPtr<nsExpatTokenizer> me=this;
    435 
    436     if (!XML_Parse(mExpatParser, aBuffer, aLength, aIsFinal)) {
    437       PushXMLErrorTokens(aBuffer, aLength, aIsFinal);
>   438       result=NS_ERROR_HTMLPARSER_STOPPARSING;
    439     }
    440     else if (aBuffer && aLength) {
    441       // Cache the last line in the buffer
    442       GetLine(aBuffer, aLength, aLength - sizeof(PRUnichar), mLastLine);

I tried to look at what XMP_Parse was doing, but it was beyond me.  Here is
the stack trace down to this point in the code:

>0  0x3ffbf84d9c8 in
((nsExpatTokenizer*)0x140422e00)->ParseXMLBuffer(aBuffer=0x140441020="<",
aLength=16384, aIsFinal=0)
"/usr/users/jnance/mozilla/mozilla/htmlparser/src/nsExpatTokenizer.cpp":438
#1  0x3ffbf84dafc in
((nsExpatTokenizer*)0x140422e00)->ConsumeToken(aScanner=class { ... },
aFlushTokens=0)
"/usr/users/jnance/mozilla/mozilla/htmlparser/src/nsExpatTokenizer.cpp":479
#2  0x3ffbf87742c in ((nsParser*)0x1403f8280)->Tokenize(aIsFinalChunk=0)
"/usr/users/jnance/mozilla/mozilla/htmlparser/src/nsParser.cpp":2419
#3  0x3ffbf876104 in ((nsParser*)0x1403f8280)->ResumeParse(allowIteration=1,
aIsFinalChunk=0)
"/usr/users/jnance/mozilla/mozilla/htmlparser/src/nsParser.cpp":1859
#4  0x3ffbf8770c4 in
((nsParser*)0x1403f8280)->OnDataAvailable(channel=0x1402cc500, aContext=0x0,
pIStream=0x1402e96d8, sourceOffset=0, aLength=8192)
"/usr/users/jnance/mozilla/mozilla/htmlparser/src/nsParser.cpp":2308
#5  0x3000336b078 in
((nsDocumentOpenInfo*)0x140303c80)->OnDataAvailable(aChannel=0x1402cc500,
aCtxt=0x0, inStr=0x1402e96d8, sourceOffset=0, count=8192)
"/usr/users/jnance/mozilla/mozilla/uriloader/base/nsURILoader.cpp":249
#6  0x30003150f7c in
((nsResChannel*)0x1402cc500)->OnDataAvailable(transportChannel=0x140303b00,
context=0x0, aIStream=0x1402e96d8, aSourceOffset=0, aLength=8192)
"/usr/users/jnance/mozilla/mozilla/netwerk/protocol/res/src/nsResChannel.cpp":729
#7  0x3000313b6f0 in
((nsFileChannel*)0x140303b00)->OnDataAvailable(transportChannel=0x140303e00,
context=0x0, aIStream=0x1402e96d8, aSourceOffset=0, aLength=8192)
"/usr/users/jnance/mozilla/mozilla/netwerk/protocol/file/src/nsFileChannel.cpp":653
#8  0x30003081300 in ((nsOnDataAvailableEvent*)0x140303ac0)->HandleEvent()
"/usr/users/jnance/mozilla/mozilla/netwerk/base/src/nsAsyncStreamListener.cpp":400
#9  0x3000308013c in nsStreamListenerEvent::HandlePLEvent(aEvent=0x140303c40)
"/usr/users/jnance/mozilla/mozilla/netwerk/base/src/nsAsyncStreamListener.cpp":97
#10 0x3ffbff2e028 in PL_HandleEvent(self=<no value>)
"/usr/users/jnance/mozilla/mozilla/xpcom/threads/plevent.c":575
#11 0x3ffbff2dee0 in PL_ProcessPendingEvents(self=<no value>)
"/usr/users/jnance/mozilla/mozilla/xpcom/threads/plevent.c":520
#12 0x3ffbff31530 in ((nsEventQueueImpl*)0x140100260)->ProcessPendingEvents()
"/usr/users/jnance/mozilla/mozilla/xpcom/threads/nsEventQueue.cpp":356
#13 0x3ffbf4e6724 in event_processor_callback(data=0x140100260, source=6,
condition=GDK_INPUT_READ)
"/usr/users/jnance/mozilla/mozilla/widget/src/gtk/nsAppShell.cpp":158
#14 0x3ffbf4e6254 in our_gdk_io_invoke(source=0x140303440, condition=G_IO_IN,
data=0x140302380)
"/usr/users/jnance/mozilla/mozilla/widget/src/gtk/nsAppShell.cpp":57
#15 0x300033987c0 in g_io_unix_dispatch(source_data=<no value>, current_time=<no
value>, user_data=<no value>)
"/usr/users/jnance/mozilla/glib-1.2.8/giounix.c":135
#16 0x3000339a8ac in g_main_dispatch(dispatch_time=<no value>)
"/usr/users/jnance/mozilla/glib-1.2.8/gmain.c":656
#17 0x3000339b0b4 in g_main_iterate(block=536851880, dispatch=0)
"/usr/users/jnance/mozilla/glib-1.2.8/gmain.c":877
#18 0x3000339b2a8 in g_main_run(loop=<no value>)
"/usr/users/jnance/mozilla/glib-1.2.8/gmain.c":935
#19 0x30003276590 in gtk_main()
"/usr/users/jnance/mozilla/gtk+-1.2.8/gtk/gtkmain.c":476
#20 0x3ffbf4e6e38 in ((nsAppShell*)0x140136350)->Run()
"/usr/users/jnance/mozilla/mozilla/widget/src/gtk/nsAppShell.cpp":334
#21 0x3ffbe86b72c in ((nsAppShellService*)0x140128980)->Run()
"/usr/users/jnance/mozilla/mozilla/xpfe/appshell/src/nsAppShellService.cpp":386
#22 0x12000c86c in main1(argc=3, argv=0x11fffc018, nativeApp=0x0)
"/usr/users/jnance/mozilla/mozilla/xpfe/bootstrap/nsAppRunner.cpp":914
#23 0x12000d060 in main(argc=3, argv=0x11fffc018)
"/usr/users/jnance/mozilla/mozilla/xpfe/bootstrap/nsAppRunner.cpp":1100
#24 0x120005f38 in __start(0x11fffb5a8, 0x0, 0x18, 0x1402d4c00, 0x78, 0xf) in
mozilla-bin

If anyone has any ideas I would love to hear them.  I am already in way over
my head.  Like I said earlier, mozilla has been broken under Tru64 for about
2 weeks.  It would be interesting to know if Linux/Alpha or any other 64 bit
port was working.

Comment 2

[Nisheeth Ranjan]

Jim, it seems that the expat tokenizer is returning an error while parsing an 
XML buffer.  Can you step into the PushXMLErrorTokens() method and examine the 
values that the nsParserError struct on the stack gets filled in with?  
Specifically, what are the values of error->code and error->description?

Also, could there be a bug in the code that calculates buffer length in 
ConsumeToken()?  If you could step through that and see if it assigning correct 
values, that would rule one more possibility out.

I don't have access to a Tru64 Unix build here, so I'm sorry that I can't help 
more...

Comment 3

[Nisheeth Ranjan]

Adding heikki and harish to the cc list...

Comment 4

[jim_nance]

Here is some of the info you wanted.
stopped at [nsresult nsExpatTokenizer::PushXMLErrorTokens(const char*, PRUint32,
PRBool):405 0x3ffbf84d83c]
    405     if (!aIsFinal) {
(ladebug) p error->code
21
(ladebug) p error->description
class nsString { 
  mLength = 45;                    // struct nsStr
  mCapacity = 64;                  // struct nsStr
  mCharSize = eTwoByte;            // struct nsStr
  mOwnsBuffer = 1;                 // struct nsStr
   = union  { 
    mStr = 0x1404499e0="e"; 
    mUStr = 0x1404499e0; 
  };   // struct nsStr
}
(ladebug) p error->description.ToNewCString()
0x14017e080="error in processing external entity reference"

Comment 5

[Nisheeth Ranjan]

I misunderstood the problem earlier.  I think the right way to fix this is to
make sure that the error returned from nsExpatTokenizer is not propagated from
nsParser::OnDataAvailable() to nsDocumentOpenInfo::OnDataAvailable().  Jim, can
you give that a shot on Tru64 Unix?

Comment 6

[jim_nance]

I tried to do this by making nsParser::OnDataAvailable always return
NS_OK, but that does not work well.  It causes the browser to shut down.
Can you send me a patch for how this should be done?

Comment 7

[jim_nance]

I tried a few different machines, and out of 3 Tru64 machines only 1 has
this bug.  I am going to try and figure out whats different.

Comment 8

[jim_nance]

I tried removing the .mozilla directory on the affected machine and that did
not help.

Comment 9

[jim_nance]

Well the problem has magically disappeared.  I dont know if thats good
or bad.