-
-
Notifications
You must be signed in to change notification settings - Fork 364
v.decimate: Added tests #6152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
v.decimate: Added tests #6152
Conversation
The tests is running fine on my machine. I am using a Linux distro. More specifically WSL2 on Windows. However it fails in the MACOS and Windows test here. Could someone help me with this? |
On macOS I'm not sure what the cause is from the trace. On Windows there's a clue about threading and lock. So, I assume there's something to do with multiprocessing. On Linux, if you use Python 3.14 rc1 (that means it is binary compatible and projects are encouraged to start building wheels), they should be using the same start mechanisms that are used on macOS and Windows (safer, but sometimes code needs to be adjusted). I didn't find something that was problematic in the new code, so maybe take a look at the tool implementation (if it is written in Python). So, if you're able to use Python 3.14 on Linux, and it fails the same way, and you manage to fix it on Linux, there's a big chance that it will be fixed on both other platforms. |
I was initially using python 3.10. I install python 3.14 rc1. The tests are still running fine with this version as well. |
v.decimate is in C, but the v.decimate process exits with 3221225477 (0xC0000005) on Windows which is some kind of system error (I can't find official doc for that). macOS ends with an error coming from GRASS, "No attribute table for layer 1". That's specifically from v.decimate which for some reason expects attribute table, but does not find one. Finally, Linux works. This may indicate error in v.decimate code, but Coverity Scan and GitHub CodeQL do not should anything. Running the tool with Valgrind would be my next step. For the tests, I suggest to remove the problematic test from this PR to merge what works and open a new PR only with the failing test afterwards. |
No description provided.