[gdal-dev] building gdal-3.3.0-dev with proj free(): invalid pointer
chris english
englishchristophera at gmail.com
Sun Mar 7 11:52:57 PST 2021
Hi.
Been building and rebuilding gdal-3.3.0-dev and arrive at this output:
chris at jacie:~$ gdalinfo --version
GDAL 3.3.0dev-96fab634a5, released 2021/03/02
free(): invalid pointer
Aborted
two version of libproj are involved:
chris at jacie:~$ ldd /usr/local/bin/gdalinfo | grep libproj
libproj.so.22 => /usr/local/lib/libproj.so.22 (0x00007f3a6cecc000)
libproj.so.19 => /usr/local/lib/libproj.so.19 (0x00007f3a659da000)
This is because when built with libproj.so.22 only, gdalinfo complained
libproj.so.19 couldn't be loaded on attempting to execute. libproj.so.22 is
in /usr/local and prjo.h is from libproj.so.22, also in /usr/local. 19 is
ln from /usr/local/lib.
in gdb I get:
gdb) set substitute-path /build/glibc-eX1tMB/glibc-2.31
/home/chris/glibc-2.31
(gdb) frame 1
#1 0x00007f8b2a4a3859 in __GI_abort () at abort.c:79
79 raise (SIGABRT);
(gdb) frame 2
#2 0x00007f8b2a50e3ee in __libc_message (action=action at entry=do_abort,
fmt=fmt at entry=0x7f8b2a638285 "%s\n") at
../sysdeps/posix/libc_fatal.c:155
155 abort ();
(gdb) frame 3
#3 0x00007f8b2a51647c in malloc_printerr (
str=str at entry=0x7f8b2a6364ae "free(): invalid pointer") at malloc.c:5347
5347 __libc_message (do_abort, "%s\n", str);
(gdb) frame 4
#4 0x00007f8b2a517cac in _int_free (av=<optimized out>, p=<optimized out>,
have_lock=0) at malloc.c:4173
4173 malloc_printerr ("free(): invalid pointer");
(gdb) frame 5
#5 0x00007f8b27035480 in __gnu_cxx::new_allocator<char>::deallocate (
this=0x557019391ff0, __p=<optimized out>)
at /usr/include/c++/9/ext/new_allocator.h:119
119 deallocate(pointer __p, size_type)
(gdb) frame 6
#6 std::allocator_traits<std::allocator<char> >::deallocate (__a=...,
__n=<optimized out>, __p=<optimized out>)
at /usr/include/c++/9/bits/alloc_traits.h:470
470 { __a.deallocate(__p, __n); }
(gdb) frame 7
#7 std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >::_M_destroy (__size=<optimized out>,
this=0x557019391ff0)
at /usr/include/c++/9/bits/basic_string.h:237
237 { _Alloc_traits::deallocate(_M_get_allocator(), _M_data(), __size
+ 1); }
(gdb) frame 8
#8 std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >::_M_dispose (this=0x557019391ff0)
at /usr/include/c++/9/bits/basic_string.h:232
232 _M_destroy(_M_allocated_capacity);
(gdb) frame 9
#9 std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >::~basic_string (this=0x557019391ff0,
__in_chrg=<optimized out>)
at /usr/include/c++/9/bits/basic_string.h:658
658 { _M_dispose(); }
(gdb) frame 10
#10 osgeo::proj::common::UnitOfMeasure::Private::~Private (
this=0x557019391ff0, __in_chrg=<optimized out>) at
iso19111/common.cpp:72
72 struct UnitOfMeasure::Private {
(gdb) frame 11
#11
std::default_delete<osgeo::proj::common::UnitOfMeasure::Private>::operator()
(this=0x7f8b272e1f60 <osgeo::proj::common::UnitOfMeasure::PPM_PER_YEAR+16>,
__ptr=0x557019391ff0) at /usr/include/c++/9/bits/unique_ptr.h:81
81 delete __ptr;
(gdb) frame 12
#12 std::unique_ptr<osgeo::proj::common::UnitOfMeasure::Private,
std::default_delete<osgeo::proj::common::UnitOfMeasure::Private>
>::~unique_ptr (
this=0x7f8b272e1f60
<osgeo::proj::common::UnitOfMeasure::PPM_PER_YEAR+16>,
__in_chrg=<optimized out>) at /usr/include/c++/9/bits/unique_ptr.h:292
292 get_deleter()(std::move(__ptr));
(gdb) frame 13
#13 osgeo::proj::common::UnitOfMeasure::~UnitOfMeasure (
this=0x7f8b272e1f50 <osgeo::proj::common::UnitOfMeasure::PPM_PER_YEAR>,
__in_chrg=<optimized out>) at ../include/proj/common.hpp:60
60 class PROJ_GCC_DLL UnitOfMeasure : public util::BaseObject {
(gdb) frame 14
#14 0x00007f8b2a4c815e in __cxa_finalize (d=0x7f8b1fdec720)
at cxa_finalize.c:83
83 cxafn (cxaarg, 0);
(gdb) frame 15
#15 0x00007f8b1fb399b7 in __do_global_dtors_aux ()
from /usr/local/lib/libproj.so.19
(gdb) frame 16
#16 0x00007ffe33879550 in ?? ()
(gdb) frame 17
#17 0x00007f8b2d55ef5b in _dl_fini () at dl-fini.c:138
138 ((fini_t) array[i]) ();
Haven't been able to further clarify frame 16 function call. Which I guess
would be useful. Any thoughts on how to proceed greatly appreciated.
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210307/3dad1ca1/attachment.html>
More information about the gdal-dev
mailing list