Page 1 of 1
PIPE: issue
Posted: Wed Nov 02, 2022 4:22 pm
by 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.
Re: PIPE: issue
Posted: Wed Nov 02, 2022 10:13 pm
by 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
Re: PIPE: issue
Posted: Thu Nov 03, 2022 6:16 pm
by 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.
Re: PIPE: issue
Posted: Sat Nov 05, 2022 11:31 pm
by 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.
*
Re: PIPE: issue
Posted: Wed Nov 09, 2022 9:28 pm
by 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.
Re: PIPE: issue
Posted: Thu Nov 10, 2022 12:20 pm
by 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.
Re: PIPE: issue
Posted: Thu Nov 10, 2022 12:45 pm
by 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.
Re: PIPE: issue
Posted: Thu Nov 10, 2022 12:54 pm
by 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.