On 10/7/19 15:21, Nikolay Sivov wrote:
Is it the same for tahoma.ttf?Were you able to figure out where in CEF it fails and why exactly?
It is the same for tahoma.ttf in a way that it also gets "\..\" in the path of course, but only times.ttf affects the crash I debugged.
I didn't figure exact reason inside libcef.dll. I just can say that crash happens inside its code using some (probably class) pointers initialized earlier. The minimal fix which makes me think that the core reason is in treating the font file name outside of Wine is the fact that I can workaround the crash by using GetFullPathName for returned file name in localfontfileloader_GetFilePathFromKey() only (ddraw/font.c). As far as I can tell, this function is not used anywhere in Wine directly. This still leaves some chance of course that the output of this function was passed to some Wine function which mishandles the path with "..", but I could not find this path passed to anything with +font, +file or +relay log. The sequence of fonts queries to dwrite changes after getting "Times New Roman" from enumeration through dwrite between successful sequence (with the path without "..") and the failing one. I also don't think that breaking on a font path with ".." is likely as we would likely have this problem exhibit itself somewhere else. This leaves some small chance of course that the true core reason lies somewhere deeper. My reasoning was that avoiding relative path parts in font file name is the right thing to do regardless. I was also thinking of suggesting the fix right to dwrite/font.c create_local_file_reference(), as the documentation to IDWriteFactory_CreateFontFileReference suggests that file path must be absolute path. But it looks reasonable to me to avoid unusual path in registry filled by gdi32 also, as it also exposed to the applications. Besides, according to my testing on Windows, while _CreateFontFileReference rejects truly relative paths, it is ok with the paths containing "\..\".