I haven't been able to duplicate this, since I'm not unfortunate enough to be running Windows Vista, but the customer reports: The attached file open blank when you’re not Administrator on Vista, if you loaded as Administrator it works fine 1. Find a Vista machine win32. (SP1) 2. Make sure UAC is turned ON. 3. Install the GS 8.7 4. Create a User with NO Administrator rights, and again make sure that UAC is turned ON 5. Log off your account and log in as the new user. 6. Run GS 8.7. 7. Open attached file. 8. Notice it loads blank. 9. Now right-click on GS 8.7 exe file and select "Run as Administrator” 10. Open the attached file. 11. Notice it loads fine. I attached screenshot of the error that GS 8.7 shows, please notice that the same file with same installation of GS 8.7 works fine if you right click and chose to run as admin.
Created attachment 6037 [details] screenshot.jpg
The attached file does not 'load fine' for me when running the current HEAD revision with either an administrator *or* a standard account. In fact I tried several different versions of Ghostscript on my administrator account, and none of them rendered anything for this file, using the display device. Note that when running the file Ghostscript gives several warning messages: **** Warning: File has a corrupted %%EOF marker, or perhaps garbage after %%EOF jasper (code 0) error: cannot decode code stream unable to decode JPX image data. **** Warning: File has insufficient data for an image. The file consists of nothing more than a JPX image wrapped up in a PDF file, so if the image cannot be decoded its not surprising that nothing is rendered. I suspect that the difference experienced by the customer has more to do with the memory layout than anything else, which will obviously be different for different users no matter whether they are administrator or standard accounts, due to the applications loaded at startup. I don't see this as a problem with GS under Vista, this appears to me simply to be due to the fact that the file is badly damaged. I do notice that Acrobat loads the PDF file without complaint, and that the file does not appear to contain anything after the %%EOF, nor does Acrobat offer to save the file on exit suggesting it has not needed to repair it. I used another tool to uncompress the file, but GS still complains about the JPX image. I believe there are two issues, neither anything to do with Vista; 1) The xref may be damaged, assigning this problem to Alex to investigate for now (its a compressed xref stream so I'm not certain). 2) The JasPer decoder may not be capable of handling a specific JPX image. After Alex has looked at the potential xref issue the owner of the JPX code should look into this issue. Marcos, if you have a Luratech build handy it would be worth checking to see what it does with this file.
The file ends with (%%EOF\n\000) . That's the "garbage after EOF". In any case, this is just a warning. The file reads just file on Windows NT and XP. The file is quite small and doesn't need much memory. Most likely, it is a problem with Jasper (or something else) creating temporary file in the wrong place. I need to set up the environment as reported above to try to reproduce the problem.
Alex this one is blank for me on Vista no matter whether I use an administrator account or not (I do have UAC enabled on both). I didn't try on any other flavour of Windows, but I do have a Win2K virtual machine I could try. I can also try Linux of course. In general though JasPer doesn't cause me any problems, so I'm a little surprised that it doesn't work on the file. Since I have a Vista setup and can reproduce the problem it may be easier if I continue to look into it, feel free to assign it back to me.
This is, as expected, a problem with JasPer creating a temporary file. If the size of the image exceeds 16Mb (this one is 21Mb) then JasPer does not create an in-memory stream for processing the image but instead creates a disk based temporary file. The path and name is generated by the tmpnam function and is producing what I would consider to be a spectacularly inappropriate temporary file name. This file is created in the root directory (!) and composed of 's' + the process ID converted to ASCII, followed by a full stop. Windows Vista protects the root directory, and only executables running with Administrator privileges are permitted to write files to it. I thought that Linux similarly protected its root file system but perhaps I'm incorrect. Hmm, I notice that it uses a predefined entry '_P_tmpdir' which it claims is in stdio.h. Oh dear... The VS 2005 implementation of _P_tmpdir in stdio.h does indeed define this 'temporary directory' as being the root '\'.... VS 2008 does the same, not ideal. OK, it seems that if the filename is of the form '\xxxx' with no path information then its supposed to be in the current working directory. That's just weird, not compatible with the usual definition I believe. Since JasPer tries to use the generated name as an argument to fopen, its not using the current working directory at all and that's why it fails.
Created attachment 6100 [details] Interim patch to resolve problem, needs more work ! There are some severe problems with this. The JasPer structure 'jas_stream_fileobj' contains a fixed array to store the pathname, and its based on the same information in stdio.h as tmpnam. As a result its only 14 characters long, not big enough to store a complete path. I've made some changes which fix the issue as far as the temporary filename is concerned (attached diff file). This leaves temporary files lying around in the working directory however. I'm not certain if this is because JasPer unlinks the files as soon as they are created (in case the program crashes) which doesn't work under Windows, or if the fact that the pathname in the structure is wrong (I can't store the filename here because the array is too short) means that its unable to delete the file when its finished with it (I suspect the latter). If its the latter case,as I suspect, then similar code picking up the current working directory and concatenating it with the stored temporary filename when the file is deleted should resolve the problem. I don't know where this is done however. Also the JasPer code needs to be checked to see if there are any other occurrences of tmpnam and these need to be fixed as well if present. As JasPer and JPEG2000 is Masaki's ownership, I'm passing this issue to him.
Ken, thanks for tracking this down. Since this is a customer issue, perhaps we should offer them the Luratech decoder. Marcos or I will take handle a possible switch to Luratech. Since it is a customer issue, I also changed the priority to P2 The correct method (used successfully by Ghostscript for its temp files is to prepend the path for whichever of the following environment variables is defined: TEMP, TMP, or TMPDIR Since we have our own jasper tree, we should fix this until we get switched over to OpenJPEG.
Assuming that the customer has plenty of RAM (reasonable today) the easiest and safest patch is to change jasper/src/libjasper/include/jasper/jas_image.h line 97: #define JAS_IMAGE_INMEMTHRESH (16 * 1024 * 1024) to a larger value -- say 300 Mb: #define JAS_IMAGE_INMEMTHRESH (300 * 1024 * 1024) and recompile. This can provide a workaround until OpenJPEG is available,
Created attachment 6240 [details] b691164_b6.patch Henry taught me this is not Windows only problem. On systems those have mkstemp(), current code tries to create temporary files in current directory. If current directory is read only, it just fails. This should be considered as a bad behavior for a program like ghostscript, which tent to be run as a daemon. In this patch, I implemented a logic Ray suggested in comment 8, and wrote a kind of mkstemp() for Windows. I confirmed this runs correctly on Mac OS X (has mkstemp()) and on read only current directory. This works on usual Windows system as well. I would like Ken to test this patch on Vista, to confirm this patch fixes original problem. I don't have Windows Vista and have not tested on it.
Created attachment 6241 [details] b691164_b8.patch Ken kindly confirmed that the patch works on Vista. This is an updated patch. There ware mistakes in b691164_b6.patch on base 64 conversion and error condition.
The patch has been committed r11182. Closing.
Changing customer bugs that have been resolved more than a year ago to closed.