The FreeType Project - Bugs: bug #30263, SIGSEGV under certain conditions...
You are not allowed to post comments on this tracker with your current authentication level.
bug #30263: SIGSEGV under certain conditions in smooth/ftgrays.c:486
Submitter: | Robert Swiecki <jagger> | ||
Submitted: | Fri 25 Jun 2010 02:11:12 PM UTC | ||
Severity: | 3 - Normal | Item Group: | Crash |
Status: | Fixed | Privacy: | Public |
Assigned to: | wl | Open/Closed: | Closed |
Planned Release: | 2.3.13 |
( Jump to the original submission )
Fri 02 Jul 2010 12:18:22 AM UTC, comment #19: |
Robert Swiecki <jagger> |
Thu 01 Jul 2010 11:36:13 PM UTC, comment #18: Please run the current git against sigsegv25.ttf again; hopefully, all valgrind errors are gone now – note that I get similar but different errors which probably have the same cause. |
Werner LEMBERG <wl>![]() ![]() |
Wed 30 Jun 2010 02:47:19 PM UTC, comment #17: Thanks for testing; I'll fix it in the repository. Regarding the other valgrind issue, I'm actually able to reproduce it, however, I wasn't able to reduce it to something I can debug: If I just run a part of the tests (for example, using the `-b c' command line option to test rendering only), the error doesn't occur. Strange. And the place where it happens is unfortunately very unspecific (namely the beginning of the interpreter loop). Of course, neither ftview nor any other demo program exhibits the valgrind error...
|
Werner LEMBERG <wl>![]() ![]() |
Wed 30 Jun 2010 02:29:06 PM UTC, comment #16: Yeah... it passes right now w/o any crashes. There's another valgrind warning printed, but it seems it's in another part of the code
|
Robert Swiecki <jagger> |
Wed 30 Jun 2010 02:15:19 PM UTC, comment #15: Even a 0x7FFF x 0x7FFF bitmap is quite large :)
|
Werner LEMBERG <wl>![]() ![]() |
Wed 30 Jun 2010 02:06:47 PM UTC, comment #14: And that values come from:
|
Robert Swiecki <jagger> |
Wed 30 Jun 2010 01:44:34 PM UTC, comment #13: Before I do that, maybe this will help. It seems that the problem might be caused by an integer overflow.
|
Robert Swiecki <jagger> |
Wed 30 Jun 2010 11:20:31 AM UTC, comment #12: Thanks, the binary reproduced SEGV crashing on my GNU/Linux
|
suzuki toshiya <mpsuzuki>![]() |
Wed 30 Jun 2010 09:41:08 AM UTC, comment #11: Yeah.. try this one
|
Robert Swiecki <jagger> |
Wed 30 Jun 2010 01:19:09 AM UTC, comment #10: I couldn't reproduce this issue on my amd64 GNU/Linux
|
suzuki toshiya <mpsuzuki>![]() |
Tue 29 Jun 2010 03:29:43 PM UTC, comment #9: I'm sorry, I don't have 64bit machine with 8GB RAM,
|
suzuki toshiya <mpsuzuki>![]() |
Mon 28 Jun 2010 07:30:44 PM UTC, comment #8: I fear I can't debug this with my limited amount of main memory built into my Laptop. If you look at the number of allocated bytes valgrind reports, this is far beyond what I can handle gracefully.
|
Werner LEMBERG <wl>![]() ![]() |
Mon 28 Jun 2010 03:23:44 PM UTC, comment #7: Well, actually the valgrind is a little bit different in the 32bit case.
|
Robert Swiecki <jagger> |
Mon 28 Jun 2010 03:12:30 PM UTC, comment #6: Hm.. I have 8GB so I'm noticing memory issues.. :)
|
Robert Swiecki <jagger> |
Sun 27 Jun 2010 09:45:23 PM UTC, comment #5: I've found and fixed some bugs in the cff code, however, I still don't get a crash in the smooth module. Maybe a 32/64bit issue?
|
Werner LEMBERG <wl>![]() ![]() |
Sun 27 Jun 2010 01:17:39 AM UTC, comment #4:
|
Robert Swiecki <jagger> |
Sun 27 Jun 2010 12:59:36 AM UTC, comment #3: What about this one: http://alt.swiecki.net/j/f/sigsegv22.pfr
|
Robert Swiecki <jagger> |
Sun 27 Jun 2010 12:43:54 AM UTC, comment #2: I think I've fixed the problem with line 404 in pfrgload.c (now in git). However, I can't reproduce the problem in ftgrays.c. |
Werner LEMBERG <wl>![]() ![]() |
Fri 25 Jun 2010 02:15:01 PM UTC, comment #1: And valgrind output, not sure if it's really related to the problem described below:
|
Robert Swiecki <jagger> |
Fri 25 Jun 2010 02:11:12 PM UTC, original submission:
This might not be easy to reproduce, .. anyway.
|
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 10 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2010-07-01 | wl | Assigned to | mpsuzuki | ![]() |
wl |
2010-06-30 | wl | Status | Works For Me | ![]() |
Fixed |
Open/Closed | Open | ![]() |
Closed | ||
Planned Release | None | ![]() |
2.3.13 | ||
2010-06-30 | wl | Assigned to | wl | ![]() |
mpsuzuki |
2010-06-28 | wl | Carbon-Copy | - | ![]() |
Added mpsuzuki |
2010-06-27 | jagger | Attached File | - | ![]() |
Added sigsegv23.otf, #20828 |
2010-06-27 | wl | Status | None | ![]() |
Works For Me |
Assigned to | None | ![]() |
wl | ||
2010-06-25 | jagger | Attached File | - | ![]() |
Added sigsegv22.pfr, #20820 |
Yeah.. it doesn't produce any errors now.
Btw, I don't any more testcases crashing libfreetype now. I'll have the fuzzer working over-night, but I don't expect anything new.
So, thanks for fixing all those bugs, and happy development :).