Segmentation Fault using gdal with Python 3

[Clifford Snow]

I'm getting a segmentation fault (core dump) when using the osgeo gdal
modules. Otherwise no problem.

I'm looking for some suggestions on how to troubleshoot this. I can't even
seem to find the core dump file.

For example, using the python interpreter with a simple program as:
> > > from osgeo import gdal
> > > quit()

Segmentation fault (core dumped)

I've reinstalled python3-gdal and gdal-python-tools with no help.

Thanks in advance,
Clifford

[Michael Hennebry]

On Thu, 27 May 2021, Clifford Snow wrote:
> I'm looking for some suggestions on how to troubleshoot this. I can't even
> seem to find the core dump file.

My guess is that there is not one.
ulimit -c
will probably tell you the your cose size limit is zero.

[Clifford Snow]

Michael,

On Thu, May 27, 2021 at 10:44 PM Michael Hennebry <
[e-mail]> wrote:
> On Thu, 27 May 2021, Clifford Snow wrote:
> > I'm looking for some suggestions on how to troubleshoot this. I can't
>
> even
> > seem to find the core dump file.
>
> My guess is that there is not one.
> ulimit -c
> will probably tell you the your cose size limit is zero.

ulimit -c reports unlimited

[Ed Greshko]

On 28/05/2021 13:46, Clifford Snow wrote:
> Michael,
>
> On Thu, May 27, 2021 at 10:44 PM Michael Hennebry <[e-mail] > wrote:
> On Thu, 27 May 2021, Clifford Snow wrote:
>
> > I'm looking for some suggestions on how to troubleshoot this. I can't even
> > seem to find the core dump file.
>
> My guess is that there is not one.
> ulimit -c
> will probably tell you the your cose size limit is zero.
>
>
> ulimit -c reports unlimited

does the output of coredumpctl show that a core dump exists?

If so, check /usr/lib/systemd/systemd-coredump for the corresponding dump file.

[Ed Greshko]

On 28/05/2021 14:07, Ed Greshko wrote:
> On 28/05/2021 13:46, Clifford Snow wrote:
> > Michael,
> >
> > On Thu, May 27, 2021 at 10:44 PM Michael Hennebry <[e-mail] > wrote:
> >
> > On Thu, 27 May 2021, Clifford Snow wrote:
> >
> > > I'm looking for some suggestions on how to troubleshoot this. I can't even
> >     > seem to find the core dump file.
> >
> > My guess is that there is not one.
> >     ulimit -c
> >     will probably tell you the your cose size limit is zero.
> >
> > ulimit -c reports unlimited
>
> does the output of coredumpctl show that a core dump exists?
>
> If so, check /usr/lib/systemd/systemd-coredump for the corresponding dump file.

Sorry, I meant check

/usr/lib/systemd/

For the file named what is called out in coredumpctl

[Ed Greshko]

On 28/05/2021 14:10, Ed Greshko wrote:
> On 28/05/2021 14:07, Ed Greshko wrote:
> > On 28/05/2021 13:46, Clifford Snow wrote:
> > > Michael,
> > >
> > > On Thu, May 27, 2021 at 10:44 PM Michael Hennebry <[e-mail] > wrote:
> > >
> > > On Thu, 27 May 2021, Clifford Snow wrote:
> > >
> > > > I'm looking for some suggestions on how to troubleshoot this. I can't even
> > >     > seem to find the core dump file.
> > >
> > > My guess is that there is not one.
> > >     ulimit -c
> > >     will probably tell you the your cose size limit is zero.
> > >
> > > ulimit -c reports unlimited
> >
> > does the output of coredumpctl show that a core dump exists?
> >
> > If so, check /usr/lib/systemd/systemd-coredump for the corresponding dump file.
>
> Sorry, I meant check
>
> /usr/lib/systemd/
>
> For the file named what is called out in coredumpctl

Oh CRAP.....  It is a *bad* afternoon.

The location would be....

/var/lib/systemd/coredump/

[George N. White III]

On Thu, 27 May 2021 at 23:37, Clifford Snow  wrote:
> I'm getting a segmentation fault (core dump) when using the osgeo gdal
> modules. Otherwise no problem.
>
> I'm looking for some suggestions on how to troubleshoot this. I can't even
> seem to find the core dump file.
>
> For example, using the python interpreter with a simple program as:
> > > > from osgeo import gdal
> > > > quit()
>
> Segmentation fault (core dumped)

You should show the complete output as in:
~% python3 ; echo $?
Python 3.9.5 (default, May 14 2021, 00:00:00)
[GCC 11.1.1 20210428 (Red Hat 11.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
> > > from osgeo import gdal
> > > quit()

0

I can't reproduce your problem on Fedora 33 or 34.   More details (Fedora
version,
python version) might help.  Is it possible you have old python packages
installed
in /usr/local or ~/.local?  Are you using a 3rd party python (Anaconda,
etc.)? Have
you tried "python3 -d -E -c 'from osgeo import gdal'?  Have you set
"PYTHONPATH"?

https://pythondev.readthedocs.io/debug_tools.html

[Clifford Snow]

Thanks everyone for their suggestions. I believe my problem is that I've
installed postgis from the postgresql PGDG repository and it's conflicting
with the Fedora python gdal files. Not sure If I need to just use Fedora's
postgresql version or if there is another workaround.

On Fri, May 28, 2021 at 4:18 AM George N. White III 
wrote:
> On Thu, 27 May 2021 at 23:37, Clifford Snow 
> wrote:
> > I'm getting a segmentation fault (core dump) when using the osgeo gdal
> > modules. Otherwise no problem.
> >
> > I'm looking for some suggestions on how to troubleshoot this. I can't
> > even seem to find the core dump file.
> >
> > For example, using the python interpreter with a simple program as:
> > > > > from osgeo import gdal
> > > > > quit()
> >
> > Segmentation fault (core dumped)
>
> You should show the complete output as in:
> ~% python3 ; echo $?
> Python 3.9.5 (default, May 14 2021, 00:00:00)
> [GCC 11.1.1 20210428 (Red Hat 11.1.1-1)] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> > > > from osgeo import gdal
> > > > quit()
>
> 0
>
> I can't reproduce your problem on Fedora 33 or 34.   More details (Fedora
> version,
> python version) might help.  Is it possible you have old python packages
> installed
> in /usr/local or ~/.local?  Are you using a 3rd party python (Anaconda,
> etc.)? Have
> you tried "python3 -d -E -c 'from osgeo import gdal'?  Have you set
> "PYTHONPATH"?
>
> https://pythondev.readthedocs.io/debug_tools.html
>
> --
> George N. White III
>
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

[George N. White III]

On Fri, 28 May 2021 at 17:22, Clifford Snow  wrote:
> Thanks everyone for their suggestions. I believe my problem is that I've
> installed postgis from the postgresql PGDG repository and it's conflicting
> with the Fedora python gdal files. Not sure If I need to just use Fedora's
> postgresql version or if there is another workaround.

You should report the problem to PGDG.   You may need to use python
environments or even
a separate Python install (Anaconda?) if fedora's gdal configuration
doesn't work for your use case.
In my field there is a "mission critical" application that hasn't moved
past Python 3.6 (due to testing
resource constraints, only 3.6 has been properly tested and is available to
the developers when
they need to duplicate a problem) so it is routine to have a Python 3.6
install just for that application.

Anaconda has activate/deactivate scripts, but you can also use
environment-modules or Lmod to
"enable" a specific python version.

environment-modules.x86_64 : Provides dynamic modification of a user's
environment
Lmod.x86_64 : Environmental Modules System in Lua