With a new profile (not sure if it happens with an existing profile) When you launch the browser on AIX, if you type in the URL field, the browser crashes. What I have found is that -nsGlobalHistory::OnStartLookup calls OnAutoComplete (autocomplete.xml) -OnAutocomplete calls processResults (autocomplete.xml) -processResults calls openResultsPopup (autocomplete.xml) -openResultsPopup (autocomplete.xml), when it tries to resolve the width "var w = this.boxObject.width;" it calls nsBoxObject::GetOffsetRect and mContent is NULL (for AIX only) and so we crash. I am guessing that somewhere along the line the 'boxObject' of autocomplete is either poorly initialized or AIX is just wigging out on us. I have been looking at this for several days and I can't figure out how autocomplete's openResultsPopup's this.boxObject is being initialized and with what. The XML/js is slightly confusing to me. I need help on this one.
accepting, but hoping hewitt can help me, point me to something to try...
Status: NEW → ASSIGNED
Ok, this has to do with the AIX assembly xptcall code and specifically the last update we put in to the xptc_invoke code. We will need to back this change out. In doing so, we will break editor... but I have a 'fix'/'hack' for that.
In order to fix autocomplete I have to go back to my code for xptcinvoke_asm_ppc_aix.s. However this breaks the launching of editor (on AIX). My fix for this is to change the order of baseclasses for nsComposerController Scott might understand this better, but I will give it a shot. Here is what I THINK is happening: Someone is instantiating/creating/invoking a nsIEditorController object. When we do a query interface on nsComposerController, the object that is returned is the pointer for the nsIEditorController base class which is 4 bytes (one word) off from nsComposerController. Then later on a method off of this object (nsIEditorController object) is invoked, but somehow AIX confuses the nsComposerController ptr with the nsIEditorController ptr and we end up accessing the word that is stored 4 bytes before the nsComposerController (in memory) and we core. By simply aligning the nsIEditorController object with the base object we don't run into this case. In fact I would like to ask that in the future that the first base class of any xpcom object (not sure if that is the 'right' term) be the class that is the ambiguous iSupports object. So for this change... I need the review of someone who owns the editor file and I also need scc to sign off on it. (I own the xptcinvoke file and am just going back to the previous version).
*** Bug 101703 has been marked as a duplicate of this bug. ***
*** Bug 98891 has been marked as a duplicate of this bug. ***
Created attachment 59958 [details] [diff] [review] xptcinvoke diff to fix the sub-classing problem We finally found the problem with the subclassing. I was grabbing the wrong vtable.
Attachment #43361 - Attachment is obsolete: true
cls I am looking for an sr= to checkin this is AIX assembly only.
Target Milestone: --- → mozilla0.9.7
Make sure to test View | Message Source as well, as this stems from the DUP bug 98891.
Comment on attachment 59958 [details] [diff] [review] xptcinvoke diff to fix the sub-classing problem r=cls
Attachment #59958 - Flags: review+
Fix checked in...
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.