ptrace: Operation not permitted : warning: process xxxxx is already traced by process yyyyy

[rishi1906]

Out of blue I am getting following error upon executing SITL with JSBSIM

dumpstack.sh has been run. Output was:
-------------- begin dumpstack.sh output ----------------
warning: process 23968 is already traced by process 23882
ptrace: Operation not permitted.
/tmp/gdb.24102:2: Error in sourced command file:
No stack.
-------------- end dumpstack.sh output ----------------

Running: sh ../Tools/scripts/dumpcore.sh 23968 >dumpcore.sh_arduplane.23968.out 2>&1
dumpcore.sh has been run. Output was:
-------------- begin dumpcore.sh output ----------------
warning: process 23968 is already traced by process 23882
ptrace: Operation not permitted.
/tmp/gdb.24189:2: Error in sourced command file:
You can't do that without a process to debug.
-------------- end dumpcore.sh output ----------------

I have been trying to train RL agent using SITL + JSBSim Setup in Unreal Engine.
This is supposed to be the intermediate step in that direction.

@seanmcleod @agodemar
Could you help me resolve this issue.

[seanmcleod]

There is really no information with regards to JSBSim above that we can use to help debug. You would first need to modify your runtime environment so that you can actually get a stack trace of JSBSim, which would then give us some information to work with.

[rishi1906]

This is how stack trace of SITL looks like. I observed the aircraft move a bit and then this error occurred. I suppose its something to do with airspeed as evident from the call stack.

[rishi1906]

> `
> Thread 1 "arduplane" received signal SIGTRAP, Trace/breakpoint trap.
> AP_HAL::panic (errormsg=0x55555595ec37 "Should never be written to") at ../../libraries/AP_HAL_SITL/system.cpp:51
> 51	    for(;;);`

Found this in debug logs

[seanmcleod]

That all looks like Arduplane software.

[rishi1906]

Yes it is, this is the binding code for SITL. Arduplane SITL code calls JSBSIM through this procedure.

[seanmcleod]

Sure, but there is no JSBSim in the call stack, the crash isn't happening in JSBSim code, so it's difficult to see how we can really provide anything useful given the information provided.

Have you set a breakpoint in SITL::Airspeed_DLVR::rdwr() to see exactly what is happening? Has it even called into JSBSim yet to retrieve the airspeed before it crashes during this instance of the call that is crashing? Does it even call JSBSim code in this function? If so, what value is returned, and even if an invalid airspeed value was returned from JSBSim why would Arduplane's SITL code crash?

https://ardupilot.org/dev/docs/sitl-i2c-devices.html

SIM_Airspeed_DLVR is an example of an implementation of this sort of device, never allowing i2c writes to the device and always returning 4 bytes of data.

Note the AP_hal::panic() message you posted above:

Should never be written to

[rishi1906]

If clause at line no 8 turns out to be false.
I don't think JSBSim has been called yet at this moment.

From stack call, while setting up airspeed sensor in HAL (Hardware Abstraction Layer) source code, Arduplane SITL code is note able to simulate the sensor. BUT WHY?

[seanmcleod]

So Arduplane SITL is simulating the implementation of an I2C airspeed sensor by sending it I2C messages etc. and in this case it only supports read requests but for some reason some higher-level code is deciding to try and write to the I2C based airspeed sensor. So as I've been alluding to I really doubt this is a JSBSim specific issue and you would have better luck asking on the Arduplane development site.

If you set a breakpoint on line 8 you can then look at the stack trace to find the code higher up that is calling this function with a write request, and by inspecting that code and it's logic and taking a look at the state of the variables you may be able to figure out what is causing the issue.

[rishi1906]

This is how stack trace of SITL looks like. I observed the aircraft move a bit and then this error occurred. I suppose its something to do with airspeed as evident from the call stack.

Yes, you are right, its actually a Arduplane SITL code issue. This is the stack trace, which leads to line no 8. I am hardly able to get meaningful info from it. Anyways, thanks for helping me narrow down the issue.

I will put it up on ardupilot repo. Closing this discussion!

[rishi1906]

@seanmcleod Hey I solved the issue just now.
ARSPD_BUS 1
Used above parameter in param list to enforce it to attach to BUS1 of I2C bus where the airspeed sensor is connected.