| Summary: | Another crash in igc_reloc_struct_ptr | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Igor Melichev <igor.melichev> |
| Component: | General | Assignee: | Igor Melichev <igor.melichev> |
| Status: | NOTIFIED FIXED | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 0.00 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Customer: | Word Size: | --- | |
| Attachments: | valgrind log | ||
|
Description
Igor Melichev
2005-07-20 09:03:35 UTC
Created attachment 1549 [details]
hdr.ps
The test file is generated from comparefiles/japan.ps with ps2write.
-Z$@? doesn't detect an error. I am unable to reproduce this problem. My command line: bin/gswin32c.exe -r72 -dNOPAUSE -dNOOUTERSAVE -sDEVICE=ppmraw -sOutputFile=xx .pnm ../test_files/688222.ps -c quit 1>>log 2>>log2 I am uaing current CVS head, WinXP, and the MSVC .NET 2003 compiler My compiler is Microsoft Visual C++ 2005 55603-000-0000016-00642 Well, I spent an hour for finding a reason one one my copy of Ghostscript crash, and another one doesn't. After many attempts I erased obj and bin directories and built them anew in both copies. Still one runs, and another one crash. Interesting that obj directories got a different size. Then I noticed that the directory names have different length, so the commnds look like this : ..\..\gs-hd\bin\gswin32c.exe -IF:/AFPL/gs-hd/lib;f:\afpl\fonts -r72 -dNOPAUSE - dNOOUTERSAVE -sDEVICE=ppmraw -sOutputFile=cur.ppm attachment.ps -c quit ..\..\gs-hdr\bin\gswin32c.exe -IF:/AFPL/gs-hdr/lib;f:\afpl\fonts -r72 - dNOPAUSE -dNOOUTERSAVE -sDEVICE=ppmraw -sOutputFile=cur.ppm attachment.ps -c quit When I create a copy of the first directory with the name GS-HDE, it crashes, rather with GS_HD it doesn't. Also creating a copy of the second one with the name GS_HE, it doesn't crash, rather than gs_HDR does. Thus the effect strongly depends on the directory name length, maybe due to it is used in the -I command like option. I don't think that you guys can reproduce this, so I'll stop any other work to exclude variations of environment untill I find the reason for the problem. Created attachment 1551 [details]
valgrind log
This is a Valgrind log for the test cass on my GNU+Linux box.
I hope it helps. It looks like there are several errors in the GC code.
The errors about memory and string functions are mostly harmless.
The error about the "Use of uninitialised value of size 4"
will be addressed separately. I think we need to test GS under valgrind
during regression testing, at least occasionaly.
I opened a new bug 688225 about the valgrind report. Please put related followups to there. The crash happens due to an attempt to relocate a pointer gs_show_enum::dev_cache2. There exist a single place where such structure is being allocated, and the field is immediately initialized. At the crash point the pointer points to an area with a good data (an image1 device), but the descriptor of the area is bad. Maybe it was prematurely released, or allocated in a wrong space, or its descriptor was damaged ? Running -Z? gives a crash in ialloc_validate_object regadring to that pointer. So I conclude that the pointer damage happens quite immediately before the garbager invocation. Well, the instance of gs_show_enum is allocated in global memory, and dev_cache2 points to a local memory. It happens due to gs_show_enum is being allocated in the current memory space, rather than cache devices do in the space of the graphic state. Recently we fixed a similar problem with gs_image_enum. So now we know what to do. See also Bug 688227. Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2005-July/005615.html |