Correct way to stop path finding thread?

This is on behalf of Heinz2024.
Since he is a new user, he is unable to respond due to the limit on the number of posts.

This is post on Heinz2024 behalf.

I checked on a Goole Pixel7a.
It took 0.42ms to calculate the path for the longest one.
2024/03/25 21:08:58.465 3014 3251 Info Unity Path Completed: computation time: 0.42ms search nodes: 290 path length: 80 path cost: 215273
2024/03/25 21:08:58.465 3014 3251 Info Unity Path Number 244 (unique ID)
2024/03/25 21:08:58.465 3014 3251 Info Unity AstarPath:<.ctor>b__82_3(Path)
2024/03/25 21:08:58.465 3014 3251 Info Unity Pathfinding.PathProcessor:CalculatePathsThreaded(PathHandler, Receiver)
2024/03/25 21:08:58.465 3014 3251 Info Unity System.Threading.ExecutionContext:RunInternal(ExecutionContext, ContextCallback, Object, Boolean)

Thanks!

Are you building and testing for any other targets? E.g. IL2CPP on windows/mac standalone?

I’ve upped @Heinz2024’s trust level, so he should be able to post now.

Are you building and testing for any other targets? E.g. IL2CPP on windows/mac standalone?

No, we do not build on any other platforms. Our project is a smartphone app, so we do not build on any other platform.

I’ve upped @Heinz2024’s trust level, so he should be able to post now.

Thank you so much!

Would it be possible for you to see if you can replicate it using a windows standalone build? I believe android uses IL2CPP usually, so an IL2CPP windows build would be the closest.

I understand. I will give it a try.

1 Like

Thank you for your patience.

We have confirmed the build with Windows Standalone.
No error occurred.
The “script backend” is “Mono”.

Curious.

Would it be possible for you to try the following?

  1. Copy the com.arongranberg.astar package from your /Packages folder to the /Assets folder, to make it editable.
  2. Replace the BlockableChannel.cs script with this: using System.Diagnostics;using System.Threading;using Pathfinding.Util;usi - Pastebin.com
  3. Make an android build, observe the issue.
  4. Send me the player log file.

I understand. We are currently trying it out.
We will send you the log, but please understand that we will cut off the log if there are any confidentiality issues involved in its contents.

1 Like

Hmmm, I’m stumped.
The error no longer occurs.
It used to occur often before the modification…

I copied and pasted all the linked code in the BlockableChannel.cs modification, is this correct?

Sorry for not being able to help you.

Hmm. Likely the Debug.Log calls take so long that some other race conditions do not happen.

Try this one instead: using System.Diagnostics;using System.Threading;using Pathfinding.Util;usi - Pastebin.com

I’ve switched out all the Debug.Log calls with System.Console.WriteLine, which are a lot faster.

Understood.
It is almost midnight, so I will try tomorrow.

Thank you for your long consultation.
I will contact you again tomorrow.

1 Like

Dear, Mr. aron.

Thank you for yesterday.

System.Console.WriteLine did not output the log, so I made my own modifications to store the log in StringBuilder and output it all together before Close.
The logs have been uploaded.
Please take a look.

PlayerLog.txt (9.2 KB)

Hi

Thank you!
But are you sure you got all WriteLine calls? It looks like some are missing.
Also. Do you lock the StringBuilder before writing to it? The StringBuilder is not thread-safe, and there are a bunch of threads writing to it at the same time now.
Also, the logged timestamps looks really off… Not sure what’s going on there.

Ahh! I forgot to lock.
Some replacements may have leaked out of Console.WriteLine.
I’ll check again and try logging again.
And I’ll try to give the log a unique ID.
I have plans for today, so I’ll upload again tomorrow.

1 Like

Hi,

Thank you for your patience.
I have reacquired the log.
StringBuilder also used lock.
I checked the output log and the character output is cut off in the middle.
Perhaps it was interrupted as a result of the scene unloading being completed.
After deactivating all agents, I wait 5 seconds before unloading the scene…

I have cut out from the log anything that is not a Unity log, or anything that violates confidentiality.
Can you tell us anything from this log?

Also, the [1] in the log is a unique number that is numbered per PathProcessor.
Is there only one instance since only the log with number 1 is output?
PlayerLog.txt (2.5 KB)

Yes, there’s only 1 path processor.

Hmm, yeah that looks weird, with it being cut off like that. I also don’t see any of the log messages saying that it closed the queue. It just looks like it continued to calculate paths without even trying to stop…

That code is running in a separate thread, so it really shouldn’t.

I have tried to replicate this by running the package’s whole test suite on my android phone (pixel 6).
This test suite contains tests for reloading a scene many times.

However, I have not been able to replicate any kind of crash :confused:

What happens if you place a large number of agents on a trial basis?
For example, 2,000 agents.

In my project, 2,000 agents are constantly on patrol.
When they reach their destination, after a few seconds of waiting, they start moving again toward a new destination.
Thus, a large number of agents are constantly looking for routes.

If there are many agents, they should be implemented in ECS, but due to project constraints, they cannot be used. I am very sorry and sad.

Yeah. Or at least I scheduled 3000 paths in a single frame, and unloaded the scene the next frame (when only about 300-400 paths had been calculated). I also tried with varying number of threads from 0 to 7.