Opened 11 years ago
Closed 11 years ago
#411 closed defect (invalid)
rasgeo reports errors anddumps backtrace almost every time run
Reported by: | Marcus Sen | Owned by: | Dimitar Misev |
---|---|---|---|
Priority: | major | Milestone: | 8.4.4 |
Component: | rasgeo | Version: | 8.4 |
Keywords: | Cc: | ||
Complexity: | Medium |
Description
When I run rasgeo commands like rasimport and raserase I get errors like those shown below even though the commands seem to run correctly and do the requested insert or delete. I give 3 examples, one raserase command, one rasimport and one where I've deliberately made a mistake in the input syntax where there is still a backtrace although all it has to do is report the syntax error.
I am not sure whether this is a major or minor problem as the commands seem to be run correctly when I do them one at a time. I have had problems with some failing when I run several in succession from a shell script but I don't know whether this is related or a different problem. Also the error status makes it difficult to test for succesful running when executing from, for example, a python script.
I am using 8.4.3 RPMs
The example commands are below, the output is attached in 3 files named appropriately.
Example 1 - a collection previously inserted with rasimport using raserase:
$ raserase -conn ~/.rasdaman/rasconnect -coll test_mb8
Example 2 - Inserting a coverage using rasimport. Note that the nmrat_48641 table which the error message says already exists did not exist before executing the rasimport command but does after running it.
$ rasimport -conn ~/.rasdaman/rasconnect -f Landsat_205_20/landsat_205_20_stack.tif -coll test_mb8 -t x8CharImage:x8CharSet
Example 3 - Trying to execute a command with invalid syntax
$ raserase faierqae
Attachments (3)
Change History (6)
by , 11 years ago
Attachment: | example1_output.txt added |
---|
comment:1 by , 11 years ago
I noticed rasimport segmentation faults usually happen when using a GDAL version that is not the one against which rasdaman was compiled. Are you also using the packaged GDAL version from EOX maintained repository on the server?
comment:2 by , 11 years ago
I'm using gdal-1.9.0-1.eox2.el6.x86_64.
and rasdaman packages:
rasdaman-docs-8.4.3-1.el6.noarch
rasdaman-debuginfo-8.4.3-1.el6.x86_64
rasdaman-petascope-8.4.3-1.el6.noarch
rasdaman-8.4.3-1.el6.x86_64
rasdaman-examples-8.4.3-1.el6.noarch
rasdaman-devel-8.4.3-1.el6.x86_64
rasdaman-rasgeo-8.4.3-1.el6.x86_64
rasdaman-rasdaview-8.4.3-1.el6.x86_64
comment:3 by , 11 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
By setting up a new machine from scratch I found that I should have gdal-1.9.0-1.eox3.el6.x86_64 rather than gdal-1.9.0-1.eox2.el6.x86_64. This hadn't been showing up in my yum updates because my /etc/yum.repos.d.eox-testing file had an
includepkgs = rasdaman*
directive so it wasn't picking up gdal from this repository. I think some earlier instructions I had received had suggested to include this directive but I changed it to
includepkgs = rasdaman* gdal*
did yum update and got the eox3 package and now rasimport works fine.
Example 1 output