[Qgis-developer] Fwd: Re: [gdal-dev] ogr2ogr segfault
a.furieri at lqt.it
a.furieri at lqt.it
Tue May 19 07:40:34 PDT 2015
On Tue, 19 May 2015 13:06:45 +0200, Paolo Cavallini wrote:
> Hi all.
> Does this imply we have to change the qgis provider for SL?
>
certainly yes: any C/C++ sw component directly linking libspatialite
is expected to urgently switch from the deprecated spatialite_init()
to the new thread safe approach based on spatialite_alloc_connection(),
spatialite_init_ex() and spatialite_cleanup()
a perfectly equivalent approach could be the one based on dynamically
loading the "mod_spatialite" extension module on the top of libsqlite
thus definitely removing any direct linkage between the application
and spatialite itself.
this second approach is universal and is absolutely language agnostic
(and is fully thread safe as well).
the calling app simply has to execute the following SQL query on behalf
of any SQLite connection requiring SpatiaLite support:
SELECT load_extension( 'mod_spatialite' );
this is the way usually adopted by Java/JDBC, Python, PHP, C# .NET
(and many others), and there are many pros in this approach:
- the external dynamic module will silently take care of any required
initialization and finalization step.
- any external dependency from libspatialite headers and binaries
will completely disappear, because this one simply is a pure SQL
extension mechanism and is completely invisible at C/C++ level.
- the app and the module will be mutually independent; if you wish
to upgrade SpatiaLite to a more recent version you simply have
to replace mod_spatialite (and its related dependencies) and
that's all.
- there is an obvious con: if for any reason the dynamic extension
module will fail to load you'll probably experience an unexpected
fatal failure directly at run time.
and this explains why many C/C++ apps still continue to support
the standard approach based on direct linking.
the classic C/C++ initialization method based on direct linkage
now works as follows:
Connection:
----------------------
c1. get a valid SQLite handle by calling sqlite3_open_v2()
c2. allocate a spatialite's internal opaque object by calling
spatialite_alloc_connection()
the handle pointing to this opaque object must be preserved
during all the connection's lifetime.
c3. then you can initialize SpatiaLite on that connection by
calling spatialite_init_ex(sqlite_handle, opaque_internal_handle)
Termination:
---------------------
t1. you should first invoke sqlite3_close() as usual.
t2. and immediately after you should finalize the internal opaque
object by calling spatialite_cleanup()
[you are obviously expected to pass to this API exactly the
same pointer returned by the previous call to
spatialite_alloc_connection() for the corresponding connection]
all this nicely fits into a typical C++ class supporting Open()
and Close() methods; and in this case the internal opaque pointer
will simply be a private class member.
from a quick glance at the QGIS sources I notice that there are
many calls to sqlite3_open(), sqlite3_close() and spatialite_init()
dispersed here and there within the code of both e.g.
qgsspatialiteconnection.cpp and qgsspatialiteprovider.cpp
a preliminary reordering work mainly focused on centralizing
all Open() and Close() operations in a single C++ class will
presumably made the transition to the new spatialite_init_ex()
model absolutely painless.
bye Sandro
>
>
> -------- Messaggio Inoltrato --------
> Return-Path: <gdal-dev-bounces at lists.osgeo.org>
> X-Original-To: cavallini at faunalia.it
> Delivered-To: paolo at paguma.faunalia.it
> Received: from localhost (localhost [127.0.0.1]) by
> paguma.faunalia.it
> (Postfix) with ESMTP id F1B49108AC1B for <cavallini at faunalia.it>;
> Tue,
> 19 May 2015 12:57:04 +0200 (CEST)
> Received: from paguma.faunalia.it ([127.0.0.1]) by localhost
> (paguma.faunalia.it [127.0.0.1]) (amavisd-new, port 10024) with LMTP
> id
> nHoMM_r_bo0O for <cavallini at faunalia.it>; Tue, 19 May 2015 12:57:02
> +0200 (CEST)
> Received: from lists.osgeo.org (mail.osgeo.osuosl.org
> [140.211.15.134])
> by paguma.faunalia.it (Postfix) with ESMTP id 6EB9A1082394 for
> <cavallini at faunalia.it>; Tue, 19 May 2015 12:57:01 +0200 (CEST)
> Received: from ash.osuosl.org (localhost [127.0.0.1]) by
> lists.osgeo.org
> (Postfix) with ESMTP id 1296D8661; Tue, 19 May 2015 03:56:50 -0700
> (PDT)
> Received: from mta.ntc.it (mta.ntc.it [212.83.162.48]) by
> lists.osgeo.org (Postfix) with ESMTP id B4D658203 for
> <gdal-dev at lists.osgeo.org>; Tue, 19 May 2015 03:56:48 -0700 (PDT)
> Received: from mail.lqt.it (mta.ntc.it [212.83.162.48])
> (Authenticated
> sender: a.furieri at lqt.it) by mta.ntc.it (Postfix) with ESMTPA id
> 902D110785B for <gdal-dev at lists.osgeo.org>; Tue, 19 May 2015 12:56:44
> +0200 (CEST)
> MIME-Version: 1.0
> Date: Tue, 19 May 2015 12:56:44 +0200
> From: a.furieri at lqt.it
> To: gdal-dev at lists.osgeo.org
> In-Reply-To: <201505191125.27414.even.rouault at spatialys.com>
> References: <555AFA50.60400 at faunalia.it>
> <201505191105.11611.even.rouault at spatialys.com>
> <555B0143.3080308 at gmail.com>
> <201505191125.27414.even.rouault at spatialys.com>
> Message-ID: <379e198fa5be25188cb0a65d5014ba27 at lqt.it>
> X-Sender: a.furieri at lqt.it
> User-Agent: Roundcube Webmail/0.5.3
> X-Netcom-MailScanner-Information: Please contact the ISP for more
> information
> X-Netcom-MailScanner-ID: 902D110785B.A7CE8
> X-Netcom-MailScanner: Found to be clean
> X-Netcom-MailScanner-From: a.furieri at lqt.it
> Subject: Re: [gdal-dev] ogr2ogr segfault
> X-BeenThere: gdal-dev at lists.osgeo.org
> X-Mailman-Version: 2.1.13
> Precedence: list
> List-Id: "Discussion for developers using and building GDAL/OGR."
> <gdal-dev.lists.osgeo.org>
> List-Unsubscribe: <http://lists.osgeo.org/mailman/options/gdal-dev>,
> <mailto:gdal-dev-request at lists.osgeo.org?subject=unsubscribe>
> List-Archive: <http://lists.osgeo.org/pipermail/gdal-dev>
> List-Post: <mailto:gdal-dev at lists.osgeo.org>
> List-Help: <mailto:gdal-dev-request at lists.osgeo.org?subject=help>
> List-Subscribe: <http://lists.osgeo.org/mailman/listinfo/gdal-dev>,
> <mailto:gdal-dev-request at lists.osgeo.org?subject=subscribe>
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain; charset="us-ascii"; Format="flowed"
> Sender: gdal-dev-bounces at lists.osgeo.org
> Errors-To: gdal-dev-bounces at lists.osgeo.org
>
> On Tue, 19 May 2015 11:25:27 +0200, Even Rouault wrote:
>> Debian Sid, might be a platform specific issue?
>> https://bugs.debian.org/785091
>>
>
> few technical details useful to understand better:
>
> a) starting since November 2013 it become definitely clear
> that the older self-registration mechanism based on the
> spatialite_init() API was intrinsically thread unsafe
> and could potentially have very bad interactions with
> the more recent versions of both PROJ.4 and GEOS
>
> b) consequently a public announcement [1] was duly released
> warning about the deprecation of spatialite_init()
> and soliciting developers and maintainers to start
> supporting the alternative thread safe mechanism based
> on spatialite_alloc_connection(), spatialite_init_ex()
> and spatialite_cleanup() APIs.
>
> c) all recent versions of libspatialite, spatialite-tools
> and spatialite_gui are now expected to be fully thread
> safe: and AFAIK the same is for recent versions of GDAL.
> any obsolete version still based on the nowadays deprecated
> spatialite_init() API is potentially at risk when deployed
> in a multithread configuration.
>
> OTH Sandro
>
> [1]
>
> https://groups.google.com/forum/#!searchin/spatialite-users/spatialite_init_ex/spatialite-users/83SOajOJ2JU/sgi5fuYAVVkJ
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
More information about the Qgis-developer
mailing list