[GRASS5] Segfault of v.in.ogr with OGR-layer

Dear List,

I am trying to import an ogr-Datasource into GRASS using v.in.ogr.

The following error appears:
(gdb) r dsn=OCI:user/pw@oracle.galileo out=a layer=SPEAR_SOILS
Starting
program: /home/holl/cvs/grass_HEAD/dist.i686-pc-linux-gnu/bin/v.in.ogr
dsn=OCI:user/pw@oracle.galileo out=a layer=SPEAR_SOILS [Thread
debugging using libthread_db enabled] [New Thread -1234180384 (LWP
21724)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1234180384 (LWP 21724)]
0xb79031b0 in strcmp () from /lib/tls/libc.so.6
(gdb) bt
#0 0xb79031b0 in strcmp () from /lib/tls/libc.so.6
#1 0xb7a254f2 in G_find_key_value (key=0x0, kv=0x817d1b0) at
key_value1.c:107 #2 0xb7a25907 in G_lookup_key_value_from_file
(file=0x0, key=0x0, value=0xbfdc1600 "", n=80) at key_value4.c:49 #3
0xb7aefdf1 in GPJ_osr_to_grass (cellhd=0xbfdc1650, projinfo=0xbfdc27c8,
projunits=0xbfdc27cc, hSRS=0x81517b0, interactive=0) at convert.c:352
#4 0x0804d4e8 in main (argc=0, argv=0xbfdc5da4) at main.c:384

I received this on a fresh CVS-HEAD-Checkout of today.

When I do this with the ogr2ogr-tool I can access the datasource fine,
everything works. But GRASS does not :frowning:

Perhaps anybody could give me some pointers where I should dig deeper?

A bt full backtrace from gdb is provided here[1] (longish).

Thanks in advance

  Stephan

[1] http://www.gdf-hannover.de/holl/tmp/grass_bt_full_2006-02-22.txt

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

Hello list,

On Wed, 22 Feb 2006 17:00:36 +0100 Stephan Holl <holl@gdf-hannover.de>
wrote:

Dear List,

I am trying to import an ogr-Datasource into GRASS using v.in.ogr.

The following error appears:
(gdb) r dsn=OCI:user/pw@oracle.galileo out=a layer=SPEAR_SOILS
Starting
program: /home/holl/cvs/grass_HEAD/dist.i686-pc-linux-gnu/bin/v.in.ogr
dsn=OCI:user/pw@oracle.galileo out=a layer=SPEAR_SOILS [Thread
debugging using libthread_db enabled] [New Thread -1234180384 (LWP
21724)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1234180384 (LWP 21724)]
0xb79031b0 in strcmp () from /lib/tls/libc.so.6
(gdb) bt
#0 0xb79031b0 in strcmp () from /lib/tls/libc.so.6
#1 0xb7a254f2 in G_find_key_value (key=0x0, kv=0x817d1b0) at
key_value1.c:107 #2 0xb7a25907 in G_lookup_key_value_from_file
(file=0x0, key=0x0, value=0xbfdc1600 "", n=80) at key_value4.c:49 #3
0xb7aefdf1 in GPJ_osr_to_grass (cellhd=0xbfdc1650,
projinfo=0xbfdc27c8, projunits=0xbfdc27cc, hSRS=0x81517b0,
interactive=0) at convert.c:352 #4 0x0804d4e8 in main (argc=0,
argv=0xbfdc5da4) at main.c:384

I received this on a fresh CVS-HEAD-Checkout of today.

When I do this with the ogr2ogr-tool I can access the datasource fine,
everything works. But GRASS does not :frowning:

Perhaps anybody could give me some pointers where I should dig deeper?

A bt full backtrace from gdb is provided here[1] (longish).

Thanks in advance

  Stephan

[1] http://www.gdf-hannover.de/holl/tmp/grass_bt_full_2006-02-22.txt

As I have not received any answers on this (the problem is still
present) I would like to ask again for some pointers where to start
looking for the problem.

It seems to be a GRASS-related problem, since I a can use ogr2ogr fine
with both Postgres and Oracle...

But v.in.ogr still fails with a seg fault.

Thank you for pointing to a starting point

Best
  Stephan

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

Hello list,

For completeness of my own thread :slight_smile:

the problem of this segfault was a missing environment-variable
ORACLE_HOME which was needed by gdal when compiled against the Oracle
OCI 9i interface.

Exporting the variable and writing this into e.g. ~/.bashrc solved the
problem permanently.

echo "export ORACLE_HOME=/some/path/OraHome" >> ~/.bashrc

Best
  Stephan

On Mon, 27 Feb 2006 11:50:15 +0100 Stephan Holl
<holl@gdf-hannover.de> wrote:

Hello list,

On Wed, 22 Feb 2006 17:00:36 +0100 Stephan Holl <holl@gdf-hannover.de>
wrote:

> Dear List,
>
> I am trying to import an ogr-Datasource into GRASS using v.in.ogr.
>
> The following error appears:
> (gdb) r dsn=OCI:user/pw@oracle.galileo out=a layer=SPEAR_SOILS
> Starting
> program: /home/holl/cvs/grass_HEAD/dist.i686-pc-linux-gnu/bin/v.in.ogr
> dsn=OCI:user/pw@oracle.galileo out=a layer=SPEAR_SOILS [Thread
> debugging using libthread_db enabled] [New Thread -1234180384 (LWP
> 21724)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1234180384 (LWP 21724)]
> 0xb79031b0 in strcmp () from /lib/tls/libc.so.6
> (gdb) bt
> #0 0xb79031b0 in strcmp () from /lib/tls/libc.so.6
> #1 0xb7a254f2 in G_find_key_value (key=0x0, kv=0x817d1b0) at
> key_value1.c:107 #2 0xb7a25907 in G_lookup_key_value_from_file
> (file=0x0, key=0x0, value=0xbfdc1600 "", n=80) at key_value4.c:49 #3
> 0xb7aefdf1 in GPJ_osr_to_grass (cellhd=0xbfdc1650,
> projinfo=0xbfdc27c8, projunits=0xbfdc27cc, hSRS=0x81517b0,
> interactive=0) at convert.c:352 #4 0x0804d4e8 in main (argc=0,
> argv=0xbfdc5da4) at main.c:384
>
> I received this on a fresh CVS-HEAD-Checkout of today.
>
> When I do this with the ogr2ogr-tool I can access the datasource
> fine, everything works. But GRASS does not :frowning:
>
> Perhaps anybody could give me some pointers where I should dig
> deeper?
>
> A bt full backtrace from gdb is provided here[1] (longish).
>
> Thanks in advance
>
> Stephan
>
> [1] http://www.gdf-hannover.de/holl/tmp/grass_bt_full_2006-02-22.txt

As I have not received any answers on this (the problem is still
present) I would like to ask again for some pointers where to start
looking for the problem.

It seems to be a GRASS-related problem, since I a can use ogr2ogr fine
with both Postgres and Oracle...

But v.in.ogr still fails with a seg fault.

Thank you for pointing to a starting point

Best
  Stephan

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508