-
Notifications
You must be signed in to change notification settings - Fork 359
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
GMT_IN or GMT_IN|GMT_IS_REFERENCE for external vectors? #3515
Comments
As a general rule, all data that is allocated outside GMT must have in the corresponding dataset |
GMT_IS_REFERENCE means that GMT must treat what you pass as read-only and cannot modify or free. But I may have a look later (Sunday am is complicated by obligatory morning swim and 2 hour zoom with son) so will get to this in ~5 hours... I am surprised that we look for REFERENCE in the direction argument. |
Virtual file is created corectly, but when the file is passed to grdinfo and grdinfo calls GMT_Read_Data, the API object has had its family changed from GMT_IS_GRID to GMT_IS_DATASET and it is all downhill from there. Have not found out where family is reset to 0 (GMT_IS_DATASET) so will need to step through very carefully. |
Ping to draw @PaulWessel's attention to this issue. |
Surely this was fixed on the weekend. It had to do with not checking direction. Is this still a problem? |
Do you mean this PR #3514? I don't think it's related to this issue, and it's still failing for me. |
Well, if it crashes it does not matter what else I fixed. TO debug I need this C code to be in the repo. Is there a branch with this code? Needs to be bild with Xcode to be available to debug. |
Please work on this PR #3528. |
External programs like PyGMT can pass dataset/momory to GMT. By default, GMT can read, modify and free the momery, which sometimes can cause crashes. Issue #406 reports an example in which PyGMT crashes. The issue was reported to the upstream (see GenericMappingTools/gmt#3515 and GenericMappingTools/gmt#3528). It turns out to be a API user error (i.e., a PyGMT bug). As per the explanation of Paul, external programs like PyGMT should always use `GMT_IN|GMT_IS_REFERENCE` to tell GMT that the data is read-only, so that GMT won't try to change and free the memory. This PR makes the change from `GMT_IN` to `GMT_IN|GMT_IS_REFERENCE` in the `Session.open_virtual_file()` function, updates a few docstrings, and also adds the script in #406 as a test.
External programs like PyGMT can pass dataset/momory to GMT. By default, GMT can read, modify and free the momery, which sometimes can cause crashes. Issue #406 reports an example in which PyGMT crashes. The issue was reported to the upstream (see GenericMappingTools/gmt#3515 and GenericMappingTools/gmt#3528). It turns out to be a API user error (i.e., a PyGMT bug). As per the explanation of Paul, external programs like PyGMT should always use `GMT_IN|GMT_IS_REFERENCE` to tell GMT that the data is read-only, so that GMT won't try to change and free the memory. This PR makes the change from `GMT_IN` to `GMT_IN|GMT_IS_REFERENCE` in the `Session.open_virtual_file()` function, updates a few docstrings, and also adds the script in #406 as a test.
We have resolved this issue to use GMT_IN only, unless you are very sure passing the raw pointers will work (GMT_IN|GMT_IS_REFERENCE). |
The issue was first reported in GenericMappingTools/pygmt#406. The PyGMT script plots two vectors, and PyGMT crashes when plotting the second one.
Here is an equivalent C code, which mimics what PyGMT does.
The C code crashes at this line
gmt/src/gmt_vector.c
Line 415 in e5b54a4
However, if I change the parameter
GMT_IN
toGMT_IN|GMT_IS_REFERENCE
when callingGMT_Open_VirtualFile
, it works fine.Is it a bug in function
gmtvector_fix_up_path_cartesian
? What's the difference betweenGMT_IN
toGMT_IN|GMT_IS_REFERENCE
? Should PyGMT always usesGMT_IN|GMT_IS_REFERENCE
?The text was updated successfully, but these errors were encountered: