214026 - crash opening address book

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Address Book & Contacts, defect)

Description

[Daniel Kies]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030726
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030726

Clicking on the address book icon, or using the keyboard shortcut to the address
book, results in a crash.

Reproducible: Always

Steps to Reproduce:
1. Start Mozilla 2003072604 build on win98se
2. Click (or short cut to) address book
3. Crash



The crash occurs just as the Personal address book is about to be populated with
individual records (the different address books -- personal, etc., are visible).

Talkback IDs:

TB22225705X
TB22225652G
TB22224653E
TB22224081M
TB22227584M

Stack dumps:

MOZILLA caused an invalid page fault in
module MSVCRT.DLL at 0167:780025b4.
Registers:
EAX=021000d0 CS=0167 EIP=780025b4 EFLGS=00010246
EBX=02972aa0 SS=016f ESP=0065e47c EBP=0065e4a4
ECX=00000000 DS=016f ESI=0065e7e0 FS=41ff
EDX=00000000 ES=016f EDI=02972ea0 GS=0000
Bytes at CS:EIP:
8b 02 3a 01 0f 84 0d eb 00 00 1b c0 d1 e0 40 c3 
Stack dump:
6118ce50 00000000 00000000 61c17163 021000d0 00000000 00000000 00000000 00000000
0065e4b8 0065e4c8 61c170e3 00000000 00000000 00000000 00000000 

MOZILLA caused an invalid page fault in
module MSVCRT.DLL at 0167:780025b4.
Registers:
EAX=02cfcf90 CS=0167 EIP=780025b4 EFLGS=00010246
EBX=029cb390 SS=016f ESP=0065e47c EBP=0065e4a4
ECX=00000000 DS=016f ESI=0065e7e0 FS=59b7
EDX=00000000 ES=016f EDI=029cb790 GS=0000
Bytes at CS:EIP:
8b 02 3a 01 0f 84 0d eb 00 00 1b c0 d1 e0 40 c3 
Stack dump:
6118ce50 00000000 00000000 61c17163 02cfcf90 00000000 00000000 00000000 00000000
0065e4b8 0065e4c8 61c170e3 00000000 00000000 00000000 00000000

Comment 1

[Charles Fenwick]

Crashed for me as well on WIN98, using 072604  (Talkback ID TB22228676X). 

Tried on 072404 and did not crash.  

Investigation ongoing...

Comment 2

[Charles Fenwick]

Crash occurs in 072504 build as well, so the bug was introduced sometime between
07/24/2003 07:00 and 07/25/2003 07:00.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=07%2F24%2F2003+07%3A00%3A00&maxdate=07%2F25%2F2003+07%3A00%3A00&cvsroot=%2Fcvsroot

shows the possible suspects... 

Comment 3

[Daniel Kies]

Still crashing on start of address book in recent nightlies.

Talkback IDs:

TB22283706M with 20030728 build on win98se 
TB22299273X with 20030729 build on win98se

Comment 4

[Daniel Kies]

I just tried an experiment.  Installing the 2003072904 nightly in a new
directory with a fresh profile, I could open the address book without problems.
 I then shut down the browser, and copied my old address book into the new
profile, after changing the name of the new, empty address book.  Restarting and
opening the address book resulted in a crash: TB22314568G.

I then restored the new, empty address book in the fresh profile and
restarted/re-opened the address book.  No crash.

There is definitely something "wrong" with the structure of my address book
crashing the recent nightlies.  I would be happy to share my address book with
you if you need it for diagnostics.

Comment 5

[Daniel Kies]

Second experiment: I started my 20030723 build and exported my address book to
ldif format.  I then started the 20030729 build with the new profile and
imported  my old address book.  Import was successful, but clicking on the
imported address book icon in the list of address books in the crashed Moz build
20030729.  

TB22314927Z

Apparently, the foulness in the structure of my address book crashing Moz
survives even through the process of exporting/importing address books.  Now I
am worried.  If I can't find a way to transfer my address book, I'm sunk.

Comment 6

[Daniel Kies]

Note on second experiment:  I could open the imported, corrupted address book
that crashed in the second experiment by clicking the twisty.  Although the
importing process reported success, not all the subfolders I expected to see
were visible.

Third experiment:  I started my 20030723 build and exported my address book to
csv format.  I then started the 20030729 build with the new profile and
imported  my old address book from csv format.  Import was successful, but
clicking on the imported address book icon in the list of address books crashed
Moz build 20030729.  

TB22315359M, TB22315337E

Interestingly, this import has no twisty next to the imported csv version of the
old address book.  Enough for tonight as I have class to teach in the morning. 
Good night, friends.

Comment 7

[Charles Fenwick]

Good observation.  I think I may have figured out what's going on.

If you have an older nightly or a branch (1.4) open your addressbook (the one
that causes a crash) in it.  Look at your Personal address book and see if you
have entries that have "weird" characters in them (i.e. not' a true address book
entry, if you click on it, it has an entry for 'displayu' and nothing else).

I'm really interested to see if you have such an entry as the first one in your
book.

If you have one as the first card in your book , delete it, and any others until
you have a "good" card, as the first in the list.  Then open up the book in a
nightly that it crashed in, and see if it causes a crash.

I had about 30 such inavalid cards in my book.  I deleted a bunch of them (but
not all of them).  Opened the address book in a nightly that it previously
crashed in, and it worked.  

My guess is that the crash will only happen if you have an invalid entry as the
first in your book, but I've no way of confirming it, unless that is what's
causing your crash as well.  

Comment 8

[Charles Fenwick]

I've been playing with this for the past couple of hours ...

-if you have an entry in you address book that contains non-ascii characters, a
crash occurs if you try to sort the address book (alway)

-trying to modify an entry that contains nono-ascii characters will cause a
crash (after hitting ok,) more often than not.

- if several of the first entries in the address book contain non-ascii
characters, then a crash will occur on start-up every time.

This checkin *might* be the source of the problem:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=neil%25parkwaycc.co.uk&whotype=match&sortby=Date&hours=2&date=explicit&mindate=07%2F24%2F2003+13%3A31%3A00&maxdate=07%2F24%2F2003+13%3A31%3A59&cvsroot=%2Fcvsroot

Comment 9

[Simon Montagu :smontagu]

I managed to reproduce the crash in a debug build when sorting the address book.

Stack:
strcmp() line 77
nsCollationWin::CompareRawSortKey(nsCollationWin * const 0x0171ef38, const
unsigned char * 0x00000000, const unsigned int 0x00000000, const unsigned char *
0x00000000, const unsigned int 0x00000000, int * 0x0012cb4c) line 57 + 16 bytes
nsAbView::CompareCollationKeys(unsigned char * 0x00000000, unsigned int
0x00000000, unsigned char * 0x00000000, unsigned int 0x00000000) line 746 + 46 bytes
inplaceSortCallback(const void * 0x01722d68, const void * 0x017239b8, void *
0x0012cd18) line 632 + 39 bytes
VoidArrayComparator(const void * 0x01722dc8, const void * 0x01722dcc, void *
0x0012cc14) line 626 + 24 bytes
NS_QuickSort(void * 0x01722dc8, unsigned int 0x00000002, unsigned int
0x00000004, int (const void *, const void *, void *)* 0x1001d940
VoidArrayComparator(const void *, const void *, void *), void * 0x0012cc14) line
119 + 37 bytes
nsVoidArray::Sort(int (const void *, const void *, void *)* 0x04dea4b0
inplaceSortCallback(const void *, const void *, void *), void * 0x0012cd18) line
635 + 36 bytes
nsAbView::SortBy(nsAbView * const 0x03c9b2e8, const unsigned short * 0x04f68ec8,
const unsigned short * 0x03d478f0) line 726
XPTC_InvokeByIndex(nsISupports * 0x03c9b2e8, unsigned int 0x00000005, unsigned
int 0x00000002, nsXPTCVariant * 0x0012cf48) line 102
XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode
CALL_METHOD) line 2017 + 42 bytes
XPC_WN_CallMethod(JSContext * 0x03371948, JSObject * 0x03def1e0, unsigned int
0x00000002, long * 0x04f77194, long * 0x0012d200) line 1269 + 14 bytes
js_Invoke(JSContext * 0x03371948, unsigned int 0x00000002, unsigned int
0x00000000) line 843 + 23 bytes
js_Interpret(JSContext * 0x03371948, long * 0x0012db14) line 2859 + 15 bytes
js_Invoke(JSContext * 0x03371948, unsigned int 0x00000001, unsigned int
0x00000002) line 860 + 13 bytes
js_InternalInvoke(JSContext * 0x03371948, JSObject * 0x03d594b0, long
0x03defe00, unsigned int 0x00000000, unsigned int 0x00000001, long * 0x0012dd74,
long * 0x0012dc44) line 935 + 20 bytes
JS_CallFunctionValue(JSContext * 0x03371948, JSObject * 0x03d594b0, long
0x03defe00, unsigned int 0x00000001, long * 0x0012dd74, long * 0x0012dc44) line
3533 + 31 bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x03b88aa0, void * 0x03d594b0,
void * 0x03defe00, unsigned int 0x00000001, void * 0x0012dd74, int * 0x0012dd78,
int 0x00000000) line 1217 + 33 bytes
nsJSEventListener::HandleEvent(nsJSEventListener * const 0x016b5438, nsIDOMEvent
* 0x04f683e8) line 181 + 77 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x016b5518,
nsIDOMEvent * 0x04f683e8, nsIDOMEventTarget * 0x04f682b8, unsigned int
0x00000004, unsigned int 0x00000002) line 1194 + 20 bytes
nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x016b53d0,
nsIPresContext * 0x03b2e230, nsEvent * 0x0012f1f8, nsIDOMEvent * * 0x0012f0b4,
nsIDOMEventTarget * 0x04f682b8, unsigned int 0x00000002, nsEventStatus *
0x0012f580) line 1363 + 36 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x03b5bc20, nsIPresContext *
0x03b2e230, nsEvent * 0x0012f1f8, nsIDOMEvent * * 0x0012f0b4, unsigned int
0x00000002, nsEventStatus * 0x0012f580) line 3245
nsXULElement::HandleDOMEvent(nsXULElement * const 0x03d2a838, nsIPresContext *
0x03b2e230, nsEvent * 0x0012f1f8, nsIDOMEvent * * 0x0012f0b4, unsigned int
0x00000002, nsEventStatus * 0x0012f580) line 3262 + 61 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x04f1db60, nsIPresContext *
0x03b2e230, nsEvent * 0x0012f1f8, nsIDOMEvent * * 0x0012f0b4, unsigned int
0x00000007, nsEventStatus * 0x0012f580) line 3262 + 61 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012f1f8, nsIView * 0x00000000,
unsigned int 0x00000001, nsEventStatus * 0x0012f580) line 6217 + 42 bytes
PresShell::HandleEventWithTarget(PresShell * const 0x030d5428, nsEvent *
0x0012f1f8, nsIFrame * 0x03e25f44, nsIContent * 0x04f1db60, unsigned int
0x00000001, nsEventStatus * 0x0012f580) line 6174 + 22 bytes
nsEventStateManager::CheckForAndDispatchClick(nsIPresContext * 0x03b2e230,
nsMouseEvent * 0x0012f798, nsEventStatus * 0x0012f580) line 2948 + 66 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x03d987c8,
nsIPresContext * 0x03b2e230, nsEvent * 0x0012f798, nsIFrame * 0x03e25f44,
nsEventStatus * 0x0012f580, nsIView * 0x03cc06b0) line 1930 + 23 bytes
PresShell::HandleEventInternal(nsEvent * 0x0012f798, nsIView * 0x03cc06b0,
unsigned int 0x00000001, nsEventStatus * 0x0012f580) line 6262 + 49 bytes
PresShell::HandleEvent(PresShell * const 0x030d5440, nsIView * 0x03cc06b0,
nsGUIEvent * 0x0012f798, nsEventStatus * 0x0012f580, int 0x00000001, int &
0x00000001) line 6112 + 25 bytes
nsViewManager::HandleEvent(nsView * 0x03cc06b0, nsGUIEvent * 0x0012f798, int
0x00000000) line 2299
nsView::HandleEvent(nsViewManager * 0x04f0d538, nsGUIEvent * 0x0012f798, int
0x00000000) line 305
nsViewManager::DispatchEvent(nsViewManager * const 0x04f0d538, nsGUIEvent *
0x0012f798, nsEventStatus * 0x0012f690) line 2036 + 23 bytes
HandleEvent(nsGUIEvent * 0x0012f798) line 79
nsWindow::DispatchEvent(nsWindow * const 0x03cc075c, nsGUIEvent * 0x0012f798,
nsEventStatus & nsEventStatus_eIgnore) line 1050 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f798) line 1071
nsWindow::DispatchMouseEvent(unsigned int 0x0000012d, unsigned int 0x00000000,
nsPoint * 0x00000000) line 5191 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 0x0000012d, unsigned int
0x00000000, nsPoint * 0x00000000) line 5448
nsWindow::ProcessMessage(unsigned int 0x00000202, unsigned int 0x00000000, long
0x00720184, long * 0x0012fc30) line 3981 + 28 bytes
nsWindow::WindowProc(HWND__ * 0x00811052, unsigned int 0x00000202, unsigned int
0x00000000, long 0x00720184) line 1333 + 27 bytes
USER32! 77e3a244()
USER32! 77e145e5()
USER32! 77e1a792()
nsAppShellService::Run(nsAppShellService * const 0x00edac90) line 478
main1(int 0x00000001, char * * 0x00262698, nsISupports * 0x00e08098) line 1290 +
32 bytes
main(int 0x00000001, char * * 0x00262698) line 1669 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77ea847c()

Comment 10

[[e-mail]]

Attachment: Clean up collation key generator

Comment 11

[David :Bienvenu]

I'm seeing this crash too. I'll apply the patch and see if it fixes it, and if
it does, I'll r= it.

Comment 12

[David :Bienvenu]

Comment on attachment 128892 [details] [diff] [review]
Clean up collation key generator

sr=bienvenu, this fixes the crash for me, and looks OK.

Comment 13

[Simon Montagu :smontagu]

Comment on attachment 128892 [details] [diff] [review]
Clean up collation key generator

r=smontagu.

Comment 14

[[e-mail]]

Fix checked in, but changing nsAbView.h not nsABView.h ;-)