After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 769064 - Assert that array size does not change during free handlers
Assert that array size does not change during free handlers
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: garray
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2016-07-22 00:07 UTC by Sam Spilsbury
Modified: 2018-04-20 13:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
garray: Assert that array size does not change during free handlers (2.97 KB, patch)
2016-07-22 00:08 UTC, Sam Spilsbury
none Details | Review
garray: Steal segment during destruction (3.31 KB, patch)
2018-04-20 12:24 UTC, Sam Spilsbury
committed Details | Review

Description Sam Spilsbury 2016-07-22 00:07:32 UTC
In bug #769061 it was possible that a programmer might accidentally mutate a pointer array during an element free handler. Assert that this does not happen to alert the programmer that this case is not supported.
Comment 1 Sam Spilsbury 2016-07-22 00:08:22 UTC
Created attachment 331944 [details] [review]
garray: Assert that array size does not change during free handlers
Comment 2 Christian Hergert 2016-07-22 01:18:12 UTC
One quick nit is that the style doesn't match the rest of the file for scoping.

Another idea might be to add an "in_destruction" bit to the structure (or steal the pdata pointer) so that we can g_return_if_fail() in mutation functions and index accessors. That would allow us to know exactly where the problem is with G_DEBUG=fatal-criticals to get a stack trace.
Comment 3 Sam Spilsbury 2016-07-22 01:30:39 UTC
(In reply to Christian Hergert from comment #2)
> One quick nit is that the style doesn't match the rest of the file for
> scoping.
> 

Ah, of course. Thanks for pointing that out.

> Another idea might be to add an "in_destruction" bit to the structure (or
> steal the pdata pointer) so that we can g_return_if_fail() in mutation
> functions and index accessors. That would allow us to know exactly where the
> problem is with G_DEBUG=fatal-criticals to get a stack trace.

I suppose that is the better approach. I'll rewrite the patch on this suggestion. Thanks for the review!
Comment 4 Philip Withnall 2018-04-19 13:27:21 UTC
Any progress on this, Sam?
Comment 5 Sam Spilsbury 2018-04-19 13:37:26 UTC
(In reply to Philip Withnall from comment #4)
> Any progress on this, Sam?

Not at the moment. I'll take a look tomorrow.
Comment 6 Sam Spilsbury 2018-04-20 12:24:11 UTC
Created attachment 371156 [details] [review]
garray: Steal segment during destruction

And warn in other parts of the code if the caller attempts
to change the array bounds during destruction, this is not
a valid operation.
Comment 7 Philip Withnall 2018-04-20 12:53:18 UTC
Review of attachment 371156 [details] [review]:

I’ll push with the change below, thanks.

::: glib/garray.c
@@ +1116,3 @@
+        }
+
+      rarray->pdata = stolen_pdata;

I don’t think there’s any need to reassign the stolen_pdata to rarray->pdata here: we immediately set it to NULL or free the rarray.
Comment 8 Philip Withnall 2018-04-20 12:54:41 UTC
Review of attachment 371156 [details] [review]:

::: glib/garray.c
@@ +1112,3 @@
       if (rarray->element_free_func != NULL)
+        {
+          for (gsize i = 0; i < rarray->len; ++i)

Also, initial declarations in `for` loops are not allowed in GLib because some of the compilers we target don’t support them. :-(  I’ll fix this too.
Comment 9 Philip Withnall 2018-04-20 13:02:57 UTC
Pushed with those fixups.

Attachment 371156 [details] pushed as 0e1a26d - garray: Steal segment during destruction