378456 - Crashes when choosing a download file save location [@ TNavNode::TNavNode[in-charge](TNavNode const&)]

Status: RESOLVED INVALID

(Core :: Widget: Cocoa, defect)

Description

[James Rome]

Attachment: my save as dialog

This is in SeaMonkey 1.1.1 on a MacPro with 8 cpus and 8 GB of memory.
Downloading a file from any URL causes me problems. I thin k the behavior might only be evidenced after the first download. I am new to Macs, so maybe I have a cockpit error, but Seamonkey should not crash!

I want to save the files in a download directory in my home area jar/download. In the attached pic, I can single-click or double-click download, and the file still gets put into jar rather than jar/download. But I would think that double-clicking download should open it. It never does. Instead, it often crashes SeaMonkey!

So how is one supposed to choose a file download location?

I have not seen any talkback anything in the OS X version. If you tell me where to look, I will send files

Comment 1

[Adam Guthrie]

Does the Apple Crash Reporter tool appear? That should give you a stacktrace that you can attach here.

Comment 2

[James Rome]

Yes. Are they saved somewhere?

Comment 3

[Adam Guthrie]

Looks like they should be in ~/Library/Logs/CrashReporter.

Comment 4

[James Rome]

Attachment: crash report

Comment 5

[Adam Guthrie]

It looks like it's crashing completely within Mac OS X code (which means it's not a bug in SeaMonkey). Here's the top few frames of the stacktrace:

0   0x92d65540 TNavNode::TNavNode[in-charge](TNavNode const&) + 12
1   0x92d930d3 std::vector<TNavNode, std::allocator<TNavNode> >::_M_insert_aux(__gnu_cxx::__normal_iterator<TNavNode*, std::vector<TNavNode, std::allocator<TNavNode> > >, TNavNode const&) + 287
2   0x92d93190 std::vector<TNavNode, std::allocator<TNavNode> >::push_back(TNavNode const&) + 62
3   0x92d8f567 TPathPopup::FillPopup() + 297
4   0x92d8f831 TPathPopup::MenuHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*) + 75
5   0x92de6537 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1093
6   0x92de5bdc SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 304
7   0x92de5aa1 SendEventToEventTargetWithOptions + 55
8   0x92e87c77 SendTrackingStatus(unsigned long, MenuData*, unsigned long, unsigned long, unsigned long, unsigned long, unsigned char) + 389
9   0x93025339 SendBeginTracking(MenuData*, unsigned long, unsigned long, MenuSelectData*) + 55
10  0x92e86e0e SetupMenuTracking(MenuSelectData&, unsigned char, Point, double, MenuData*, unsigned long, Rect const*, Rect const*, GDevice**, Rect const*, __CFString const*) + 1656
11  0x92ec65fc PopUpMenuSelectCore(MenuData*, Point, double, Point, GDevice**, Rect const*, unsigned short, unsigned long, Rect const*, Rect const*, __CFString const*, OpaqueMenuRef**, unsigned short*) + 170
12  0x92ec6504 _HandlePopUpMenuSelection5 + 580
13  0x92fbd4f2 HIPopupButton::TrackMenu() + 1162
14  0x92fbd6d7 HIPopupButton::TrackSelfCommon(short, short*) + 59

Comment 6

[James Rome]

I sent them all off to Apple. Gee, I thought switching from a PC was supposed to make for fewer crashes ;-)

I was able to save properly if I used the column display mode instead of the details mode.

Thanks. I guess you can change the status.

Comment 7

[Shane Caraveo]

Rename the second hard drive to be different than the first to fix the crashes.  see bug 379426