341355 - probably print preview uses free memory on clicking close.

Status: RESOLVED FIXED

(Core :: Print Preview, defect)

Description

[georgi - hopefully not receiving bugspam]

probably print preview uses free memory on clicking close in 1.5 and 2.0 branch.

symptoms are:

1. on linux with valgrind - clicking close on any print preview:
==4853== 
==4853== Invalid read of size 4
==4853==    at 0x1C161276: FT_Done_Face (in /usr/lib/libfreetype.so.6.3.8)
==4853==  Address 0x1EE4FA80 is 96 bytes inside a block of size 540 free'd
==4853==    at 0x1B9003B3: free (vg_replace_malloc.c:235)
==4853==    by 0x1C15DADA: (within /usr/lib/libfreetype.so.6.3.8)

on trunk with valgrind don't get this error.

2. on freebsd 6.1 with MALLOC_OPTIONS=J. this malloc option forces free() to
clear the deallocated memory, filling it with 0xd0.

after clicking "close" in print preview, firefox crashes with SIGBUS and if
 gdb and the core are to believed the stack is full with 0xd0 (probably
caused by MALLOC_OPTIONS). if the 'J' option isn't set, firefox doesn't
crash.

couldn't fill the free()ed memory with my data yet, so probably the window
of opportunity is small.

Comment 1

[timeless]

could you possibly file bugs into core instead of firefox? people don't always triage firefox very well :(

Comment 2

[georgi - hopefully not receiving bugspam]

(In reply to comment #1)
> could you possibly file bugs into core instead of firefox? people don't always
> triage firefox very well :(
> 

ok, got it.

Comment 3

[georgi - hopefully not receiving bugspam]

i don't crash anymore with clearing hooks and valgrind doesn't complain as before so this seems fixed?

Comment 4

[georgi - hopefully not receiving bugspam]

i mean i don't crash on trunk.

Comment 5

[georgi - hopefully not receiving bugspam]

trunk seems safe from this, but 1.5.0.5 and 2.0b1 crash.

Comment 6

[georgi - hopefully not receiving bugspam]

trunk and 2.0.0.1 are safe, 1.5.0.9 is not according to valgrind.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

There's almost no stack given with the valgrind warnings above, but this seems like it's probably a duplicate of bug 355059.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Could you retest with *tomorrow's* 1.8.0 branch build?

Comment 9

[georgi - hopefully not receiving bugspam]

(In reply to comment #8)
> Could you retest with *tomorrow's* 1.8.0 branch build?
> 

according to valgrding today's 1.8.0 branch is safe from this on linux.

Comment 10

[chris hofmann]

so, is this ready to close?

Comment 11

[georgi - hopefully not receiving bugspam]

according to my tests this is fixed on linux trunk and 2.0.1
not fixed in 1.5.0.9

Comment 12

[georgi - hopefully not receiving bugspam]

confirming comment #10 that 1.8.0-latest is safe according to valgrind

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

So this is fixed? Why not then mark this FIXED or WORKSFORME