From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001010 BuildID: 2000101014 I tried to import data from Eudora 5.0. I have multiple folders, a lot of messages and some attachments manually deleted. When I start importing, progress bar moves to a certain point and then Mozilla crashes. Reproducible: Always Steps to Reproduce: I set up my mail account manually - it's not imported from Eudora. I tried to import data with File -> Import -> Mail -> Eudora. Actual Results: Crash Expected Results: Imported data. Lot of messages. Multiple nested folders. Some messages have attachments manually deleted.

Update: I tried import once again and got alert message instead of crash at the same progress bar position. It says: This message contains characters not found in the chosen Character Coding. The message may be unreadable to the recipient. Send it anyway or "Cancel" to choose a different Caharacter Coding. I think that problem is with non-US encodings (Win 1250, 1252). At one of those messages it stopped for a bery long time, and "Close" and other options from taskbar menu were unaccessible. 4 browser windows and mail client occupied 51 MB! Message that confirms import have bug - it shows square instead of CR/LF (there is no newline between import statistics for separate folders).

seth: please take a look.

adding tony to the cc list. I'll investigate tomorrow. zeljko, can you give me a sample of one of the messages that were crashing for you? you can send it to me at sspitzer@netscape.com or sspitzer@sspitzer.org

FYI: Eudora import parses the original Eudora message, which is not really in rfc822 format, and reassembles the message using nsIMsgSend. By the way, I think that a feature was added to nsIMsgSend that should be used by the import but currently is not - SetGUINotificationState - nsIMsgSend should not be displaying error messages when called from the import, you could get hundreds of error dialogs! If you can forward me the message as well I'd be happy to track down where the problem is.

I'm unable to reproduce this. (I used eudora 4.3, saved a sample message from Zeljko to In.mbx and then imported into 6.0) I've asked Zeljko to send me his entire .mbx file that causes the crash.

I haven't gotten a .mbx file from Zeljko to reproduce this.

import -> tony

Build 2001-02-26-09: NT4 Also Using Eudora 5.2, I'm able to reproduce a crash importing Eudora Mail. 1. Talkback# 27011991 Call Stack: (Signature = ntdll.dll + 0x4b6d (0x77f64b6d) 493647d7) ntdll.dll + 0x4b6d (0x77f64b6d) MSVCRT.dll + 0x1385 (0x78001385) MSVCRT.dll + 0x12d9 (0x780012d9) xpcom.dll + 0x1ed2 (0x60d21ed2) xpcom.dll + 0x1df5 (0x60d21df5) xpcom.dll + 0x3994 (0x60d23994) xpcom.dll + 0x19f5 (0x60d219f5) xpcom.dll + 0x1d49 (0x60d21d49) xpcom.dll + 0x1cf6 (0x60d21cf6) xpcom.dll + 0x77e6 (0x60d277e6) impEudra.dll + 0x6eb7 (0x60426eb7) impEudra.dll + 0x77a4 (0x604277a4) impEudra.dll + 0x740b (0x6042740b) impEudra.dll + 0x2703 (0x60422703) impEudra.dll + 0x1d26 (0x60421d26) import.dll + 0x381a (0x6043381a) nspr4.dll + 0x136d1 (0x60c936d1) MSVCRT.dll + 0x12b1 (0x780012b1) KERNEL32.dll + 0x4ee8 (0x77f04ee8) 2. Talkback# 26977397 Call Stack: (Signature = ntdll.dll + 0x1d465 (0x77f7d465) bbe4098a) ntdll.dll + 0x1d465 (0x77f7d465) ntdll.dll + 0x4111 (0x77f64111) ntdll.dll + 0x4830 (0x77f64830) MSVCRT.dll + 0x1385 (0x78001385) MSVCRT.dll + 0x12d9 (0x780012d9) impEudra.dll + 0x7981 (0x60427981) impEudra.dll + 0x7a5b (0x60427a5b) impEudra.dll + 0x2724 (0x60422724) impEudra.dll + 0x1d26 (0x60421d26) import.dll + 0x381a (0x6043381a)

Marking nsbeta1 since a crash should not occur when importing.

reassigning to chuang. Candice, could you look into this? It looks like the crash may not be in our code, so if it isn't, let's reassign to the right person.

reassign to Tony.

reassigning back to chuang due to miscommunication error on my part.

re-assign to cavin

moving to mozilla0.9.1

cavin, can you elaborate on the "move message" problem? is there a bug on that? if not, can you log it? if yes, you should take it and when we check in we can mark it fixed. I'm going to test cavin's code on my outlook account and then try to get it in for 0.9

moving to 0.9.1. I don't have any problem getting this into 0.9 if they take it but it's not a blocker so moving off the list.

sounds good to me. I'll get this tested, reviewed and landed on the trunk today.

still testing, sorry for the delay

looks good. sr=sspitzer I also made a change to http://lxr.mozilla.org/seamonkey/source/mailnews/import/oexpress/nsOE5File.cpp#2 22 along the same lines. I'll attach the latest version of the patch. reading http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/content%2Dlength.html, it seems that we should be handling both "From ???@???" and "From -". cavin, was having "From ???@???" as our delimiter causing us problems?

ok, looking nsParseMailMessageState::IsEnvelopeLine(), we should do the right thing in either case. (at least as far as parsing goes.) cavin, what is the "move message problem"? how does fixing the "???@???" fix it?

I have a feeling that the move message problem is fixed by cavin's fix for various versions of SpecialMemCpy() I don't think the "@@@?@@@" stuff needs to be changed. I'll attach a minimal patch (based on cavin's patch).

Seth, the "move message problem" is fixed by changing "???@???" to "-" in the 'From ' line. Without it you can't move imported messages to any server folders. I also change the date format (in the 'From ' line) to be cosistent with other local messages.

ah, ok. makes sense. I didn't know we sent the message envelope to the server on a move or copy. here comes back cavin's orignal patch, with more "???@???" places fixed.

fixed. excellent work cavin.

Build 2001-05-04-04: WinME Verified Fixed, it no longer crashes!