You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
LTOBD2Adapter: Race Condition in Command Queue Access #22
Tested this in debug and _commandQueue is between 1 and 6 after adding commands.
i dont know why it can go up to 7000.
And why it is possible to get this Error: index beyond bounds
i will try it with this solution:
if ( [_commandQueue count] > 200 )
{
NSLog( @"cancelPendingCommands : Has more than 200" );
[self cancelPendingCommands];
}
Thanks for this report. The actual problem looks like a multithreading race condition – I should check whether access of the command queue is a) coordinated or b) make the command queue thread-safe.
That said, if you're checking values in a loop, you have to take care that you're not adding commands faster than they are handled, so instead of adding based on a timer it would be better to use the completion handler to schedule the next iteration.
Last but not least, there are several optimizations that I want to tackle in 2019, namely adding facilities to group multiple PID queries (in order to save bandwidth), and also something to ease repeating queries.
changed the title [-]Error: sometimes i got a crash in LTOBD2Adapter.m NSRangeException beyond bounds[/-][+]LTOBD2Adapter: Race Condition in Command Queue Access[/+]on Dec 21, 2018
Activity
Skyb0rg commentedon Dec 20, 2018
Tested this in debug and _commandQueue is between 1 and 6 after adding commands.
i dont know why it can go up to 7000.
And why it is possible to get this Error: index beyond bounds
i will try it with this solution:
after: asyncProcessCommandQueue
mickeyl commentedon Dec 21, 2018
Thanks for this report. The actual problem looks like a multithreading race condition – I should check whether access of the command queue is a) coordinated or b) make the command queue thread-safe.
That said, if you're checking values in a loop, you have to take care that you're not adding commands faster than they are handled, so instead of adding based on a timer it would be better to use the completion handler to schedule the next iteration.
Last but not least, there are several optimizations that I want to tackle in 2019, namely adding facilities to group multiple PID queries (in order to save bandwidth), and also something to ease repeating queries.
[-]Error: sometimes i got a crash in LTOBD2Adapter.m NSRangeException beyond bounds[/-][+]LTOBD2Adapter: Race Condition in Command Queue Access[/+]Skyb0rg commentedon Dec 22, 2018
created an outlet for the queue count and slow down the new requests if needed.
for me its currently ok.
Thank you for detailed answer 👍
Skyb0rg commentedon Jan 3, 2019
Have you any idea how to fix this ?
Yesterday it was 0...4 [index 6 beyond bounds]
I start the "transmitMultipleCommands" function in the main queue but it doesn´t help.
Skyb0rg commentedon Feb 1, 2019
This Error only happens all >50.000 readings so its hard to find the error but i think this might be help.
Skyb0rg commentedon Feb 15, 2019
@synchronized(self) is not the solution.
Now i test with the serial dispatchqueue.
Skyb0rg commentedon Mar 15, 2019
created pull request for the solution. #26