The FreeType Project - Bugs: bug #30249, Heap corruption in base/* (Mac...
You are not allowed to post comments on this tracker with your current authentication level.
bug #30249: Heap corruption in base/* (Mac fonts related functions)
Submitter: | Robert Swiecki <jagger> | ||
Submitted: | Thu 24 Jun 2010 09:17:09 PM UTC | ||
Severity: | 3 - Normal | Item Group: | Crash |
Status: | Fixed | Privacy: | Public |
Assigned to: | mpsuzuki | Open/Closed: | Closed |
Planned Release: | 2.3.13 |
( Jump to the original submission )
Thu 01 Jul 2010 08:54:50 AM UTC, comment #8: |
suzuki toshiya <mpsuzuki>![]() ![]() |
Wed 30 Jun 2010 03:46:50 PM UTC, comment #7: I'm sorry, please wait 48 hours. |
suzuki toshiya <mpsuzuki>![]() ![]() |
Wed 30 Jun 2010 03:40:12 PM UTC, comment #6: Hey,
I propose you close this and #30248 bugs, as it seems that the core issues has been fixed, and I'll file another bug with the remaining issues, just to have clear situation over what to fix in the max fonts parsing routines. |
Robert Swiecki <jagger> |
Fri 25 Jun 2010 02:17:25 PM UTC, comment #5: It doesn't throw any errors for me now. It seems that I overestimated the amount of work required to make it fixed. Thanks for looking into this. |
Robert Swiecki <jagger> |
Fri 25 Jun 2010 01:36:46 AM UTC, comment #4: When it have been committed I'll give it a try one more time. It's interesting that lack of just one check leads to so many troubles ;). |
Robert Swiecki <jagger> |
Fri 25 Jun 2010 01:32:13 AM UTC, comment #3: The patch for bug #30248
It seems that, when an error occurs (FT_Stream_Read() got
Please wait my next report. Anyway, I will commit the patch
|
suzuki toshiya <mpsuzuki>![]() ![]() |
Fri 25 Jun 2010 12:53:38 AM UTC, comment #2: Cool, thanks for looking into this.
BTW, this heap corruption ends up with a crash only under specific conditions. I usually test it in the following way: (on Linux)
MALLOC_CHECK_=3 ./ftbench -c 1 <font_file>
Then, if glibc's memory management subsystem detects a malloc()-related issue, it kills the process with SIGABRT (raise(SIGABRT)).
Obviously, similar effect can be observed in valgrind, which reports heap structure corruption issues; and valgrind should be even more reliable here.
|
Robert Swiecki <jagger> |
Fri 25 Jun 2010 12:41:52 AM UTC, comment #1: For first, thank you for reporting the issue in
|
suzuki toshiya <mpsuzuki>![]() ![]() |
Thu 24 Jun 2010 09:17:09 PM UTC, original submission:
gcc version 4.4.3 on Linux amd64, compiled with "-O0 -g"
Font: http://alt.swiecki.net/j/f/sigabrt17.font
There's heap corruption somewhere in Mac font parsing functions. It might be related to: https://savannah.nongnu.org/bugs/?30248
I feel that these functions might need some serious amount of work to make them behave correctly.
$ valgrind ./ftbench -c 1 SIGABRT.PC.0x7ffff7875a75.CODE.-6.ADDR.0x11020000002bb.INSTR.cmp_rax,_0xfffff000.ttf
==1703== Memcheck, a memory error detector
valgrind: m_mallocfree.c:248 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
==1703== at 0x3802CA47: report_and_quit /tmp/vg/coregrind/m_libcassert.c:191
sched status:
Thread 1: status = VgTs_Runnable
|
Robert Swiecki <jagger> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 6 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2010-07-01 | mpsuzuki | Status | In Progress | ![]() |
Fixed |
Open/Closed | Open | ![]() |
Closed | ||
Planned Release | None | ![]() |
2.3.13 | ||
2010-06-25 | mpsuzuki | Status | None | ![]() |
In Progress |
2010-06-25 | mpsuzuki | Assigned to | None | ![]() |
mpsuzuki |
2010-06-24 | jagger | Attached File | - | ![]() |
Added sigabrt17.font, #20813 |
I added additional buffer size checking
(at present, FreeType2 believes the
total size of PFB declared in header,
allocates the buffer by declared size,
and does not check overrun by putting
too long fragments). I close this issue.