Valgrind reports access to uninitialized memory with many files, for instance valgrind gs -sDEVICE=nullpage -dNOPAUSE -dBATCH comparefiles/336-01.ps The appears in the code added by the rev. 10603. The uninitialized values, apparently, din't affect the output files but it would be great to fix this anyway. The bug can be easily observed by placing a breakpoint at gschar0.c:450 and examining the value of pte->fstack.items[fdepth].index .
I thought even pte->fstack.items[fdepth].index is not initialized, the effect was harmless, i.e. the equivalent of 'if' block was already done and there is no harm to do that again. However, several test I performed today indicates that there is a possibility of another path, and it may do it harmful way. I will look into it and remove valgrind warnings. Thank you Alex for pointing this out.
A fix is committed in r11281. ------------------------------------------------------------------------ r11281 | masaki | 2010-05-19 19:09:05 +0900 (Wed, 19 May 2010) | 9 lines Bug 691291. Fix reading uninitialized memory. The change I made in r10603 had a problem comparing with uninitialized data when using Roman fonts. The side effect was slowing down font rendering a little. In this change I added extra initializer and made intention of the 'if' condition more clear. No difference on outputs expected nor observed by localcluster tests. ------------------------------------------------------------------------ If you still find more errors, please reopen this bug and assign to me.