GNU Astronomy Utilities - Tasks: task #14572, Protect gal_data_t's array and...
You are not allowed to post comments on this tracker with your current authentication level.
task #14572: Protect gal_data_t's array and block pointers
Submitter: | Mohammad Akhlaghi <makhlaghi> | ||
Submitted: | Sun 25 Jun 2017 06:13:50 PM UTC | ||
Should Start On: | Sat 24 Jun 2017 10:00:00 PM UTC | Should be Finished on: | Sat 24 Jun 2017 10:00:00 PM UTC |
Category: | Libraries | Priority: | 5 - Normal |
Item Group: | Enhancement | Status: | Postponed |
Privacy: | Public | Assigned to: | None |
Percent Complete: | 0% | Open/Closed: | Open |
Effort: | 0.00 |
Fri 14 Jul 2017 04:21:31 PM UTC, comment #5: |
Antonio Diaz Diaz <antonio> |
Wed 28 Jun 2017 04:05:33 PM UTC, comment #4: Thank you for the extra explanation Antonio. Unfortunately I am still a little confused. I completely agree with defining `gal_data_t' as an opaque structure and only access it through functions. I just don't understand the significance of the "subtile" (or "subarray") concept. Is it a new concept, or just a re-naming of the existing ones? Let me explain:
|
Mohammad Akhlaghi <makhlaghi> |
Wed 28 Jun 2017 02:57:55 PM UTC, comment #3: A 'subtile' is just a 'struct gal_data_t' initialized by 'gal_data_initialize' with a non-NULL pointer as 'array' (the larger parent array). My suggestion is to just wrap the gal_data_t's block concept (working with only a subset of the data) in a set of handling functions that guarantee that the 'array' and 'block' pointers are managed as documented in lib/gnuastro/data.h.
|
Antonio Diaz Diaz <antonio> |
Tue 27 Jun 2017 10:35:55 PM UTC, comment #2: Thank you very much Antonio for this interesting suggestion.
|
Mohammad Akhlaghi <makhlaghi> |
Tue 27 Jun 2017 08:59:08 PM UTC, comment #1: Maybe you could implement the feature the other way. Instead of a 'block' pointer pointing to the larger array, you may implement an array of subtiles in (the opaque) 'gal_data_t'. This also allows arbitrary levels of tessellation, or mapping one particular region over several tiles, but makes it easier to keep tile->array and tile->block in sync and avoid use-after-free errors. The interface to the subtile array could be something like this:
|
Antonio Diaz Diaz <antonio> |
Sun 25 Jun 2017 06:13:50 PM UTC, original submission:
Gnuastro's generic data container (`gal_data_t') has two pointers that give information about the region of memory it is related to: `tile' and `block' (see the manual).
|
Mohammad Akhlaghi <makhlaghi> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Powered by Savane 3.13-02a9.
Corresponding source code
After reading the Gnuastro manual for a while, if I have undertood it correctly, Gnuastro has two uses for gal_data_t objects; datasets and tiles. The reason to use the same data type for both is to be able to implement arbitrary tiling (two-layer tessellation, for example) without special cases (without the first-level tiles pointing to a dataset, and N-level tiles pointing to tiles of level N - 1).
My first idea to avoid dangling pointers under these circumstances is to implement a reference counter in gal_data_t. Every time a new tile is created (by one of the handling functions), the reference counter of its underlying gal_data_t is increased. And every time a tile is freed, its own reference counter is verified to be 0 and then the reference counter of its underlying gal_data_t is decreased.
Also when a tile is reassigned to another dataset of the same size (as is now done by changing manually tile->array and tile->block), the reference counter of its old dataset is decreased, while the reference counter of its new dataset is increased.