322838 - Entering a really long piece of text in To: field crashes Thunderbird and Intel Graphics Driver

Status: RESOLVED INVALID

(Core :: XPCOM, defect)

Description

[Anton Daneika]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: version 1.0.7 (20050923)

i accidentally pasted a plain text file in To: field instead of the message body, which resulted in thunderbird crash and (for the first time)the switch of my video mode to 640x480x256. as i repeted my actions after reboot i got the blue screen of death. i rebooted one more time and let microsoft's automatic bug reporting system to work which brought me to this webpage: http://oca.microsoft.com/en/response.aspx?SGD=26b8d270-07f2-4bd8-8900-12d2ecb35c25&SID=531
which said "Error caused by Intel Graphics Driver: no specific solution found."

Reproducible: Always

Steps to Reproduce:
1. open new message for editing
2. copy a large text file (mine had 536 strings) into To: field instead of real mail adress

Actual Results:  
either video mode change or BSOD

Expected Results:  
either pasted string or message box with caution of too long string entered

the text file i used to crash TB is in attachment grep.tmp

Comment 1

[Anton Daneika]

Attachment: a text file that crashed TB

this is the file i accidentally pasted into To: field instead of the message body

Comment 2

[timeless]

well erm, if you don't attach a minidump(.dmp) to this bug, i will kill it. bsod's are not really our fault. as the report from microsoft clearly indicated. if you want to complain to someone, complain to intel. that said, post the .dmp and i'll help.

Comment 3

[Anton Daneika]

Attachment: as i understand that is what you want...

Comment 4

[Anton Daneika]

(In reply to comment #2)
> well erm, if you don't attach a minidump(.dmp) to this bug, i will kill it.
> bsod's are not really our fault. as the report from microsoft clearly
> indicated. if you want to complain to someone, complain to intel. that said,
> post the .dmp and i'll help.
> 

i do not want to complain. was thinking that i contribute to the comunity by submitting an error.

Comment 5

[timeless]

kd> !analyze -v -f
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possible to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: 85c98da8, Pointer to a stuck thread object.  Do .thread then kb on it to find
	the hung location.
Arg2: 862a98d8, Pointer to a DEFERRED_WATCHDOG object.
Arg3: f7ba9cb4, Pointer to offending driver name.
Arg4: 00000001, Number of times "intercepted" bugcheck 0xEA was hit (see notes).

Debugging Details:
------------------


FAULTING_THREAD:  85c98da8

DEFAULT_BUCKET_ID:  GRAPHICS_DRIVER_FAULT

CUSTOMER_CRASH_COUNT:  2

BUGCHECK_STR:  0xEA

LAST_CONTROL_TRANSFER:  from 806eeca4 to 804db8f3

STACK_TEXT:  
edf61d5c 806eeca4 00000000 f6bf7000 804da925 nt!KiDispatchInterrupt+0x7f
edf61d68 804da925 edf61d00 00000162 f6bf7000 hal!HalEndSystemInterrupt+0x54
edf61d68 bfa1d653 edf61d00 00000162 f6bf7000 nt!KiInterruptDispatch+0x4d
WARNING: Stack unwind information not available. Following frames may be wrong.
edf61de8 00000000 8607d110 edf61e34 00000002 ialmdev5+0x1c653


STACK_COMMAND:  .thread ffffffff85c98da8 ; kb

FOLLOWUP_IP: 
ialmdev5+1c653
bfa1d653 ??               ???

SYMBOL_STACK_INDEX:  3

FOLLOWUP_NAME:  MachineOwner

SYMBOL_NAME:  ialmdev5+1c653

MODULE_NAME:  ialmdev5

IMAGE_NAME:  ialmdev5.DLL

DEBUG_FLR_IMAGE_TIMESTAMP:  4166b683

FAILURE_BUCKET_ID:  0xEA_IMAGE_ialmdev5.DLL_DATE_10_8_2004

BUCKET_ID:  0xEA_IMAGE_ialmdev5.DLL_DATE_10_8_2004

Followup: MachineOwner
---------

kd> dd watchdog!g_WdBugCheckData l5
f7b573a4  000000ea 85c98da8 862a98d8 8620d3c8
f7b573b4  00000001

well, i'd look for a feedback link on intel's site, or an updated driver if there's one floating around (although, i suspect if there's one available, microsoft's site would have suggested it). we can try asking some of the people from intel who visit bugzilla if they can find someone who can help out....

thanks for promptly posting the dmp. note that if you really want to chase this problem, you'll need to change your system to generate a full memory dump instead of a minidump (win-break, advanced>startup and recovery [settings]>write debug information:complete memory dump), the result is a much bigger file (and you will see windows pause as it tells you it's writing the dump to disk before it reboots), but it's something you can give to someone at intel, and hopefully they can do something with it.

Comment 6

[John Villalovos]

I would prefer not to get spammed in a bug report just because I work at Intel.  80,000+ people work for the company.

I think it is completely inappropriate to add people to the bug report just because they happen to work at Intel.

Comment 7

[Doug Turner (:dougt)]

mass reassigning to nobody.

Comment 8

[Tanner M. Young [:tmyoung]]

Is this still an issue in Firefox 3.5?

If it is not, we should set the resolution of the bug to WORKSFORME.