Hi,
> Igor, I did some more digging, and I have a stack trace for you
>
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V [libjvm.so+0x298366]
> C [libfontmanager.so+0x59e4]
> C [libfreetype.so.6+0x73c9] FT_Stream_Close+0x19
> C [libfreetype.so.6+0xa065
Igor, I did some more digging, and I have a stack trace for you
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x298366]
C [libfontmanager.so+0x59e4]
C [libfreetype.so.6+0x73c9] FT_Stream_Close+0x19
C [libfreetype.so.6+0xa065] FT_Stream_Free+0x25
Hi Igor,
Caveat: I am not a 2d-developer, and am unfamiliar with the API,
and did not write the fix (but I did review it) or the test case.
I was hoping it would be easy for you font wranglers to easily
see how a crash could be triggered. Or at least much easier
than for myself. Given the P2 J
Hi Igor,
> >> It first glance it seems that the only way to get into freetypeScaler.c
> >> is through synchronized methods and
> >> env variable gets overridden every time. So, it seems that it should
> >> match current thread always.
> >> I am interested to understand what i am missing here.
>
Hi,
Suggested changes seems reasonable.
However, i failed to invent testcase to reproduce this issue.
Could you please describe what google test is doing in regard to the
font code?
It first glance it seems that the only way to get into freetypeScaler.c
is through synchronized methods and
env
Hi,
> Suggested changes seems reasonable.
> However, i failed to invent testcase to reproduce this issue.
> Could you please describe what google test is doing in regard to the
> font code?
>
> It first glance it seems that the only way to get into freetypeScaler.c
> is through synchronized met
