Leopold Toetsch wrote:
Brent Dax wrote:
Can we add a way to explicitly free the memory associated with a buffer
without freeing the header? That seems like it could be useful in other
areas too (although I'm not quite sure where)
So mixing the 2 schemes is a PITA, IMHO.
did I write
Brent Dax wrote:
Leopold Toetsch:
# It's totally sane with the standard copying allocator. But the malloc
# allocator tracks resources (i.e. strings bufstart) only via
# the header.
# So, when you reuse the header, the old bufstart which was
# there before
# is unmanaged and leaks.
Can we a
Leopold Toetsch:
# It's totally sane with the standard copying allocator. But the malloc
# allocator tracks resources (i.e. strings bufstart) only via
# the header.
# So, when you reuse the header, the old bufstart which was
# there before
# is unmanaged and leaks.
Can we add a way to explici
Brent Dax wrote:
Leopold Toetsch:
# - string_set() is gone, highly (WRT malloc) illegal reusage
# of existing
# string headers - and unnecessary IMHO
I specifically asked for and received permission from Dan for this.
It's designed to remove the need to pass in
pointers-to-pointers-to-headers
Leopold Toetsch:
# - string_set() is gone, highly (WRT malloc) illegal reusage
# of existing
# string headers - and unnecessary IMHO
I specifically asked for and received permission from Dan for this.
It's designed to remove the need to pass in
pointers-to-pointers-to-headers in functions with s
Finally and after more changes I like to ci in one bunch, the parrot
interpreter is (almost) memory leak free.
Summary
Currently broken test:
- t/op/interp_2 with standard allocator and --gc-malloc
Memory leakages:
- PIO (PIO_new doesn't remember ParrotIO structures)
- rx (bitmaps)
- intstack (
