Closed Bug 391020 Opened 18 years ago Closed 18 years ago

Crash when autocomplete addresses after address book was opened

Categories

(MailNews Core :: Address Book, defect)

Product:
MailNews Core
Component:
Address Book
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 390707

People

(Reporter: whimboo, Unassigned)

Details

(Keywords: crash, regression)

With the check-in of the last patches on bug 203927 into the trunk I can reproduce a crash of Thunderbird while it tries to autocomplete the address within the composer window. Following steps you have to do: 1. Add the hidden prefs to your prefs.js or via config editor 2. Start Thunderbird 3. Open the address book (you can see the OS X address book?) 4. If yes close the address book and start writing a new mail 5. Press a key to give the first letter of a name => Thunderbird crashes immediately without any crash information. The crashreporter only tells me: "Couldn't find the crash reporter's settings.". Also my debug build doesn't give any information about the stack. Anyone who gets a full stack trace? Scott, do you know what's wrong with breakpad? What settings it cannot find? The crashreporter.ini is still existent here.
Hmm, you're sure this isn't bug 390773?
As long as I don't have a reliable stack trace I can't answer your question. I downloaded a nightly build from Saturday and there the crash also happens. So it has nothing to do with Davids check-in. I will try to find a regression window within the next days. Seems to be Mac specific.
Keywords: regression
Summary: Crash when autocomplete addresses with OS X system address book → Crash when autocomplete addresses after address book was opened
Looks like the crash reporter fires that error if this methods fails: http://mxr.mozilla.org/seamonkey/source/toolkit/crashreporter/client/crashreporter_osx.mm#468 I sure hope this isn't another problem because we don't set the vendor string to Mozilla over in http://mxr.mozilla.org/seamonkey/source/mail/app/application.ini#40 because that breaks our default profile location (Bug 247973), but I have a sinking suspicion it is...
Scott, does that only happen for Mac OS X or are Windows and Linux also affected? I wasn't able to produce a crash under these OS, so I've no idea. But wouldn't it be a chance to reconsider the decision on bug 247973 if that's the cause? I will try to apply your patch from comment 9 and lets see if it still happens.
Scott, that path explicitly doesn't use the vendor on OS X, by platform convention. I'm puzzled as to why that would fail though.
(In reply to comment #3) > http://mxr.mozilla.org/seamonkey/source/mail/app/application.ini#40 because > that breaks our default profile location (Bug 247973), but I have a sinking > suspicion it is... Scott, that's the cause! I copied my existing profile to that location and the crash reporter is working fine. I'll file a new bug on that. Here the crash report for this issue: http://crash-stats.mozilla.com/report/index/c3de07b3-4530-11dc-9776-001a4bd43ed6?date=2007-08-07-21 UUID c3de07b3-4530-11dc-9776-001a4bd43ed6 Time 2007-08-07 14:54:26.120000-07:00 Build ID 2007080503 OS Mac OS X OS Version 10.4.10 8R2218 CPU x86 CPU Info GenuineIntel family 6 model 15 stepping 6 Crash Reason EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE Crash Address 0x90a594c7 Stack Traces Stack of Crashing Thread frame signature source 0 libobjc.A.dylib@0x24c7 1 AppKitMenuEventHandler 2 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) 3 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) 4 SendEventToEventTargetWithOptions 5 SendMenuPopulate(MenuData*, OpaqueEventTargetRef*, unsigned long, double) 6 PopulateMenu(MenuData*, OpaqueEventTargetRef*, CheckMenuData*, unsigned long, double) 7 Check1MenuForKeyEvent(MenuData*, CheckMenuData*) 8 CheckEachHMenuForKeyEvent(MenuData*, unsigned long) 9 ForEachInstalledHMenuDo(long (*)(MenuData*, unsigned long), unsigned long) 10 CheckMenusForKeyEvent(MenuData*, CheckMenuData*) 11 _IsMenuKeyEvent(MenuData*, OpaqueEventRef*, unsigned long, MenuData**, unsigned short*) 12 IsMenuKeyEvent 13 _NSGetMenuItemForCommandKeyEvent 14 _NSHandleCarbonMenuEvent 15 _DPSNextEvent 16 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 17 nsAppShell::ProcessNextNativeEvent(int) mozilla/widget/src/cocoa/nsAppShell.mm:309 18 nsBaseAppShell::DoProcessNextNativeEvent(int) mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:137 19 nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, int, unsigned int) mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:247 20 nsThread::ThreadFunc(void*) nsThread.cpp:260 21 nsTArray_base::ShrinkCapacity(unsigned int) nsTArray.cpp:146 22 nsBaseAppShell::Run() mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:154 23 -[AppShellDelegate runAppShell] mozilla/widget/src/cocoa/nsAppShell.mm:459 24 __NSFireDelayedPerform 25 CFRunLoopRunSpecific 26 CFRunLoopRunInMode 27 RunCurrentEventLoopInMode 28 ReceiveNextEventCommon 29 BlockUntilNextEventMatchingListInMode 30 _DPSNextEvent
this might be the mac top crasher we're seeing in firefox.
There is a similar bug filed for Camino (bug 377203). But I don't think that they are related. But if we also have this crash for Firefox the patch on bug 377203 could also help us? But that would be another bug. There are only 2 crashes listed with this stack trace for Thunderbird 3a1.
The stack looks like the one in bug 390773 (fixed yesterday, seem to have fixed bug 390773 as well).
Yes, the crash doesn't occur anymore. So you were right with your suspicion. I still forgot to have a look at the mentioned bug again.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.