How to Find the Point of Memory Leakage by DUMP_LEAKS infos

[yudaosi]

My system is running a test case in a loop. After dozens of runs, I found that the allocated memory has increased by 2MB compared to the initial state. I want to analyze the memory leak by DUMP_LEAKS information, but I don't know how to analyze it based on the information. Could you please give me some good suggestions?

Here's the DUMP_LEAKS info, and I intercepted some of it.
dump memory:
QuickJS memory usage , 32-bit, malloc limit: 10485760
NAME COUNT SIZE
memory allocated 81130 7433272 (91.6 per block)
memory used 79433 5071871 (8 overhead, 29.7 average slack)
atoms 8397 449007 (53.5 per atom)
strings 28014 1576240 (56.3 per string)
objects 14912 715776 (48.0 per object)
properties 43456 382144 (2.9 per object)
shapes 1046 169536 (162.1 per shape)
bytecode functions 6060 1033904
bytecode 6060 615119 (101.5 per function)
pc2line 1 1 (1.0 per function)
C functions 264
arrays 1266
fast arrays 1266
elements 15048 120384 (11.9 per fast array)
binary objects 1 1054015

I guess it's probably the leakage of string and atom, but after a preliminary look at atom, there are some constant strings, which should be fixed values and will not increase continuously.
The string contains a large number of variables. It is estimated that the problem is caused by this problem, but I do not know how to locate the problem.
Memory leakage occurs when the JS_FreeRuntime interface is used,

leaks info:
object leaks just a little.

atom leaks have More than 8,000.

String leaks are very many.

Memory leak: 3929960 bytes lost in 44692 blocks

[chqrlie]

The string leaks are regex source and compiled data.
Can you reduce your test loop to only test regex features.
Trimming down to a single test that leaks data is the way to investigate and find the offending code.

[yudaosi]

It's quite troublesome to simplify the test. The business process is rather complex, and I'm not clear about the approximate key steps, so it's difficult to carry out the simplification.
By comparing the DUMP_LEAKS outputs before and after running the test cases, I've found some differences.
Currently, from the DUMP_LEAKS info atom and string leaks, I've found that many are random numbers temporarily generated during the execution of JS code or strings generated by concatenation, which are used for log recording or message sending to the native C functions.
Generally speaking, these numbers or strings generated in the functions should be automatically free and released after the function execution is completed, right?

atom leaks

string leaks

[bnoordhuis]

Generally speaking, these numbers or strings generated in the functions should be automatically free and released after the function execution is completed, right?

Yes, but maybe you're forgetting to JS_FreeValue them on the C side? Are you per chance using them as object keys?

[yudaosi]

I've checked that all the strings on the C code have been released by JS_FreeCString. I understand that the args parameter in c native func does not need to be actively released by JS_FreeValue, right?
I'll check the key values again. If they are used as object key values, how can I actively release them in the JS code?

[bnoordhuis]

The arguments to C callbacks indeed don't need to be freed, but:

• in a call to JS_SetProperty(ctx, obj, atom, val), quickjs takes ownership of val but it's your responsibility to call JS_FreeAtom(ctx, atom) afterwards if you're not reusing the atom

• ditto for JS_DefineProperty, JS_DefinePropertyValue, etc. If you pass in getter or setter functions, you must JS_FreeValue them afterwards

• in JSValue val = JS_GetProperty(ctx, obj, atom), you need to both JS_FreeAtom(ctx, atom) and JS_FreeValue(ctx, val)