20228 - [DOGFOOD]Can't change locale provider with the registry.rdf's replacement

Status: VERIFIED FIXED

(Core Graveyard :: RDF, defect, P3)

Description

[tao]

I edited an old registry.rdf, took out unnecessary entries, and drop it into
navigator/locale. It crashed Mozilla M11.

The chrome.rdf for addressbook
-------------------------------

<?xml version="1.0"?> <!-- -*- Mode: SGML; tab-width: 4; indent-tabs-mode: nil
-*- -->

<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns="http://chrome.mozilla.org/rdf#">

  <chrome about="chrome://addressbook/">

    <locale>
      <RDF:Description about="chrome://addressbook/locale/">
        <name>ja-JP</name>
      </RDF:Description>
    </locale>

  </chrome>

</RDF:RDF>


The stack trace:
----------------

     _heap_alloc_base(unsigned int 3722305024) line 161
     _heap_alloc_dbg(unsigned int 3722304976, int 1, const char * 0x00000000,
int 0) line 367 + 9 bytes
     _nh_malloc_dbg(unsigned int 3722304976, int 1, int 1, const char *
0x00000000, int 0) line 242 + 21 bytes

     _nh_malloc(unsigned int 3722304976, int 1) line 194 + 19 bytes
     operator new(unsigned int 3722304976) line 24 + 11 bytes
     nsDeque::GrowCapacity() line 139 + 12 bytes
     nsDeque::Push(void * 0x01b92f40) line 174
     nsHTMLTokenizer::AddToken(CToken * & 0x01b92f40, unsigned int 0, nsDeque &
{...},
     CTokenRecycler * 0x01b298a0) line 150
     nsExpatTokenizer::HandleDefault(void * 0x00000000, const char * 0x00d91eb8,
int 2) line 490 + 27 bytes

     reportDefault(void * 0x0227c170, const encoding * 0x019ec9c0
little2_encoding, const char *
     0x00d92756, const char * 0x00d92756) line 3059 + 32 bytes
     doProlog(void * 0x0227c170, const encoding * 0x019ec9c0 little2_encoding,
const char * 0x00d92752,
     const char * 0x00d9351a, int 15, const char * 0x00d92756, const char * *
0x00000000) line 2627 + 21
     bytes
     prologProcessor(void * 0x0227c170, const char * 0x00d92700, const char *
0x00d9351a, const char * *
     0x00000000) line 2144 + 36 bytes
     prologInitProcessor(void * 0x0227c170, const char * 0x00d92700, const char
* 0x00d9351a, const char *
     * 0x00000000) line 2133 + 21 bytes
     XML_Parse(void * 0x0227c170, const char * 0x00d92700, int 3610, int 1) line
860 + 38 bytes
     nsExpatTokenizer::HandleExternalEntityRef(void * 0x02ac72a0, const char *
0x00000000, const char *
     0x00dd1030, const char * 0x00dd10fa, const char * 0x00000000) line 674 + 30
bytes
     doProlog(void * 0x02ac72a0, const encoding * 0x019ec9c0 little2_encoding,
const char * 0x01eceac8,
     const char * 0x01ed2008, int 17, const char * 0x01eceaca, const char * *
0x0012fb98) line 2271 + 36
     bytes
     prologProcessor(void * 0x02ac72a0, const char * 0x01ece008, const char *
0x01ed2008, const char * *
     0x0012fb98) line 2144 + 36 bytes
     prologInitProcessor(void * 0x02ac72a0, const char * 0x01ece008, const char
* 0x01ed2008, const char *
     * 0x0012fb98) line 2133 + 21 bytes
     XML_Parse(void * 0x02ac72a0, const char * 0x01ece008, int 16384, int 0)
line 867 + 40 bytes
     nsExpatTokenizer::ParseXMLBuffer(const char * 0x01ece008, unsigned int
16384, int 0) line 293 + 24
     bytes
     nsExpatTokenizer::ConsumeToken(nsScanner & {...}) line 336 + 18 bytes
     nsParser::Tokenize(int 0) line 1414 + 21 bytes
     nsParser::ResumeParse(nsIDTD * 0x00000000, int 0) line 959 + 12 bytes
     nsParser::OnDataAvailable(nsParser * const 0x02ac5594, nsIChannel *
0x02ac3ac0, nsISupports *
     0x00000000, nsIInputStream * 0x02ac3b98, unsigned int 0, unsigned int 8192)
line 1310 + 19 bytes
     nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x02ac2200,
nsIChannel *
     0x02ac3ac0, nsISupports * 0x00000000, nsIInputStream * 0x02ac3b98, unsigned
int 0, unsigned int 8192)
     line 1414 + 43 bytes
     nsChannelListener::OnDataAvailable(nsChannelListener * const 0x02ac3a40,
nsIChannel * 0x02ac3ac0,
     nsISupports * 0x00000000, nsIInputStream * 0x02ac3b98, unsigned int 0,
unsigned int 8192) line 1567
     nsFileChannel::OnDataAvailable(nsFileChannel * const 0x02ac3ac4, nsIChannel
* 0x02ac20b0,
     nsISupports * 0x00000000, nsIInputStream * 0x02ac3b98, unsigned int 0,
unsigned int 8192) line 495
     nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const
0x02ac6460) line 417
     nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x02ac6410) line 173 + 12
bytes
     PL_HandleEvent(PLEvent * 0x02ac6410) line 537 + 10 bytes
     PL_ProcessPendingEvents(PLEventQueue * 0x00c75640) line 498 + 9 bytes
     _md_EventReceiverProc(HWND__ * 0x01ec06ce, unsigned int 49215, unsigned int
0, long 13063744)
     line 972 + 9 bytes
     USER32! 77e713ed()
     00c75640()

Comment 1

[David Hyatt]

M11 isn't in a working state as far as the chrome.rdf file is concerned.  You
need to do this with a current build.

Also your RDF file is wrong.  It should be...

<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns="http://chrome.mozilla.org/rdf#">
      <RDF:Description about="chrome://addressbook/locale/">
        <name>ja-JP</name>
      </RDF:Description>
</RDF:RDF>

Comment 2

[leger]

tao, we need more info...we believe this may be a "power-user" error.  Can you
provide more info?  We will re-evaluate tomorrow.

Comment 3

[tao]

I retested it with Hyatt's chrome.rdf and it still crashed with the same stack
trace.

The chrome.rdf file is used to inform Mozilla where to pick up
locale-specific information (choosing between English and localized UI).

Localization group won't be able to indicate the location of localized UI
resources files if this mechanism does not work. We can't ship localized build
without fixing this bug.

Feel free to contact me if you need help reproducing the crash or
explaining why this is a show stopper!

Comment 4

[bobj]

Was this on M11 or a current build?

Comment 5

[tao]

Sorry that I missed out the build date in previous comments.

It crashed on M11 build, Nov-11-29 commerical build, and my local build of
Nov-23-99.

Thanks

Comment 6

[leger]

Putting on PDT+ radar.

Comment 7

[tao]

Hi, Hyatt:

I don't understand why would you reassign the bug to me. Do you see it as a user
error or the stack trace indicate you're not the owner?

CC nisheeth.

Comment 8

[tao]

I inserted a printf in the chrome conversion routine and it did correctly
map the chrome URL to the proper "resource" URL.

Reassign to Nisheeth.

Comment 9

[Nisheeth Ranjan]

Rick, I have 3 PDT+ bugs on my plate currently.  Going by the stack trace it
seems like the XML tokenizer is crashing while trying to add a token to the
token queue.  Do you think you could spend some time on this?  Please re-assign
this back to me if you can't and I'll get to it as soon as I can. Thanks.

Comment 10

[tao]

Attachment: An NT purify session (mozilla.pfy)

Comment 11

[tao]

I had attached a purify session, mozilla.pfy, to this report. It appears that
there are tons of IPR and IPW before crashing. They occur mostly in this calling
chain:

    nsFileSpecHelpers::UnixToNative(nsSimpleCharString&) [nsFileSpecWin.cpp:113]
    nsFileSpec::+=(char const*) [nsFileSpecWin.cpp:394]
    nsChromeRegistry::CheckForProfileFile(nsCAutoString const&,nsCAutoString&)
[nsChromeRegistry.cpp:1171]
    nsChromeRegistry::LoadDataSource(nsCAutoString const&,nsIRDFDataSource *
*,int) [nsChromeRegistry.cpp:595]
    nsChromeRegistry::InitializeDataSource(nsString&,nsString&,nsIRDFDataSource
* *,int) [nsChromeRegistry.cpp:666]
    nsChromeRegistry::ConvertChromeURL(nsIURI *) [nsChromeRegistry.cpp:405]
    nsChromeProtocolHandler::NewChannel(char const*,nsIURI *,nsILoadGroup
*,nsIInterfaceRequestor *,UINT,nsIURI *,nsIChannel * *)
[nsChromeProtocolHandler.cpp:142]
    nsIOService::NewChannelFromURI(char const*,nsIURI *,nsILoadGroup
*,nsIInterfaceRequestor *,UINT,nsIURI *,nsIChannel * *) [nsIOService.cpp:247]
    NS_OpenURI(nsIChannel * *,nsIURI *,nsILoadGroup *,nsIInterfaceRequestor
*,UINT) [nsNeckoUtil.cpp:71]
    nsDocumentBindInfo::Bind(nsIURI *,nsILoadGroup *,nsIInputStream *,WORD
const*) [nsDocLoader.cpp:1297]



Hope that this helps.

Comment 12

[rickg]

Chris -- this one looks like fun for you.

Comment 13

[Mike Pinkerton (not reading bugmail)]

I'll take this away from an overworked hyatt. Give me a few days, though, I've
never seen any of this code before in my life.

Comment 14

[Mike Pinkerton (not reading bugmail)]

accepting

Comment 15

[Mike Pinkerton (not reading bugmail)]

Nisheeth and I looked at this and here is what is happening:

The crash occurs while we are parsing hiddenWindow.xul. It loads in navigator.dtd
and we're parsing the first comment in that file. At this point, the global deque
|gTokenDeque| in the expatTokenizer has been deleted by the time that the comment
is being parsed, and so trying to call AddToken() crashes because the deque is
garbage.

I think the purify logs pointing to the chrome registry code that accompany this
bug might be red herrings and unrelated, though should be investigated
separately.

per Nisheeth's advice, pushing to rickg. Nisheeth says he will be away for the
xml '99 conference until Thurs. so he will be unavailable to take this bug
himself.

Comment 16

[rickg]

Tell Nisheeth I said "thanks a lot" for this bug.

Comment 17

[rickg]

Fix in hand. Doing verification and awaiting approval for checkin.

Comment 18

[rickg]

There were 3 classes of problems here. First, we needed to use refcounting on
tokenizers because their scope has now exceeded the parser (alone). Second, we
have interesting stack problems, which are eliminated by adding a self ref-count
on expattokenizer while expat runs. Third, expattokenizer was dereferencing ptrs
without checking.

In addition to testing for this bug, I also did the precheckin smoke tests,
viewed-source on files, and saved HTML documents in the editor.

Comment 19

[David Hyatt]

Thanks, Rick! I appreciate you looking at this!

Comment 20

[tao]

I tested dec-10-99 mozilla build and dec-13-99 commercial build on NT. It does
 not crash anymore; instead, when a chrome.rdf presents in a locale/ directory,
the first attempt to bring up the affected window (e.g. Addressbook) will
cause a funky browser frame to pop up with an oversized canvas/pixmap.
If you close this funky window and reopen it (Addressbook) again, the new
window will just render fine with the proper localized UI.

I'll "VERIFY" this bug and log a second one for the funky window problem.

Comment 21

[tao]

A separate bug for the funky window problem:
http://bugzilla.mozilla.org/show_bug.cgi?id=21647, "[BETA] locale/chrome.rdf
hangs or causes funky window".