gaia_rttopo_error_msg freed before malloc

[Aaron Farnham]

Hello,

I have compiled Spatialite 4.4.0-RC1 for iOS and encounter a crash (SIGABRT) when I call spatialite_cleanup_ex. It appears to be due to cache->gaia_rttopo_error_msg being freed in free_internal_cache in alloc_cache.c without having been allocated previously. 

Any idea how I can fix this?

For the record, Spatialite 4.4.0-RC0 works fine with iOS.

Thanks,

Aaron

[mj10777]

On Wednesday, 27 July 2016 16:39:24 UTC+2, Aaron Farnham wrote:

Hello,

I have compiled Spatialite 4.4.0-RC1 for iOS and encounter a crash (SIGABRT) when I call spatialite_cleanup_ex. It appears to be due to cache->gaia_rttopo_error_msg being freed in free_internal_cache in alloc_cache.c without having been allocated previously. 

Any idea how I can fix this?

On the fly, no.

When the structure it belongs too is being initialized, the pointer is set to NULL

- after every every free, it is also set to NULL

- free is done only after checking for NULL

Can you reproduce this error?

- with valgrind, it might be easier to find this

If you could create a sql-script that when called with 'spatialite some_new.db < some_sql.sql' and reproduces the error

- that will be helpful

(I assume you don't have vagrind)

Markl 

[mj10777]

On Wednesday, 27 July 2016 17:17:55 UTC+2, mj10777 wrote:

On Wednesday, 27 July 2016 16:39:24 UTC+2, Aaron Farnham wrote:

Hello,

I have compiled Spatialite 4.4.0-RC1 for iOS and encounter a crash (SIGABRT) when I call spatialite_cleanup_ex. It appears to be due to cache->gaia_rttopo_error_msg being freed in free_internal_cache in alloc_cache.c without having been allocated previously. 

Any idea how I can fix this?

On the fly, no.

When the structure it belongs too is being initialized, the pointer is set to NULL

- after every every free, it is also set to NULL

- free is done only after checking for NULL

Just checked the RC1 version of the source, no changes were made in this area

- everywhere where cache->gaia_rttopo_error_msg is dealt with, seems to be properly checked for (or set to) NULL

[Aaron Farnham]

On Wednesday, July 27, 2016 at 10:32:05 AM UTC-5, mj10777 wrote:

On Wednesday, 27 July 2016 17:17:55 UTC+2, mj10777 wrote:

On Wednesday, 27 July 2016 16:39:24 UTC+2, Aaron Farnham wrote:

Hello,

I have compiled Spatialite 4.4.0-RC1 for iOS and encounter a crash (SIGABRT) when I call spatialite_cleanup_ex. It appears to be due to cache->gaia_rttopo_error_msg being freed in free_internal_cache in alloc_cache.c without having been allocated previously. 

Any idea how I can fix this?

On the fly, no.

When the structure it belongs too is being initialized, the pointer is set to NULL

- after every every free, it is also set to NULL

- free is done only after checking for NULL

Just checked the RC1 version of the source, no changes were made in this area

- everywhere where cache->gaia_rttopo_error_msg is dealt with, seems to be properly checked for (or set to) NULL

I am using spatialite_alloc_connection() in src/connection_cache/alloc_cache.c to create the connection. I downloaded the source for RC1 and looked in that function and it appears neither gaia_rttopo_error_msg nor gaia_rttopo_warning_msg are set to NULL when the cache is allocated.

[mj10777]

On Thursday, 28 July 2016 18:01:04 UTC+2, Aaron Farnham wrote:

On Wednesday, July 27, 2016 at 10:32:05 AM UTC-5, mj10777 wrote:

On Wednesday, 27 July 2016 17:17:55 UTC+2, mj10777 wrote:

On Wednesday, 27 July 2016 16:39:24 UTC+2, Aaron Farnham wrote:

Hello,

I have compiled Spatialite 4.4.0-RC1 for iOS and encounter a crash (SIGABRT) when I call spatialite_cleanup_ex. It appears to be due to cache->gaia_rttopo_error_msg being freed in free_internal_cache in alloc_cache.c without having been allocated previously. 

Any idea how I can fix this?

On the fly, no.

When the structure it belongs too is being initialized, the pointer is set to NULL

- after every every free, it is also set to NULL

- free is done only after checking for NULL

Just checked the RC1 version of the source, no changes were made in this area

- everywhere where cache->gaia_rttopo_error_msg is dealt with, seems to be properly checked for (or set to) NULL

I am using spatialite_alloc_connection() in src/connection_cache/alloc_cache.c to create the connection. I downloaded the source for RC1 and looked in that function and it appears neither gaia_rttopo_error_msg nor gaia_rttopo_warning_msg are set to NULL when the cache is allocated.

 

Ok, I can see that

- add the 2 staments in between 

    cache->gaia_geosaux_error_msg = NULL;

    cache->silent_mode = 0;

-- as is done in 'spatialite_alloc_reentrant'

spatialite_alloc_reentrant

    cache->gaia_rttopo_error_msg = NULL;

    cache->gaia_rttopo_warning_msg = NULL;

 Mark

[Aaron Farnham]

I will give it a try tomorrow. Out of time for today.

Should I file a ticket against this?

Thanks for your help.

~Aaron

[mj10777]

On Thursday, 28 July 2016 18:17:28 UTC+2, Aaron Farnham wrote:

I will give it a try tomorrow. Out of time for today.

Should I file a ticket against this?

No, I will do that

- I will look more closely why 'spatialite_alloc_reentrant ()' is not being used

-- this is a 'do it once correctly and use everywhere' function so that such things don't happen

--> and it seems only being used when 'GEOS_REENTRANT' has been set

Mark

[Aaron Farnham]

For the record, I am compiling with the OMIT_GEOS option enabled.

~Aaron

--
You received this message because you are subscribed to a topic in the Google Groups "SpatiaLite Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/spatialite-users/HY6KYF1jHkQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to spatialite-use...@googlegroups.com.
To post to this group, send email to spatiali...@googlegroups.com.
Visit this group at https://groups.google.com/group/spatialite-users.
For more options, visit https://groups.google.com/d/optout.

This email message is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

[mj10777]

On Thursday, 28 July 2016 18:29:15 UTC+2, Aaron Farnham wrote:

For the record, I am compiling with the OMIT_GEOS option enabled.

Yes, I assumed that and since GEOS is almost always being set this problem has not turned up yet.

These structure are, normally, always initialized in a central function to avoid problems when the structure is changed

- this looks like a temporary solution during the development, that was forgotten 

[a.fu...@lqt.it]

On Thu, 28 Jul 2016 09:44:10 -0700 (PDT), 'mj10777' via SpatiaLite
Users wrote:
> On Thursday, 28 July 2016 18:29:15 UTC+2, Aaron Farnham wrote:
>
>> For the record, I am compiling with the OMIT_GEOS option enabled.
>
> Yes, I assumed that and since GEOS is almost always being set this
> problem has not turned up yet.
> These structure are, normally, always initialized in a central
> function to avoid problems when the structure is changed
> - this looks like a temporary solution during the development, that
> was forgotten 
>

Hi Aaron and Mark,

your analysis is correct; two pointers were badly left uninitialized
when disabling GEOS, and this caused a crash.
already fixed into the Fossil repository since the latest commit.

thanks for your collaboration,
Sandro