439012 - "ASSERTION: Illegal value (length > position): 'aLen > aPos'" when replying to a message with Chinese characters

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Compose Window, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: both normal and full backtraces

###!!! ASSERTION: Illegal value (length > position): 'aLen > aPos', file /Users/skywalker/Desktop/Mozilla/cvs/mozilla/intl/lwbrk/src/nsJISx4501LineBreaker.cpp, line 775

Seen when I tried to reply to a message containing Chinese characters. Latest debug 3.0a2pre Mac TB build.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

No longer seems to occur on latest debug Mac TB build. WFM.

Comment 2

[ISHIKAWA, Chiaki]

Hi, it looks that the problem has been dormant for a while.
I spotted a very similar (the same?) bug during running debug version of thunderbird through mozmill test suite. 
Bug 827061 - ASSERTION: Bad position passed to nsJISx4051LineBreaker::Next: 'aLen > aPos', file ./mozilla/intl/lwbrk/src/nsJISx4501LineBreaker.cpp

The messages were printed more than two dozen times, and I found that
(aLen, aPos) = (0, 0)
Your stack trace also shows aLen, aPos = 0 as in my observation.

So the problem may be not restricted to Chinese e-mail message.
I am using Japanese locale (but come to think of it, I set LC_ALL=C, LANG=C 
at the beginning of mozmill run. (Not sure I have exported them though.)

BTW, did you get the message while you are using the debug build TB in a non-testing set up? That is, were using it as a general user, and noticed the problem, and then re-ran TB under gdb after setting breakpoint in "Break" or whichever routine is executed at the time ASSERTION is printed? 

I am asking this because it is rather difficult to insert gdb backtrace during
automated "make mozmill" run if I am not mistaken.
I wonder if there is a way to print the backtrace (a la gdb) automatically from mozmill run for better backtrace that helps people to focus on the bug and come up with a fix in a speedy manner.

TIA

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Setting XPCOM_DEBUG_BREAK=stack is probably what you want - see:

https://developer.mozilla.org/en-US/docs/XPCOM_DEBUG_BREAK

If XPCOM_DEBUG_BREAK is set as "stack" in your enviroment, when assertions are hit, stacks are dumped into the console as well. In my case in comment 0, I think I was running debug TB in gdb so I was also able to get a backtrace and/or inspect variables.

In any case, please feel free to file a new bug, this bug is now WFM.