C# Process breaks on Large Standard Input

Question

I need to Encrypt the content of file by GnuPG encryption. for that, I am fetching content from FILE and passing it Process via StandardInput. For small data it is working fine but when I try to Write StandardInput of more than 500KB data, program gets stuck.

    process = new Process();
     process.StartInfo.WorkingDirectory = _bindirectory;
     process.StartInfo.RedirectStandardInput = true;
     process.StartInfo.RedirectStandardOutput = true;
     process.StartInfo.RedirectStandardError = true;
     process.StartInfo.FileName = gpgExecutable;
     process.StartInfo.Arguments = gpgOptions;
     process.StartInfo.UseShellExecute = false;
     process.StartInfo.CreateNoWindow = true;

     process.Start();
/*****Here is the line where Compiler Process Stucks on large data****/
     process.StandardInput.Write(inputText); 
     process.StandardInput.Flush();
     process.StandardInput.Close();

     process.OutputDataReceived += process_OutputDataReceived;
     process.ErrorDataReceived += process_ErrorDataReceived;
     process.BeginErrorReadLine();
     process.BeginOutputReadLine();
     process.WaitForExit();

Please suggest a solution? Should i send data of file in chunks???

If your program executes at all, then this is not **the compiler**'s fault. The compilation phase has ended long time ago before the program has been launched. Please watch the terminology a bit.. But that's a minor thing. You have not said the most important: **how does it look** when your program break? **how** does it 'stuck'? Any exceptions? Crashes? Logs? Messages? Stacktraces? — quetzalcoatl, Sep 19 '12 at 08:20
You probably want to hook up those `...Received` handlers before you start the process. Otherwise, you might miss some events. — Damien_The_Unbeliever, Sep 19 '12 at 08:44
@Quetzalcoatl: No response.. i left application for 2 mints NO CRASH or EXCEPTION occurred, Can't see anything in stack trace or logs — nalaiqChughtai, Sep 19 '12 at 13:36
@Damien: process.StandardInput.Write(inputText); calls before RECIEVED HANDLER. process.StandardInput.Write(inputText); this is line where compiler show even not a response. i dont think thats a compiler issue. It should be smth related to BUFFER — nalaiqChughtai, Sep 19 '12 at 13:38
Do you understand the difference between the 'compiler', 'linker', 'debugger' and the 'IDE' at all? I think you not. Start here: http://www.blurtit.com/q3321346.html It seems that you'd rather want to say "debugger" instead..Anyways, have you tried putting some breakpoints before/at/after that line? Has the debugger stepped through the stdin.write correctly and got to the "flush" line, or did it hang right there at stdin writing and never finished writing? Have you checked if the stdin's flags like CanRead or CanWrite? Next step is to do what Damien said:attach to events and check what arrives — quetzalcoatl, Sep 19 '12 at 14:36
May be i didn't explain correctly. Anyways. Yep i have been tried these all things. Debugger not stepped through the WRITE command. it just stucks there. — nalaiqChughtai, Sep 19 '12 at 15:21

score 0 · Answer 1 · edited May 23 '17 at 11:55

By the way, what is the data that you are trying to pass through? is it text or binary data? If binary, try writing to the StandardInput.BaseStream instead. I think that stdin is in textual mode by default and can get broken if passed some certain bytes like EOF or NULL.. see https://stackoverflow.com/a/1284753/717732

Edit:

I as right in my comment - if the child process does not read the data fast enough (or doesn't read at all) the stream buffer will get choked and all writes will block, just like reads block when the buffer is empty. See for example How to avoid standard input getting stuck in c# process

You may verify this easily: create a tiny application which reads from stdin in an infinite loop. Then, temporarily replace your gpgexecutable path with a that one tiny test app and see if blocks or not. It most probably will not block.

You should definitely check why the child process is not reading the data you try to send. Maybe commandline parameters are wrong? Or if everything seems fine and it is just the childprocess working so slowly (you can check the process' activity in TaskMonitor - does the gpg sleep or spin?), then put the stream-writing code into some backgroundworker..

Eh.. Strange one.. Ok, so if it hangs at that line and there are no exceptions and the CanWrite is True, then the only cause I can think of is that the child process stopped reading data fomr the stdin and that the stdin's buffer has run out of space and it caused your process to infinitely wait until there is space in the buffer to write another block of data.. this is a complete guess however. If I find ome time, I'll try tomorrow to create similar two projects and send few megs of text and check how it behaves when noone reads from the pipe. — quetzalcoatl, Sep 19 '12 at 19:00
I've updated the answer. Doubke check your gpg params and try with some guaranteed-reading test app. — quetzalcoatl, Sep 21 '12 at 07:30

C# Process breaks on Large Standard Input

1 Answers1