-
-
Notifications
You must be signed in to change notification settings - Fork 1
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
C stack usage is too close to the limit when loading a LAScatalog #6
Labels
Comments
Jean-Romain
added
multithreading
Parallel processing
bug
Something isn't working
labels
Feb 22, 2024
Jean-Romain
changed the title
C stack usage is too close to the limit with multithreading when loading a LAScatalog
C stack usage is too close to the limit when loading a LAScatalog
Feb 27, 2024
Jean-Romain
added a commit
that referenced
this issue
Mar 5, 2024
Jean-Romain
added a commit
that referenced
this issue
Mar 22, 2024
* encapsulation and const * Separate implementation progress bar * multi file parallelism * add clone method * Create raster file before to process the point cloud * Create vector file before to process the point cloud * shared pointer to gdaldataset * Thread safe error handling * mutlithread raster * connected algorithms stored in a map * A lot of things are working... * Fix clone of LASfilter * precompute nmetrics * A lot of change * Critical aggregate * parallel noise * Thread safe print * thread safe stages * hread safe progress * -- * Callback merge * writelas * virtual is_parallelizable * Thread safe copy constructor * Fix * finalize multi-thread * Documentation * passes test removed in #6 * Change user API * Thread safe progress bar * error context * print error context * omp set max active level * Thread safe call to R C API * Fully thread safe callback * Ready for nested parallism * Fix data race * is_parallized * change multithreading api + nested * Fix unit tests strategy applied * Fix callback merging * Temporarily ignore test * Order preserving multi-threading * Temporary workaround for #6 * -- * Fix nmetrics evaluation * Get rid of useless warning * set_parallel_strategy * Benchmarks * Benchmarks * Multi-threading article. * Add clone method * OpenMP stuff * Note about macos * New benchmarks * Update benchmarks * man * Update benchmarks * Remove messages * vendor json parser * coverage * v0.4.0 * Rinterface.h is missing on windows * test multithreading with gh-actions * R_CStackLimit + tests * Import R_CStackLimit from DLL for windows Test * Try with STRICT_R_HEADERS * Remove windows.h * fix test on mac ? * Skip test on mac OS * Fixed conditionnal jump on unitialized value * dump * Wrap query in critical section * Dynamic scheduling * Fix #8 * Order preserving output file * remove order preserving code for static scheduling * Fix ordering * Order callback * No critical section * set_exec_options * skip test if no omp support * remove print * Fix no omp support * - * Fix verbose * new
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
In the
multithreading
development branch there is one unit test that is failling for very weird reasons. If aLAScatalog
fromlidR
is loaded it crashes the session withErreur : C stack usage is too close to the limit
. This typically comes from conccurent call to R's C API but here no call to R's C API is used.Removing
las = lidR::readLAScatalog(LASfile)
it works.After investigations, it fails because
lidR::is.overlapping()
is called internally. Using a modified version that does not calllidR::is.overlapping()
it works. After more investigation and using a modified version withoutis.overlapping()
it can still fail usingBut
does work !!
After even more investigations the error is called into the vector writer by
polygon.IsValid()
. Removing this line it works despite it has 0 relationship with aLAScatalog
not even used.lasR/src/LASR/Vector.cpp
Line 257 in b5d0898
I was also able to reproduce loading
testthat
but it was inconsistent.The text was updated successfully, but these errors were encountered: