Andrew Schultz Assignee
	Description • 21 years ago

Mozilla hangs while downloading a piece of spam.  debugging shows that it's hung
up in readTokens in nsBayesianFilter.cpp

	Andrew Schultz Assignee
	Comment 1 • 21 years ago

0x460a831e in readTokens (stream=0x89d6878, tokenizer=@0x882d4ac) at
nsBayesianFilter.cpp:925
925			newBufferSize *= 2;
(gdb) p tokenCount
$1 = 25484
(gdb) p i
$2 = 17664
(gdb) p size
$3 = 3267347362     <== impressive
(gdb) p newBufferSize
$4 = 0
(gdb) p bufferSize
$5 = 0

	Andrew Schultz Assignee
	Comment 2 • 21 years ago

a clean profile can successfully download mail.  clean profile with this
training.dat file hangs downloading the mail.

I also tried deleting the specific piece of spam that was causing the hang
before, and the clean profile hung on a different one.

	Andrew Schultz Assignee
	Comment 3 • 21 years ago

a clean profile could download the mail properly.  a clean profile with my
training.dat file hit this bug.

	Andrew Schultz Assignee
	Comment 4 • 21 years ago

looking at the training.dat file, there seem to be a couple sections that are
uncharacteristic.  the first such section looks like a xine configuration file.
 My system was having trouble distinguishing up from down for a while, and so
the file getting corrupted is probably INVALID.  lowering severity.

it would still be nice if Mozilla didn't hang...

	Wayne Mery (:wsmwk)
	Comment 5 • 18 years ago

hang=critical

blocking bug 262743 and bug 317798 on the probability that these are related. 
bug 317798 also has a test training.dat file.
also related? bug 285927, bug 240788

	Andrew Schultz Assignee
	Comment 6 • 18 years ago

bug 240788 helped here, but we still attempt to allocate 2GB of memory on bogus sizes (which would bring things to a stand-still).  Also, if a 2GB token *was* read in and then the next token claimed to be bigger, we'd still hit unchecked overflow.

I'm not sure what mGoodCount and mBadCount have as a purpose in life, but if they're supposed to be related to the number of tokens, then this code needs to update their values on failure.

	David :Bienvenu
	Comment 7 • 18 years ago

Comment on attachment 239465 [details] [diff] [review]
don't try to allocate memory that has no chance of being used

this looks ok to me, but I haven't tried it out...

	Wayne Mery (:wsmwk)
	Comment 8 • 18 years ago

OS=ALL?

	Andrew Schultz Assignee
	Comment 9 • 18 years ago

FIXED

	Wayne Mery (:wsmwk)
	Comment 10 • 18 years ago

Comment on attachment 239465 [details] [diff] [review]
don't try to allocate memory that has no chance of being used

after sufficient baking of course.

	Scott MacGregor
	Comment 11 • 18 years ago

Comment on attachment 239465 [details] [diff] [review]
don't try to allocate memory that has no chance of being used

I think this has had sufficient bake time :)

	Andrew Schultz Assignee
	Comment 12 • 18 years ago

Scott, can you grant approval for bug 240788 as well?  It'd be easier if this one doesn't land first.

	Scott MacGregor
	Comment 13 • 18 years ago

(In reply to comment #12)
> Scott, can you grant approval for bug 240788 as well?  It'd be easier if this
> one doesn't land first.
> 

done! Thanks for pointing that bug out.

	Andrew Schultz Assignee
	Comment 14 • 18 years ago

landed on branch

	Carsten Book [:Tomcat]
	Comment 15 • 18 years ago

Verified for 1.8.1.2 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070105 Thunderbird/2.0b1 ID:2007010503 on Fedora FC 6 with testcase training.dat