Running pdfwrite 311-03.ps got : Fail: (localdict2 \(key4\) known ?) A further analyzis shows that the efect depends on the content of gs\Resource\Encoding. A fresh gs copy has gs/Resource/Encoding/Wingdings, and doesn't fail. When I add gs/Resource/Encoding/MyEnc , it stablely fails. Devices other than pdfwrite don't fail. The command line is : F:\SVN-GS\HDRF\gs\bin\gswin32c.exe -IF:\SVN-GS\HDRF\gs\lib;f:\afpl\fonts - dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=HDRF.pdf params.ps 311-03-.ps It happens with gs revision 8047 and withj few older revisions. Younger revisions were not tested yet. The test file checks the interaction of def/undef/known with save/restore. It doesn't deal with Resource, but the Ghostscript initialization fails do read gs/Resource/Encoding. I guess here we observe eiter a delicate heap corruption, or a bug in save/restore logic, possibly related to name indices. Particularly, need to check whether a name may be garbage colloected while it is used in a dictionary, and later re-created with another index.
Created attachment 3027 [details] MyEnc Attaching the mentioned resource file, rather I don't think that its content is really important for the problem. However it may be impotant for reproducing the problem.
Created attachment 3028 [details] 311-03-.ps A simplified test case, which fails as well.
Diagnosed with MSVC8 debug build. Setting P1 because it impedes the regression testing.
Created attachment 3029 [details] params.ps Attaching params.ps, which is listed in the command line. The failure with this command line appears to depend on presence of it in the command line. However here is another command line with no params.ps, which fails also : ..\..\gs-hd\bin\gswin32c.exe -IF:/AFPL/gs-hd/lib;f:\afpl\fonts -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=cur.pdf H:\AuxFiles\comparefiles\311-03.ps Thus the effect is pretty delicate and it possibly is hardly reproducible on another machine.
Created attachment 3032 [details] 311-03-.ps A more simplified test case.
Created attachment 3033 [details] 311-03-.ps A more simplified test case. It allows to set a conditional breakpoint at idict.c:307 to filter out operations with the interesting dictionary. The condition is pkey->value.bytes[0]=='k' && pkey->value.bytes[1]=='e' && pkey->value.bytes[2]=='y' .
Here is the bottom of the problem. The further explanation assumes gs revision 8047 with applied changes 8062, 8064, when it works with params.ps and the attachment 3033 [details]. Here is the action sequence : key2 put start=4 empty insert key3 put start=3 hash-conflict key4 put start=3 empty insert index=2 empty insert key3 undef start=3 found set("deleted") save key4 undef start=3 "deleted" index=2 found idict.c:589 succeeds [1]==("empty"), [2]:="empty" [3]:="empty" restore : [3] is still empty. key4 known start=3 empty (must be deleted!) goto miss (wrong!!!!!) So here we observe a bug in the interaction of the "undef" algorithm with "restore". The effect depends on hane hash, that explains why it depends on params.ps and on MyEnc - the just interfere the name indices. Need to think how to fix it better.
The last comment has been added with errors. Here is the improved revision : Here is the bottom of the problem. The further explanation assumes gs revision 8047 with applied changes 8062, 8064, when it works with params.ps and the attachment 3033 [details]. Here is the action sequence : key2 put start=4 empty insert key3 put start=3 empty insert key4 put start=3 hash-conflict index=2 empty insert key3 undef start=3 found set("deleted") save key4 undef start=3 "deleted" index=2 found idict.c:589 succeeds [1]==("empty"), [2]:="empty" [3]:="empty" restore : [3] is still empty. key4 known start=3 empty (must be deleted!) goto miss (wrong!!!!!) So here we observe a bug in the interaction of the "undef" algorithm with "restore". The effect depends on hane hash, that explains why it depends on params.ps and on MyEnc - the just interfere the name indices. The culprit is the cycle in idict.c:579-580. Its changes are not saved. Need to think how to fix it better.
s/hane/name
Changing the bug summary for a better reflection of the problem. The old one is "Abnormal dependence of 'known' on the Resource/Encoding contents.".
Created attachment 3034 [details] patch.txt A suggested patch is being tested now.
The patch passed the regression test. It has been committed. Here is the full list of patches related to this problem : http://ghostscript.com/pipermail/gs-cvs/2007-June/007641.html http://ghostscript.com/pipermail/gs-cvs/2007-June/007643.html http://ghostscript.com/pipermail/gs-cvs/2007-June/007644.html http://ghostscript.com/pipermail/gs-cvs/2007-June/007647.html The last patch is the real fix. Others just improve the debugging technology. Closing the bug now.