Closed
Bug 112139
Opened 23 years ago
Closed 23 years ago
selecting rewrap for plain text reply causes mozilla to hang
Categories
(Core :: DOM: Editor, defect)
Tracking
()
VERIFIED
FIXED
mozilla0.9.8
People
(Reporter: luke.taylor, Assigned: akkzilla)
References
Details
(Keywords: dataloss, hang, Whiteboard: fix in hand, needs review)
Attachments
(8 files)
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120 BuildID: 2001112009 When I am replying to a plain text message which is included inline, and I select rewrap to tidy it up, the program hangs completely. i.e. with rewrap still selected on the menu... Reproducible: Always Steps to Reproduce: 1. reply to a message 2. select options->rewrap That's it. Actual Results: The program is completely gone and I have to kill it. Expected Results: Fomatted the text properly? The mail I most recently tried starts off like this: BSamra@xxxxxx.com wrote: > Hej Luke, > > My rent is £650 per month, so I am going to charge the new housemate £295 > and pay the rest. > There is also council tax which is very high. I am band G, so thats over a > grand a year. i think The original message was plain text and I have mail setup to alwaps use plain text replies.
|
||
Comment 1•23 years ago
|
||
I had this happen this morning an my Mac OSX build as well. Happened in a build from early last week (probably also an 11/20 build... I've updated since then.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
||
Comment 2•23 years ago
|
||
Reporter: Please try a fresh profile. You can manage/create profiles with "mozilla.exe -profilemanager". You may also wish to try a more recent build: http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip (as always, be sure to delete your old Mozilla directory before installing the new one)
URL: n/a
|
Reporter | |
Comment 3•23 years ago
|
||
I tried it with another profile: 1. Created new profile. 2. Mailed myself a copy of the same message. 3. Downloaded it with the new profile. 4. Tried reply and rewrap. Exactly the same proble. Did notice that it doesn't happen if you have html composition enabled. But rewrap doesn't seem to do anything at all then. I was previously using a 0.9.8 build and had similar problems.
|
||
Comment 4•23 years ago
|
||
repoter, can you attach the message to this bug if it is not confidential so we can reproduce the problem. I tried this on 2001-11-27-06 build on win98 and the application did not hang.
QA Contact: sheelar → esther
|
||
Comment 5•23 years ago
|
||
dup of Bug 106293 ?
|
|
Reporter | |
Comment 6•23 years ago
|
||
I'm seeing this on Win98, 2001120208 on *every* reply composition window (modern theme). I don't think it depends on a specific message formatting. Considering the inefficiencies of wrpping in reply window, inability of using rewrap is annoying.
|
||
Comment 8•23 years ago
|
||
Seeing it in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120 Please mark OS->All. Mozilla consumes 99.4% CPU until I kill it.
|
||
Comment 10•23 years ago
|
||
I have the same problem but only when: ->> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) ->> With the other messages, works.
|
||
Comment 11•23 years ago
|
||
*** Bug 106293 has been marked as a duplicate of this bug. ***
|
||
Comment 12•23 years ago
|
||
trying this on linux 20011210 caused the wrap menu to hang open, cursor locked up and i had to exit to console to kill moz.
|
||
Comment 13•23 years ago
|
||
*** Bug 115044 has been marked as a duplicate of this bug. ***
|
|
||
Comment 14•23 years ago
|
||
*** Bug 113259 has been marked as a duplicate of this bug. ***
|
||
Comment 15•23 years ago
|
||
This is happening to me now. I'm on version 0.9.6 Sparc Sunos. It may not be new with this release though, I've only been using rewrap since I hacked my UseContent.css and now the message composition is using a variable width font. With a fixed width font it used to wrap OK by itself.
|
||
Comment 16•23 years ago
|
||
Reproduced on build 2001112014 on the OpenVMS Platform. Hang not only takes out Mozilla, but locks up all windows until the process running Mozilla is terminated. While this lockup can be triggered by this problem. It can induced from other issues. There appears to be some resource leak in Mozilla, so that reproducing this may require replying to several messages. As it seems to be triggered by Mozilla running out of some resource, it may be difficult to come up with a reliable reproducer. The suggestion is to look for code that is not handling failures of resource allocations, that is called by the rewrap option. That may solve this lockup, but there is a serious resource leak in Mozilla that is the underlying problem.
|
|
||
Comment 17•23 years ago
|
||
Another reproducer of the problem.
|
|
||
Comment 18•23 years ago
|
||
[BUGZILLA would not allow this as an attachment from MOZILLA, claimed the file
was empty!, Sigh, another bug to look up!]
OpenVMS Build 2001112014.
The exact lines of code can be decoded from the OpenVMS linker Map and compiler
listings.
Otherwise, it will give an idea of what routine is looping, and who called it.
OpenVMS (TM) Alpha system analyzer
SDA> SHOW SUM
[edit]
000000E7 0067 VUE$MALMBERG_2 MALMBERG COM 0 810B5F00 8209E000 13137
SDA> SHOW PROC/IND=67
Process index: 0067 Name: VUE$MALMBERG_2 Extended PID: 000000E7
-------------------------------------------------------------------
Process status: 02040001 RES,PHDRES,INTER
status2: 00000001 QUANTUM_RESCHED
PCB address 810B5F00 JIB address 80EB5500
PHD address 8209E000 Swapfile disk address 00000000
KTB vector address 810B61EC HWPCB address 8209E080
Callback vector address 8101B680 Termination mailbox 002A
Master internal PID 00010067 Subprocess count 0
Creator extended PID 00000000 Creator internal PID 00000000
Previous CPU Id 00000000 Current CPU Id 00000000
Previous ASNSEQ 0000000000000001 Previous ASN 0000000000000099
Initial process priority 4 Delete pending count 0
# open files allowed left 141 Direct I/O count/limit 150/150
UIC [00400,000100] Buffered I/O count/limit 149/150
Abs time of last event 084163AF BUFIO byte count/limit 82464/82464
ASTs remaining 248 # of threads 1
Swapped copy of LEFC0 00000000 Timer entries allowed left 9
Swapped copy of LEFC1 00000000 Active page table count 0
Global cluster 2 pointer 00000000 Process WS page count 10116
Global cluster 3 pointer 00000000 Global WS page count 3021
Press RETURN for more.
SDA> SHOW CALL
Call Frame at 00000000.7AEC0080
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.00351C30 LIBXPCOM+00167C30
Return address on stack = 00000000.00354FD0 LIBXPCOM+0016AFD0
Registers saved on stack
------------------------
7AEC00A8 00000000.0022E988 Saved R2 LIBXPCOM+44988
7AEC00B0 00000000.00001E3C Saved R3 CTL$C_CLIDATASZ+0089C
7AEC00B8 00000000.7AEC00C0 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC2B40
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.02E28890 LIBGKLAYOUT+002E0890
Handler at 00000000.000E4A38, Data = 00000000.02BC7B90
Return address on stack = 00000000.02D0D010 LIBGKLAYOUT+001C5010
Registers saved on stack
------------------------
7AEC2C58 00000000.02B6D850 Saved R2 LIBGKLAYOUT+25850
7AEC2C60 00000000.08520638 Saved R3
7AEC2C68 00000000.7AEC31B8 Saved R4
7AEC2C70 00000000.066E4110 Saved R5
7AEC2C78 00000000.7AEC2C80 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC2C80
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.02D0CD80 LIBGKLAYOUT+001C4D80
Return address on stack = 00000000.02D0CC60 LIBGKLAYOUT+001C4C60
Registers saved on stack
------------------------
7AEC2CA0 00000000.02B6FED0 Saved R2 LIBGKLAYOUT+27ED0
7AEC2CA8 00000000.08520638 Saved R3
7AEC2CB0 00000000.066E4110 Saved R4
7AEC2CB8 00000000.7AEC31B8 Saved R5
7AEC2CC0 00000000.7AEC3078 Saved R6
7AEC2CC8 00000000.00000000 Saved R7
7AEC2CD0 00000000.7AEC2CE0 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC2CE0
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.02D0C950 LIBGKLAYOUT+001C4950
Return address on stack = 00000000.02F5EE20 LIBGKVIEW+30E20
Registers saved on stack
------------------------
7AEC2D08 00000000.02F2E698 Saved R2 LIBGKVIEW+00698
7AEC2D10 00000000.066E4110 Saved R3
7AEC2D18 00000000.7AEC31B8 Saved R4
7AEC2D20 00000000.7AEC30F8 Saved R5
7AEC2D28 00000000.7AEC3078 Saved R6
7AEC2D30 00000000.00000000 Saved R7
7AEC2D38 00000000.000002A0 Saved R8 BUG$_NORCVBUF
7AEC2D40 00000000.000001DC Saved R9
7AEC2D48 00000000.7AEC2D50 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC2D50
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.02F5EBD0 LIBGKVIEW+30BD0
Handler at 00000000.000E4A38, Data = 00000000.02F2E688
Return address on stack = 00000000.02F5ED84 LIBGKVIEW+30D84
Registers saved on stack
------------------------
7AEC2DA0 00000000.02F2E698 Saved R2 LIBGKVIEW+00698
7AEC2DA8 00000000.05B379F8 Saved R3
7AEC2DB0 00000000.7AEC31B8 Saved R4
7AEC2DB8 00000000.7AEC30F8 Saved R5
7AEC2DC0 00000000.7AEC3078 Saved R6
7AEC2DC8 00000000.00000001 Saved R7
7AEC2DD0 00000000.000002A0 Saved R8 BUG$_NORCVBUF
7AEC2DD8 00000000.000001DC Saved R9
7AEC2DE0 00000000.00000000 Saved R10
7AEC2DE8 00000000.066E4110 Saved R11
7AEC2DF0 00000000.7AEC2E00 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC2E00
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.02F5EBD0 LIBGKVIEW+30BD0
Handler at 00000000.000E4A38, Data = 00000000.02F2E688
Return address on stack = 00000000.02F5ED84 LIBGKVIEW+30D84
Registers saved on stack
------------------------
7AEC2E50 00000000.02F2E698 Saved R2 LIBGKVIEW+00698
7AEC2E58 00000000.065CAF90 Saved R3
7AEC2E60 00000000.7AEC31B8 Saved R4
7AEC2E68 00000000.7AEC30F8 Saved R5
7AEC2E70 00000000.7AEC3078 Saved R6
7AEC2E78 00000000.00000001 Saved R7
7AEC2E80 00000000.000002CA Saved R8 BUG$_NOTIRPAQB+00002
7AEC2E88 00000000.00000206 Saved R9 IRP$Q_SHD_RESERV_Q9+00002
7AEC2E90 00000000.00000000 Saved R10
7AEC2E98 00000000.05B379F8 Saved R11
7AEC2EA0 00000000.7AEC2EB0 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC2EB0
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.02F5EBD0 LIBGKVIEW+30BD0
Handler at 00000000.000E4A38, Data = 00000000.02F2E688
Return address on stack = 00000000.02F5ED84 LIBGKVIEW+30D84
Registers saved on stack
------------------------
7AEC2F00 00000000.02F2E698 Saved R2 LIBGKVIEW+00698
7AEC2F08 00000000.0799E998 Saved R3
7AEC2F10 00000000.7AEC31B8 Saved R4
7AEC2F18 00000000.7AEC30F8 Saved R5
7AEC2F20 00000000.7AEC3078 Saved R6
7AEC2F28 00000000.00000010 Saved R7
7AEC2F30 00000000.00000AFE Saved R8 BUG$_LASTBUG+0004E
7AEC2F38 00000000.00000372 Saved R9 BUG$_PTELENVIOL+00002
7AEC2F40 00000000.00000000 Saved R10
7AEC2F48 00000000.065CAF90 Saved R11
7AEC2F50 00000000.7AEC2F60 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC2F60
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.02F5EBD0 LIBGKVIEW+30BD0
Handler at 00000000.000E4A38, Data = 00000000.02F2E688
Return address on stack = 00000000.02F6FDA8 LIBGKVIEW+41DA8
Registers saved on stack
------------------------
7AEC2FB0 00000000.02F324A0 Saved R2 LIBGKVIEW+044A0
7AEC2FB8 00000000.02F33BB8 Saved R3 LIBGKVIEW+05BB8
7AEC2FC0 00000000.7AEC31B8 Saved R4
7AEC2FC8 00000000.7AEC30F8 Saved R5
7AEC2FD0 00000000.00000030 Saved R6
7AEC2FD8 00000000.0799E998 Saved R7
7AEC2FE0 00000000.00000196 Saved R8
7AEC2FE8 00000000.0000085E Saved R9 BUG$_CSLBUG+00006
7AEC2FF0 00000000.00000000 Saved R10
7AEC2FF8 00000000.00000000 Saved R11
7AEC3000 00000000.7AEC3010 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3010
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.02F6F5B0 LIBGKVIEW+415B0
Handler at 00000000.000E4A38, Data = 00000000.02F32490
Return address on stack = 00000000.02F5E2D4 LIBGKVIEW+302D4
Registers saved on stack
------------------------
7AEC3098 00000000.08368618 Saved R2
7AEC30A0 00000000.7AEC31B8 Saved R3
7AEC30A8 00000000.7AEC3158 Saved R4
7AEC30B0 00000000.00F9D8D8 Saved R5 LIBWIDGET_GTK+178D8
7AEC30B8 00000000.00000000 Saved R6
7AEC30C0 00000000.00A51058 Saved R7
7AEC30C8 00000000.0049CD70 Saved R8 LIBGDK+02D70
7AEC30D0 00000000.003F6550 Saved R9 LIBGLIB+10550
7AEC30D8 00000000.00000000 Saved R10
7AEC30E0 00000000.7AEC30F0 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC30F0
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.02F5E280 LIBGKVIEW+30280
Return address on stack = 00000000.00FDFEB4 LIBWIDGET_GTK+59EB4
Registers saved on stack
------------------------
7AEC3110 00000000.7AEC3120 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3120
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.00FDFDE0 LIBWIDGET_GTK+59DE0
Return address on stack = 00000000.00FDFD28 LIBWIDGET_GTK+59D28
Registers saved on stack
------------------------
7AEC3130 00000000.00F8F8D8 Saved R2 LIBWIDGET_GTK+098D8
7AEC3138 00000000.08368618 Saved R3
7AEC3140 00000000.7AEC31B8 Saved R4
7AEC3148 00000000.7AEC3150 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3150
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.00FDFCF0 LIBWIDGET_GTK+59CF0
Return address on stack = 00000000.00FDFFAC LIBWIDGET_GTK+59FAC
Registers saved on stack
------------------------
7AEC3168 00000000.7AEC3170 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3170
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.00FDFF50 LIBWIDGET_GTK+59F50
Return address on stack = 00000000.00FE0EC0 LIBWIDGET_GTK+5AEC0
Registers saved on stack
------------------------
7AEC3180 00000000.00F8F900 Saved R2 LIBWIDGET_GTK+09900
7AEC3188 00000000.08368618 Saved R3
7AEC3190 00000000.02A04900 Saved R4
7AEC3198 00000000.7AEC31A0 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC31A0
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.00FE0D80 LIBWIDGET_GTK+5AD80
Return address on stack = 00000000.00FE7B80 LIBWIDGET_GTK+61B80
Registers saved on stack
------------------------
7AEC3208 00000000.00F93A40 Saved R2 LIBWIDGET_GTK+0DA40
7AEC3210 00000000.08368618 Saved R3
7AEC3218 00000000.7AEC3220 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3220
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.00FE7970 LIBWIDGET_GTK+61970
Return address on stack = 00000000.00FD4698 LIBWIDGET_GTK+4E698
Registers saved on stack
------------------------
7AEC32E8 00000000.00F8B530 Saved R2 LIBWIDGET_GTK+05530
7AEC32F0 00000000.02A04900 Saved R3
7AEC32F8 00000000.08368618 Saved R4
7AEC3300 00000000.08368618 Saved R5
7AEC3308 00000000.00000000 Saved R6
7AEC3310 00000000.7AEC3320 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3320
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.00FD4590 LIBWIDGET_GTK+4E590
Return address on stack = 00000000.00FD429C LIBWIDGET_GTK+4E29C
Registers saved on stack
------------------------
7AEC3330 00000000.00F8B700 Saved R2 LIBWIDGET_GTK+05700
7AEC3338 00000000.02A04900 Saved R3
7AEC3340 00000000.00000000 Saved R4
7AEC3348 00000000.7AEC3350 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3350
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.00FD3FF0 LIBWIDGET_GTK+4DFF0
Handler at 00000000.000E4A38, Data = 00000000.00F8B670
Return address on stack = 00000000.004DBB70 LIBGDK+41B70
Registers saved on stack
------------------------
7AEC33F0 00000000.0049CD70 Saved R2 LIBGDK+02D70
7AEC33F8 00000000.004AA2F0 Saved R3 LIBGDK+102F0
7AEC3400 00000000.02A04900 Saved R4
7AEC3408 00000000.003F62D8 Saved R5 LIBGLIB+102D8
7AEC3410 00000000.003F6560 Saved R6 LIBGLIB+10560
7AEC3418 00000000.00A51058 Saved R7
7AEC3420 00000000.7AEC3430 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3430
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.004DBAE0 LIBGDK+41AE0
Return address on stack = 00000000.00423FD0 LIBGLIB+3DFD0
Registers saved on stack
------------------------
7AEC3440 00000000.003E8B50 Saved R2 LIBGLIB+02B50
7AEC3448 00000000.7AEC34E0 Saved R3
7AEC3450 00000000.003F6290 Saved R4 LIBGLIB+10290
7AEC3458 00000000.7AEC3460 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3460
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.00423EA0 LIBGLIB+3DEA0
Return address on stack = 00000000.0042477C LIBGLIB+3E77C
Registers saved on stack
------------------------
7AEC3470 00000000.003E8BF0 Saved R2 LIBGLIB+02BF0
7AEC3478 00000000.00000000 Saved R3
7AEC3480 00000000.00000000 Saved R4
7AEC3488 00000000.00000001 Saved R5
7AEC3490 00000000.003F6560 Saved R6 LIBGLIB+10560
7AEC3498 00000000.003F62AC Saved R7 LIBGLIB+102AC
7AEC34A0 00000000.00000001 Saved R8
7AEC34A8 00000000.003F62B8 Saved R9 LIBGLIB+102B8
7AEC34B0 00000000.00000001 Saved R10
7AEC34B8 FFFFFFFF.FFFFFFFF Saved R11
7AEC34C0 00000000.00A51080 Saved R12
7AEC34C8 00000000.7AEC34D0 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC34D0
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.004240C0 LIBGLIB+3E0C0
Return address on stack = 00000000.00424998 LIBGLIB+3E998
Registers saved on stack
------------------------
7AEC3508 00000000.003E8C60 Saved R2 LIBGLIB+02C60
7AEC3510 00000000.016DFB28 Saved R3
7AEC3518 00000000.016DFB28 Saved R4
7AEC3520 00000000.004AA2F0 Saved R5 LIBGDK+102F0
7AEC3528 00000000.00ABFE40 Saved R6
7AEC3530 00000000.00EF8078 Saved R7 LIBNSAPPSHELL+16078
7AEC3538 00000000.00000002 Saved R8
7AEC3540 00000000.00000004 Saved R9
7AEC3548 00000000.00000007 Saved R10
7AEC3550 00000000.00000009 Saved R11
7AEC3558 00000000.00000000 Saved R12
7AEC3560 FFFFFFFF.80D18DF0 Saved R13 EXE_STD$RESETVEC+006A0
7AEC3568 00000000.7AEC3570 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3570
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.00424900 LIBGLIB+3E900
Return address on stack = 00000000.006A1A58 LIBGTK+00123A58
Registers saved on stack
------------------------
7AEC3580 00000000.005968E0 Saved R2 LIBGTK+188E0
7AEC3588 00000000.005BE960 Saved R3 LIBGTK+40960
7AEC3590 00000000.7AEC35A0 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC35A0
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.006A1920 LIBGTK+00123920
Return address on stack = 00000000.00FC7574 LIBWIDGET_GTK+41574
Registers saved on stack
------------------------
7AEC35D0 00000000.00F867E0 Saved R2 LIBWIDGET_GTK+007E0
7AEC35D8 00000000.00B7A5E0 Saved R3
7AEC35E0 00000000.02A893B8 Saved R4 LIBXREMOTESERVICE+033B8
7AEC35E8 00000000.0000000F Saved R5
7AEC35F0 00000000.00EF8078 Saved R6 LIBNSAPPSHELL+16078
7AEC35F8 00000000.00EF8078 Saved R7 LIBNSAPPSHELL+16078
7AEC3600 00000000.00000002 Saved R8
7AEC3608 00000000.7AEC3610 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3610
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.00FC7510 LIBWIDGET_GTK+41510
Return address on stack = 00000000.00038FF8 MOZILLA-BIN+38FF8
Registers saved on stack
------------------------
7AEC3620 00000000.00013068 Saved R2 MOZILLA-BIN+13068
7AEC3628 00000000.0000000E Saved R3
7AEC3630 00000000.7AEC3640 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3640
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.00038180 MOZILLA-BIN+38180
Handler at 00000000.000E4A38, Data = 00000000.00012F88
Return address on stack = 00000000.00039CE8 MOZILLA-BIN+39CE8
Registers saved on stack
------------------------
7AEC3738 00000000.000136D8 Saved R2 MOZILLA-BIN+136D8
7AEC3740 00000000.00000001 Saved R3
7AEC3748 00000000.0077BC60 Saved R4
7AEC3750 00000000.00000001 Saved R5
7AEC3758 00000000.7FFAC4E5 Saved R6
7AEC3760 00000000.00000000 Saved R7
7AEC3768 FFFFFFFF.80000000 Saved R8 G
7AEC3770 00000000.7FFAC410 Saved R9
7AEC3778 00000000.7FFAD238 Saved R10
7AEC3780 00000000.7FFCE3E0 Saved R11 CTL$AG_CLIDATA+00180
7AEC3788 00000000.7AEC3790 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3790
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.000399B0 MOZILLA-BIN+399B0
Handler at 00000000.000E4AA0
Return address on stack = 00000000.00030070 SYS$K_VERSION_01+00070
Registers saved on stack
------------------------
7AEC37C0 00000000.00013740 Saved R2 MOZILLA-BIN+13740
7AEC37C8 00000000.7BCC2908 Saved R3 PTHREAD$RTL+12908
7AEC37D0 00000000.7BCC28B4 Saved R4 PTHREAD$RTL+128B4
7AEC37D8 00000000.7FFCF938 Saved R5 MMG$IMGHDRBUF+00138
7AEC37E0 00000000.7FFAC4E5 Saved R6
7AEC37E8 00000000.7FFAC9F0 Saved R7
7AEC37F0 00000000.7FFAC208 Saved R8
7AEC37F8 00000000.7AEC3820 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3820
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.00030000 SYS$K_VERSION_01
Handler at 00000000.7BF60520, Data = 00000000.00000008
Return address on stack = 00000000.7BCEB540 PTHREAD$RTL+4F540
Registers saved on stack
------------------------
7AEC3858 00000000.7BCB9A80 Saved R2 PTHREAD$RTL+05A80
7AEC3860 00000000.7AEC3870 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3870
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.7BCEB2B0 PTHREAD$RTL+4F2B0
Handler at 00000000.7BCBD2E0, Data = 00000000.00000008
Return address on stack = 00000000.7BCCC3E4 PTHREAD$RTL+303E4
Registers saved on stack
------------------------
7AEC3A40 00000000.7BCB4308 Saved R2 PTHREAD$RTL+00308
7AEC3A48 00000000.7BCC2908 Saved R3 PTHREAD$RTL+12908
7AEC3A50 00000000.7BCC0020 Saved R4 PTHREAD$RTL+10020
7AEC3A58 00000000.7AEC3A60 Saved R29
Result: 64-bit integer returned in register R0
Argument List:
00000000.00000000 in register R16 (signed 32-bit)
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC3A60
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.7BCCC250 PTHREAD$RTL+30250
Return address on stack = FFFFFFFF.802553D4 IMAGE_MANAGEMENT+0F3D4
Registers saved on stack
------------------------
7AEC7AD0 00000000.7FFCF880 Saved R2 MMG$IMGHDRBUF+00080
7AEC7AD8 00000000.7B05FBB6 Saved R3
7AEC7AE0 00000000.7FFCF818 Saved R4 MMG$IMGHDRBUF+00018
7AEC7AE8 00000000.7AEC7B30 Saved R29
Result: 32-bit zero extended integer returned in register R0
Argument List:
00000000.00000000 in register R16 (signed 32-bit)
00000000.00000000 in register R17 (signed 32-bit)
00000000.00000000 in register R18 (signed 32-bit)
00000000.00000000 in register R19 (signed 32-bit)
00000000.00000000 in register R20 (signed 32-bit)
00000000.00000000 in register R21 (signed 32-bit)
001C0000.00000040 in memory (64-bit integer)
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC7B30
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: FFFFFFFF.80255280 IMAGE_MANAGEMENT+0F280
Handler at FFFFFFFF.80D18DE0
Return address on stack = 00000000.7B0354C4
Registers saved on stack
------------------------
7AEC7B80 00000000.00000000 Saved R2
7AEC7B88 00000000.7FFAC9F0 Saved R7
7AEC7B90 00000000.7B00C220 Saved R13
7AEC7B98 00000000.7AEC7BB0 Saved R29
SDA> SHOW CALL/NEXT
Call Frame at 00000000.7AEC7BB0
-------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: 00000000.7B035314
Handler at 00000000.7B00C210
Return address on stack = 00000000.7B035300
Registers saved on stack
------------------------
7AEC7BD0 00000000.00000020 Saved R4
7AEC7BD8 00000000.7FFCF800 Saved R5 MMG$IMGHDRBUF
7AEC7BE0 00000000.7B00C200 Saved R13
7AEC7BE8 00000000.00000000 Saved R29
SDA> SHOW CALL/NEXT
%SDA-E-NOTINPHYS, 00000000.00000000 : virtual data not in physical memory
SDA>
EAGLE>
|
||
Comment 19•23 years ago
|
||
You need to use a plain text compose window in order to reproduce this problem. We get stuck in nsInternetCiter::Rewrap in the loop while ((PRInt32)posInString < nextNewline) at line 339. posInString never incress! Reassign to editor core and nominating nsbeta1. This is a dataloss in case the user has already composed his/her message before deciding to rewrap.
|
Assignee | |
Updated•23 years ago
|
Status: NEW → ASSIGNED
|
||
Comment 21•23 years ago
|
||
*** Bug 116902 has been marked as a duplicate of this bug. ***
|
||
Comment 22•23 years ago
|
||
*** Bug 117209 has been marked as a duplicate of this bug. ***
|
||
Comment 23•23 years ago
|
||
I've noticed that this hanging is more likely to occur if some parts of the message (typically -- signatures) are removed automatically when the message is opened for editing.
|
|
Assignee | |
Comment 24•23 years ago
|
||
I have a guess about where the fix needs to go, but I need a way to reproduce this to test it. I tried saving the first attachment, appending the resulting contents to one of my local folders, running mail on the local folder, select the message, reply to it in plaintext compose, and immediately do Rewrap. It rewrapped correctly, no hang. I don't have a signature, if that matters. Can someone give me reproducible instructions, including how to create a folder and what options I need to set, which will make this hang happen?
|
|
||
Comment 25•23 years ago
|
||
Another message as testcase. The reason you cannot reproduce, imo, lies in your Mail preferences. Mine are: - Wrap text to fit window width (Message Display) - Automatically quote the original message when replying (Message Composition) - Start my reply above the quoted text (Message Composition) - Wrap plain text messages at 72 chars (Message Composition) - No signature - Plain text compose - POP account Still puzzled on how to append an eml file to a local folder but, anyway, I don't think that the specific process matters. It's rather a matter of preferences.
|
|
||
Comment 26•23 years ago
|
||
*** Bug 118148 has been marked as a duplicate of this bug. ***
|
|
Assignee | |
Comment 27•23 years ago
|
||
Those prefs are basically what I have, with the exception that I put my reply after the quoted message. I'll try with that setting, if I ever manage to get a build (my machine crashed in the middle of my morning build today and now my filesystem is horked and I'm trying to repair it.) It would be a big help if someone who can actually reproduce this problem could turn on DEBUG_wrapping in nsInternetCiter and give me some of the output from it. I need to know what's special about these messages that cause posInString not to increment, rather than just guessing by inspection of the code.
|
||
Comment 28•23 years ago
|
||
Dump this file in your Local Folders to test it out. The first mail hangs Mozilla on rewrap. The second two do not. The second one does weird things that are probably not related to this bug, but Mozilla does not crash. What seems to set it off is the string of 72 characters. This is consistent with people crashing with signatures, which often have long strings in them. Preferences are same as mentioned above except that I start my reply below the quoted text.
|
|
Assignee | |
Comment 29•23 years ago
|
||
Got the folder ... but with today's build, I'm getting a dialog which says: An error occurred while creating a message compose window. Please try again. T No indication of what the error was (unless "T" is meaningful to someone). I'm also getting an unbelievable number of asserts doing anything in the mail window. I'll try again tomorrow. J-F? Should I file a bug?
|
|
||
Comment 30•23 years ago
|
||
This .msf goes with the folder I attached previously. I transferred the folder as the file from my office (0.9.7) to my home computer (020103 and 020104 builds) without any problem. I also re-downloaded my own attachment, and that worked too. I'm not sure if the .msf file will help or not. I created the "folder" by text-editting a mail folder with one message, and whittling the message down until rewrapping didn't crash. I then copied the message back and forth between folders to create duplicate messages.
|
|
||
Comment 31•23 years ago
|
||
Akkana, you should try again with today's build. We got couple problem with the comose window recently due to MAPI landing.
|
|
Assignee | |
Comment 32•23 years ago
|
||
Mail is even worse for me today -- not only do I get huge numbers of assertions mousing over the folder pane, but it doesn't see the folder with the test cases in it (which it did see last week). But I discovered that if you save one of the testcases (with "> " added) to a text file, you can run mozilla -edit file.txt and see the hang with Debug->Rewrap. Turns out it's the "line would be too long, breaking early" clause that's failing to increment posInString.
|
|
Assignee | |
Comment 33•23 years ago
|
||
Here's a patch, which does the following: - If a line is close to being able to wrap, as in the examples where the line was exactly 72 columns, then it lets it slop over (and the resulting line in the output will be slightly long). The plaintext serializer already does something like this, so now rewrap will as well. I set the slop to 6 characters, which I picked out of thin air and would be open to changing if anyone thinks it should be larger or smaller. - If the line is longer than wraplength+SLOP, we hard-break the line at wraplength-1, add a hyphen, then continue onto the next line. I'll attach a test case I used for testing, which has a line just barely long enough, a line over the slop threshold, and a line long enough that it has to wrap several times (and it alternates characters so you can see it isn't leaving anything out). Looking for review now (and cc kin since I'll probably ask him for sr after it's reviewed).
Whiteboard: fix in hand, needs review
|
|
Assignee | |
Comment 34•23 years ago
|
||
|
|
Assignee | |
Comment 35•23 years ago
|
||
Here's my test case. Save it in something like wrapmail.txt, then run mozilla -edit wrapmail.txt and in a debug build you'll be able to do Debug->Rewrap.
|
||
Comment 36•23 years ago
|
||
Comment on attachment 63914 [details] [diff] [review] A fix Have you tested this with double-byte or high-ascii text? r=brade (assuming there are no problems)
Attachment #63914 -
Flags: review+
|
|
Assignee | |
Comment 37•23 years ago
|
||
I'm not sure how to generate double-byte text to test it. Mail folks, any ideas?
|
||
Comment 38•23 years ago
|
||
#ifdef DEBUG_wrapping
+ if (++loopcount > 500)
+ {
+ printf("infinite loop detected, breaking\n");
+ return NS_ERROR_UNEXPECTED;
+ }
+
Surely this should be an NS_ASSERTION. It's pretty serious, and only breaks out
of the loop in debug builds. Why do that?
Otherwise it looks good, sr=sfraser
|
|
Assignee | |
Comment 39•23 years ago
|
||
Done. I wasn't confident about the 500 number, and it seems like a bad idea to do the loop counter thing in production code, so I've changed the printf to an assertion, changed the 500 to 1000 (still only if DEBUG_wrapping), and removed the return.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
|
|
||
Comment 40•23 years ago
|
||
*** Bug 120175 has been marked as a duplicate of this bug. ***
|
|
||
Comment 41•23 years ago
|
||
*** Bug 120454 has been marked as a duplicate of this bug. ***
|
|
||
Comment 42•23 years ago
|
||
*** Bug 120892 has been marked as a duplicate of this bug. ***
|
|
||
Comment 43•23 years ago
|
||
*** Bug 120919 has been marked as a duplicate of this bug. ***
|
||
Comment 44•23 years ago
|
||
*** Bug 121046 has been marked as a duplicate of this bug. ***
|
|
||
Comment 45•23 years ago
|
||
I just had a deadlock with a current CVS when doing a wrap for the third time in a message where the quotes looked messy.
|
|
||
Comment 46•23 years ago
|
||
I'm seeing this too. I will attach a snippet from an email that seems to give problems. note that on the first pass, the font is changed. I don't know that this is the desired behavior, but probably a different bug. on the second pass, lines are wrapped slightly differently. third time is the charm...
|
|
||
Comment 47•23 years ago
|
||
new testcase. my old testcase works ok. Akkana's testcase does weird things, but does not crash.
|
||
Comment 48•23 years ago
|
||
I have a testcase in DUPE bug #121046 - it causes Mozilla to hang everytime. In that bug I mistakedly forgot to include the bild number: 2002011803 under Win98SE. I'll get a new build tonight and test it again. I usually always update my builds tuesday + saturdays. If I still see it in tonights build, I am going to take the liberty of reopening this bug, unless someelse does before me.
|
|
||
Comment 49•23 years ago
|
||
NOT fixed. Tested with builds 2002011803 and 2002012203; OS: Win98SE. Both fail on running Options/Rewrap in plain text compose window when you have the text from attachment #65862 [details] of duplicate bug #121046.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
|
|
Assignee | |
Comment 50•23 years ago
|
||
I see that, too. It's a different problem this time: I get into an infinite loop asserting on this: ###!!! ASSERTION: Infinite loop: can't advance a writing iterator beyond the end of a string: 'one_hop>0', file ../../../dist/include/string/nsStringIterator.h, line 330 I'm going to un-dup the other bug since it's not the same problem.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
|
||
Comment 51•23 years ago
|
||
I am still seeing the same problem listed in comment 49 on the 01-24 trunk build on Win 2k. I am reopening this bug.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
|
|
||
Comment 52•23 years ago
|
||
should it be marked as a dup of bug 121046?
|
|
Assignee | |
Comment 53•23 years ago
|
||
Bug 121046 was already reopened for that problem, which was a different problem from the one that was fixed here. Go join that bug rather than reopening this one unless you see the original problem using the original test cases.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•