The customer reports that when they run several instances of Ghostscript converting the attached file they receive the following Windows error message: "R6016 - not enough space for thread data". From the customer's email: We are converting with the following command line gswin64c.exe -sDEVICE=tiffg4 -dSAFER -r300 -dBATCH -dNOPAUSE -sOutputFile=7_915.tif 7.pdf I am able to duplicate this issue by running the 3 batch files in parallel on the same machine. I've copied the original image into multiple copies and run them from 3 separate Command Prompts. For reference, my laptop is Windows 7 (64bit), intel i7 (8 core), 8GB RAM. This behavior will happen under normal production load on our Windows 2k8r2 servers depending on load when processing the included image.
A bit of googling comes up with : We recommend that an executable that calls the C run-time library (CRT) should use _beginthreadex for thread creation rather than the Windows API CreateThread. _beginthreadex initializes internal static storage used by many CRT functions in thread local storage. If you use CreateThread to create a thread, the CRT may terminate the process with R6016 when a call is made to a CRT function that requires initialized internal static storage. From <https://msdn.microsoft.com/en-us/library/d509d9f9.aspx> and also <https://msdn.microsoft.com/en-us/library/windows/desktop/ms682453(v=vs.85).aspx>.
(In reply to Marcos H. Woehrmann from comment #1) > A bit of googling comes up with : > > We recommend that an executable that calls the C run-time library (CRT) > should use _beginthreadex for thread creation rather than the Windows API > CreateThread. Sadly, we already use _beginthreadex rather than CreateThread, so it doesn't sound like this is the magic bullet we might hope for. More analysis required.
Assigned to Marcos to reproduce.
I'm not able to reproduce this. I setup a virtual machine running Windows 7 SP1 with 8GB of RAM and an 8-core i7 CPU. I installed the customer release of Ghostscript 9.15 64 bit and opened 3 command prompts windows. Running the 6.bat, 7.bat, and 8.bat batch files in parallel did not produce any errors. As a further test I generated batch files 1.bat through 5.bat and ran all 8 batch files at the same time but didn't see any errors with that configuration. I've emailed the customer and pending further information that will allow us to reproduce this bug I'm closing it as worksforme.