Memory size accounting error

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Memory size accounting error

Stephen R. van den Berg
Can anyone confirm that the following patch seems reasonable?
Or am I seeing the results of anomalies I created/missed in the
Buffer/Shuffler rewrites?

    Memory size accounting error.

diff --git a/src/builtin_functions.c b/src/builtin_functions.c
index 52534409d7..993ba05611 100644
--- a/src/builtin_functions.c
+++ b/src/builtin_functions.c
@@ -8262,6 +8262,7 @@ unsigned int rec_size_svalue( struct svalue *s, struct mapping **m )
         case PIKE_T_FLOAT:
         case PIKE_T_FUNCTION:
         case PIKE_T_TYPE:
+        case PIKE_T_FREE:
             return 0;
     }
     if( !m ) return 0;

Without this fix, obviously perhaps, it coredumps.  Inserting a PIKE_T_FREE
in a mapping does not work.
--
Stephen.
Reply | Threaded
Open this post in threaded view
|

Re: Memory size accounting error

Tobias S. Josefowitz
On Thu, Apr 1, 2021 at 1:08 PM Stephen R. van den Berg <[hidden email]> wrote:
>
> Can anyone confirm that the following patch seems reasonable?
> Or am I seeing the results of anomalies I created/missed in the
> Buffer/Shuffler rewrites?

PIKE_T_FREE is only acceptable in a limited amount of places, and
inside mappings is not one of them. In particular, as far as I
understand, PIKE_T_FREEs should never be user-reachable.
Reply | Threaded
Open this post in threaded view
|

Re: Memory size accounting error

Stephen R. van den Berg
Tobias S. Josefowitz wrote:
>PIKE_T_FREE is only acceptable in a limited amount of places, and
>inside mappings is not one of them.

I do not insert it into a mapping, the size-calculation code tries to
just below this code fragment.

> In particular, as far as I
>understand, PIKE_T_FREEs should never be user-reachable.

If one would insert an object into a multiset, and the object
then gets destructed; what happens to the references from within the multiset
to the object?
--
Stephen.
Reply | Threaded
Open this post in threaded view
|

Re: Memory size accounting error

Tobias S. Josefowitz
On Thu, Apr 1, 2021 at 1:22 PM Stephen R. van den Berg <[hidden email]> wrote:
>
> Tobias S. Josefowitz wrote:
> >PIKE_T_FREE is only acceptable in a limited amount of places, and
> >inside mappings is not one of them.
>
> I do not insert it into a mapping, the size-calculation code tries to
> just below this code fragment.

Then that most likely means you're keeping PIKE_T_FREE type svalues
around in places where you shouldn't.

>
> > In particular, as far as I
> >understand, PIKE_T_FREEs should never be user-reachable.
>
> If one would insert an object into a multiset, and the object
> then gets destructed; what happens to the references from within the multiset
> to the object?

Not a multiset expert, but in general svalue pointing to destructed
objects keep doing so, the struct object* stays around (but their
o->prog is NULL), and the svalue's may gradually get converted to
T_INT, subtype NUMBER_DESTRUCTED by maintenance code and possibly even
the GC during runs.