tusko wrote:In contrast with other hacks, here using the background sign "&" has problems. When loading only one module is not a problem, but it becomes one when loading more than one.
We should edit our posts to remove the "&" in the examples. It is plenty (look at the first page of this post).
Also, to prevent this injectso should detect if there is other instance of it running and the PID is already attached. Then, fail with an advice.
Global advice: When possible, run your hacks from a USB pen!! If something goes wrong you can unplug the device.
You are right with all your comments. However when looking into the logfile you can see two instances being started, but one of them fails:
Code: Select all
...
Module injector V1.2 for ARM based CPUs.
(copyleft) SmartSmurf 2010 (smartsmurf@shared-files.de)
Module injector V1.2 for ARM based CPUs.
(copyleft) SmartSmurf 2010 (smartsmurf@shared-files.de)
Error: ptrace_attachInfo: Import dlopen set at 0x00530d7c
Info: Import dlsym set at 0x00531244
Info: Import dlclose set at 0x00530f38
...
This is the result of the ptrace_attach() function:
Code: Select all
void ptrace_attach(int pid)
{
if ((ptrace(PTRACE_ATTACH, pid, NULL, NULL)) < 0) {
printf("Error: ptrace_attach");
exit(-1);
}
waitpid(pid, NULL, WUNTRACED);
}
So, finally only one injectso debugger process controls exeDSP. It is definitely a good advise to not use the background sign since you cannot predict which call to injectso will fail and which will succeed.
Yesterday I tried to reproduce the issue with a manually started script and 3 calls to injectso, but I could not kill exeDSP with it. That's why I am not sure, whether the "&" caused the problems or whether it is a matter of calling it too early. The bootlog entry "Application is started..." comes from rc.local before calling /mtd_exe/rc.local. But there is not any output from exeDSP. Maybe the injectso messes up with the dynamic loader while in the stage of loading exeDSP.
