PIPE: issue

[alfkil]

When working with Spotless (the debugger), I am running into a problem with the PIPE: device.

The problem arises, when I load Spotless into Spotless (self-debugging). Upon Start (IExec->RestartTask()) the child will crash on this line :

Code: Select all

fd[1] = IDOS->Open ("PIPE:/UNIQUE/NOBLOCK", MODE_NEWFILE);

The child is created using the following line of code :

Code: Select all

    process = IDOS->CreateNewProcTags(
		NP_Seglist,					seglist,
//		NP_Entry,					foo,
		NP_FreeSeglist,				false, //important
		NP_Name,					strdup(command.c_str()),
		// NP_CurrentDir,				lock,
		// NP_ProgramDir,				homelock,
		// NP_StackSize,				2000000,
		NP_Cli,						true,
		NP_Child,					false, //important
		NP_Arguments,				arguments.c_str(),
		NP_Input,					IDOS->Input(),
		NP_CloseInput,				false,
		NP_Output,					IDOS->Output(), //pipe.getWrite(),
		NP_CloseOutput,				false,
		NP_Error,					IDOS->ErrorOutput(),
		NP_CloseError,				false,
		NP_NotifyOnDeathSigTask,	IExec->FindTask(0),
		TAG_DONE
	);

Does anyone have any ideas, why this fails? The only solution, I have come up with so far, is to remove the references to PIPE: entirely. Then the subprocess will start and finish problem free.

[billyfish]

Hi

As a quick question, what's the scope of arguments? As if that goes out of scope, then maybe the value passed in for NP_Arguments would be garbage?

billy

[alfkil]

@billyfish

Thanks! It is definitely a good thing to safeguard these variables. I have inserted a strdup. Sadly it didn't solve the problem.

[colinw]

Every tag gets a free autodoc.

* NP_Name (STRPTR) -- Name of the child process. Defaults to
* "New Process" if no tag is specified, or a NULL tag is supplied.
* There is no maximum length limit imposed on this string.
* The child process' task structure; task->tc_Node.ln_Name
* will point to the buffer to where this string is copied.
* The exec function FindTask() searches on this string.
*
* From V50, the internal copy of your NP_Name string is added to
* the task memory list and will therefore be freed automatically
* when the process eventually exits.
* DO NOT use this tag with anything but a nul-terminated c-string.
*

[salass00]

@alfkil

In your code you are passing the parent Input() file handle directly to the child using NP_Input.

If you read the WARNING section in the dos.library/CreateNewProcTags autodoc entry (second paragraph) you can find there an explanation why doing this and providing NP_Arguments is bad:

NEVER specify NP_Input,ZERO if you also specify NP_Arguments tag,
When 'NP_Arguments' is specified, it needs to modify the Input()
stream filehandle buffer to make ReadArgs() and others work properly.
If NP_Arguments is needed, the best thing is to not specify NP_Input
at all, so a valid NIL: stream will be allocated automatically.

NEVER share the NP_Input filehandle with other processes, as the
input buffer is modified to make ReadArgs() and other work,
this will cause a race condition in the buffer restoration on exit.
If you must supply an NP_Input, use a DupFileHandle() copy of it.

[alfkil]

@colinw

Ok, so the strdup() is redundant. Good to know!

@salass00

If I understand this correctly, then DupFileHandle() at the NP_Input tag is the way to go? Or I am not able to specficy NP_Arguments and NP_Input simultaneously? This is a little confusing. I can remove either one of them, but it is going to degrade the amount of functionality in the application.

[salass00]

You should pass a copy of the Input() file handle (as gained from DupFileHandle()), rather than the file handle itself. Also there is no need to make a copy of the string for NP_Arguments (dos.library should handle that according to the autodoc).

Edit: That is if you want the program to have the same stdin input stream as the parent. If a NIL: input stream is what you want instead then you should remove NP_Input or pass Open("NIL:", MODE_OLDFILE) instead.

[alfkil]

@salass00

That is good to know. Thanks! I will modify the code accordingly.

For now, I have solved the original problem of the thread. It happened, because there was a hidden call to newlib from inside the debug hook. Or at least removing the newlib call changed the behavior to not crashing.