#736 closed defect (fixed)
r.proj fails in wingrass
| Reported by: | cnielsen | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 6.4.0 |
| Component: | Raster | Version: | unspecified |
| Keywords: | r.proj, wingrass | Cc: | |
| CPU: | x86-32 | Platform: | MSWindows Vista |
Description
Reported in: http://www.mail-archive.com/grass-user@lists.osgeo.org/msg09983.html and http://n2.nabble.com/r-proj-exe-has-stopped-working-td3500149.html#a3500149
I tried this with latest standalone and osgeo4w versions with the same result. "r.proj.exe has stopped working". I also tried r.proj.old with the same result.
By adding a couple debug lines I found out it is crashing on line 280
pj_print_proj_params(&iproj, &oproj);
Not sure what this means but hopefully someone else does. g.proj -w works fine but it could still be a PROJ.4 issue.
-Colin
Change History (13)
comment:1 by , 15 years ago
| Keywords: | r.proj wingrass added |
|---|
comment:2 by , 15 years ago
follow-up: 4 comment:3 by , 15 years ago
Replying to cnielsen:
By adding a couple debug lines I found out it is crashing on line 280
> pj_print_proj_params(&iproj, &oproj);
pj_print_proj_params() uses G_free() to free a string returned from PROJ, where it should use pj_free().
follow-up: 5 comment:4 by , 15 years ago
Replying to jef:
pj_print_proj_params() uses G_free() to free a string returned from PROJ, where it should use pj_free().
Fixed in r38873 (7.0).
comment:5 by , 15 years ago
follow-up: 7 comment:6 by , 15 years ago
Not fixed yet. Same error comes up after update. It prints the "Input Projection Parameters" which is the line above the now pj_free, but hangs at pj_free line 405 of get_proj.c
follow-up: 8 comment:7 by , 15 years ago
Replying to cnielsen:
Not fixed yet. Same error comes up after update. It prints the "Input Projection Parameters" which is the line above the now pj_free, but hangs at pj_free line 405 of get_proj.c
Ouch. It's not pj_free(), it's pj_dalloc() (just like in #537). Sorry.
comment:8 by , 15 years ago
follow-up: 10 comment:9 by , 15 years ago
jef:
Ouch. It's not pj_free(), it's pj_dalloc()
so, does the patch test out ok & shall we commit it?
Index: lib/proj/get_proj.c
===================================================================
--- lib/proj/get_proj.c (revision 38897)
+++ lib/proj/get_proj.c (working copy)
@@ -402,7 +402,7 @@
if (str != NULL) {
fprintf(stderr, "%s: %s\n", _("Input Projection Parameters"),
str);
- pj_free(str);
+ pj_dalloc(str);
fprintf(stderr, "%s: %.16g\n", _("Input Unit Factor"),
iproj->meters);
}
@@ -415,7 +415,7 @@
if (str != NULL) {
fprintf(stderr, "%s: %s\n", _("Output Projection Parameters"),
str);
- pj_free(str);
+ pj_dalloc(str);
fprintf(stderr, "%s: %.16g\n", _("Output Unit Factor"),
oproj->meters);
}
thanks, Hamish
comment:10 by , 15 years ago
Replying to hamish:
Ouch. It's not pj_free(), it's pj_dalloc()
Ouch. I can't be the only person to have been tripped up by that one.
Any chance of getting the PROJ developers to rename pj_free() to e.g. pj_free_proj()?
so, does the patch test out ok & shall we commit it?
Yes.
follow-up: 13 comment:12 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Ok guys, patch submitted on all branches. Thanks!
Glynn:
Ouch. I can't be the only person to have been tripped up by that one. Any chance of getting the PROJ developers to rename pj_free() to e.g. pj_free_proj()?
I think you'll have to take that up with them directly.
Hamish
ps- I still would like to learn a bit more about how to deal with there errors which Valgrind finds; leaving them there but ignoring them seems like an unscratched itch. Currently I can make the reports but it's frustrating having done that not knowing what to do next.
comment:13 by , 15 years ago
Replying to hamish:
ps- I still would like to learn a bit more about how to deal with there errors which Valgrind finds; leaving them there but ignoring them seems like an unscratched itch. Currently I can make the reports but it's frustrating having done that not knowing what to do next.
Without reviewing the valgrind log in detail, I'd just expect memory leaks. Those just waste memory and are otherwise harmless, unless you run out of memory because of them.
It didn't point to the crash. Actually it can't as there isn't any problem valgrind could detect, because on Unix there isn't any. On Unix the runtime library (aka libc) provides malloc() and free() and deals with memory management for the whole process - including shared libraries.
On Windows OTOH each DLL can have it's own runtime library and each call to malloc() must be matched with a call to free() from the same library.
Therefore each DLL provides a function to free allocated memory they return, that simply calls free(), but from the runtime library they use - eg. pj_dalloc() for PROJ, CPLFree() for GDAL/OGR and G_free() for GRASS).
Still you won't run into problems if you compile everything using the same runtime library, eg. one version of MinGW.
On Unix one could also call any of those or free() directly, without causing problems. But one still shouldn't as the functions might do more than just free() in the future. That's also why I'd consider those issues bugs even on Unix.
As is the case once again with these wingrass bugs, valgrind finds some memory errors which are apparently benign on UNIX.
setup:
#get&set region spearfish> g.region -dbg # #create and enter a LL/WGS84 location ll_wgs84> g.region n=44.50173527 s=44.37032007 \ w=-103.87110972 e=-103.62942673 res=0:00:01 -ap ll_wgs84> CMD="r.proj in=elevation.dem loc=spearfish60 mapset=PERMANENT" ll_wgs84> valgrind --tool=memcheck --leak-check=yes --show-reachable=yes $CMDresult: (GRASS 6.5svn on Debian/Etch 32bit i686 linux)
Hamish