Possible memory leak in PB 6.12?

[ColeopterusMaximus]

I think I've found a memory leak on PB 6.12, I've tested it with two computers and can reproduce the issue on both.

One computer is running Debian 11 (Linux 6.11.5) and the other is running an Arch machine up-to-date (Linux 6.12.4)

This is the offending code that can be used to reproduce it:

(save as leak.pb)

Code: Select all

EnableExplicit

DeclareModule leaktest

    Structure uds_config
        int_exitcode.i
        str_filename.s
        str_command_name.s
        str_command_value.s
        str_filter.s
        str_status.s
        str_socket.s
        str_error_msg.s
        int_archive.i
        bol_error_state.a
        bol_interactiveprompt.a
        bol_autosave.a
        bol_progress.a
        bol_debug.a
        List lst_commands.s()
    EndStructure

    Define varname.uds_config

EndDeclareModule

Module leaktest
    varname\int_exitcode = 1
    varname\str_filename = "test"
    AddElement(varname\lst_commands())
    varname\lst_commands() = "test2"

    Procedure function()
    EndProcedure
EndModule

If OpenConsole()
    PrintN(leaktest::varname\str_filename)
EndIf

If compiled as follows:

Code: Select all

pbcompiler leak.pb -o leak.bin

Then when running the binary run on valgrind:

Code: Select all

valgrind -s ./leak.bin 

==50002== Memcheck, a memory error detector
==50002== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==50002== Using Valgrind-3.24.0 and LibVEX; rerun with -h for copyright info
==50002== Command: ./leak.bin
==50002== 
test
==50002== 
==50002== HEAP SUMMARY:
==50002==     in use at exit: 854 bytes in 6 blocks
==50002==   total heap usage: 38 allocs, 32 frees, 6,120 bytes allocated
==50002== 
==50002== LEAK SUMMARY:
==50002==    definitely lost: 104 bytes in 1 blocks <<< LEAK
==50002==    indirectly lost: 0 bytes in 0 blocks
==50002==      possibly lost: 0 bytes in 0 blocks
==50002==    still reachable: 750 bytes in 5 blocks
==50002==                       of which reachable via heuristic:
==50002==                         length64           : 712 bytes in 3 blocks
==50002==         suppressed: 0 bytes in 0 blocks
==50002== Rerun with --leak-check=full to see details of leaked memory
==50002== 
==50002== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

If somebody else could verify this or let me know if I'm doing something wrong it would be great.

[Fred]

Can you observe the leak in a loop ? Some resources are not released at end because of the OS tracking feature which auto cleanup everything. It's especially the case when using strings as tracking them will be inefficient and memory consuming.

[ColeopterusMaximus]

Hi Fred,

Can you observe the leak in a loop ? Some resources are not released at end because of the OS tracking feature which auto cleanup everything. It's especially the case when using strings as tracking them will be inefficient and memory consuming.

I will try to see if I can reproduce it in a loop, I think I might have observed a case, it is a very elusive thing.

Found this accidentally when noticed that two programs had the same sharing that same structure.

[ColeopterusMaximus]

Hi Fred,

Good news, can't seem to trigger it in a loop.

After doing some more testing I've narrowed it down to this:

Code: Select all

EnableExplicit

Structure uds_leak
    test.a    
    List lst_list.s()
EndStructure

Define test.uds_leak

Basically the "leak" only shows up when using types a, b, c, w & l in a structure along with a list or a map.

Removing any of the smaller types from the structure makes the "problem" go away, so that is what I've done.

[DarkDragon]

Also keep in mind that valgrind also shows things as definitely lost which are intentionally not freed because the end of the process frees them anyway. Usually you'd generate a suppression file for that.

[ColeopterusMaximus]

Also keep in mind that valgrind also shows things as definitely lost which are intentionally not freed because the end of the process frees them anyway. Usually you'd generate a suppression file for that.

Thanks for the suggestion, this is useful too.