| Summary: | Abnormal dependence of 'known' on name hash indices | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | leonardo <leonardo> |
| Component: | General | Assignee: | leonardo <leonardo> |
| Status: | NOTIFIED FIXED | ||
| Severity: | normal | ||
| Priority: | P1 | ||
| Version: | 0.00 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Customer: | Word Size: | --- | |
| Attachments: |
MyEnc
params.ps 311-03-.ps 311-03-.ps patch.txt |
||
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. |
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.