Mon 17 Mar 2014 06:33:48 AM UTC, comment #11:
Thanks, and fixed in git.
I think it's actually a bug in HarfBuzz, and I've sent a report to its author.
[And it's probably a bug in valgrind, too, that it doesn't report an error for me...]
|
Sun 16 Mar 2014 06:41:28 PM UTC, comment #10:
There you go ;)
(file #30918)
|
Sun 16 Mar 2014 06:03:28 PM UTC, comment #9:
Thanks! This helps. Unfortunately, I made a mistake: I don't need the value of `face' in function `af_get_coverage' (which is hb_face_t) but the one in function `af_loader_load_glyph' (which is FT_Face). Please provide this.
|
Sun 16 Mar 2014 05:45:05 PM UTC, comment #8:
OK, attached new "bt full" and "p face". I had to recompile harfbuzz with debug symbols too or I wouldn't have any info on hb_face_t *.
Also added a valgrind run.
(file #30916, file #30917)
|
Sun 16 Mar 2014 09:42:34 AM UTC, comment #7:
Well, yes, it's with debug symbols, but from an optimized build, and many important values are `optimized out'.
Can you run your program within gdb and check the values of the `face' variable if you get the crash? And can you run `valgrind' on your program? Maybe this gives additional insight.
Note that I don't get any problems with Roboto-Thin.ttf.
|
Sat 15 Mar 2014 08:42:54 PM UTC, comment #6:
I'm using Roboto too. Maybe that's the problem? I attach the ttf here as all of them print out "layout tables are invalid" with ftvalid.
btw Werner, that bt is with FreeType already with debug symbols:
file ./pkg/freetype2/usr/lib/libfreetype.so.6.11.2
./pkg/freetype2/usr/lib/libfreetype.so.6.11.2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=d4daa5bb81588073af726156ada4a2831e340c19, not stripped
and lots of symbols with objdump -t
(file #30912)
|
Sat 15 Mar 2014 07:08:55 PM UTC, comment #5:
The very problem is that I don't get any problems with Roboto on my GNU/Linux box, so I can't debug this issue. Maybe the use-case isn't covered by the ftdemo programs, or your platform has specific demands that make the bug rise its ugly head.
|
Sat 15 Mar 2014 09:22:12 AM UTC, comment #4:
I have the same problem using Roboto font. I guess it's problem with freetype2 and that font. Switching to it should make the crash 100% reproducible for some programs(VLC for example).
Switching to Droid font family makes the crash disappear, for now.
|
Fri 14 Mar 2014 03:20:54 PM UTC, comment #3:
No, I mean FreeType. Sorry for being imprecise. Please compile it without optimizations so that a run in the debugger gives better results.
Looking into the your log files, the affected font is probably `DejaVuSansMono.ttf', but you can get more information by inspecting the `face' variable.
|
Fri 14 Mar 2014 03:03:26 PM UTC, comment #2:
Just to clear things up:
a) you mean ristretto right?
b) how do I check what font it is?
|
Fri 14 Mar 2014 02:52:19 PM UTC, comment #1:
Thanks for the report. Unfortunately, the traces only show a problem with the new harfbuzz code, but for further tests I need (a) a backtrace from the program with debugging symbols, and (b) the problematic font that triggers the bug.
A quick solution is to compile FreeType without harfbuzz:
./configure --with-harfbuzz=no ...
|
Fri 14 Mar 2014 10:25:16 AM UTC, original submission:
Well, summary says it all :)
I'm using Arch Linux and reverting back to freetype2-2.5.2 makes my system work again. I'll attach a strace and a backtrace with debug symbols of ristretto which is one program that stops working, but there are more.
If you need me to do more tests, I'll do my best to help.
|