get parse fault to call py function after garbage collection

[Indiacurry]

Environment :
OS is FreeRTOS and board is not pyboard.
do_str/do_file/garbage collection is ported to this.

basically do file and do_str work. garbage collection also works in general situation.
But I got HardFault to call do_str with a little complicate string just after garbage collection occurs.
My code(1) is as follows.
testcode.py has function implementation of "function_A"
do_str() works correctly repeatedly
But just after garbage collection, it get HardFault.

--(1)-----------------------------------------------------------------
do_file("/testcode.py");

while (1) {
do_str("globals()[\'function_A\'](\"on\")");
}
----------------------------------------------------------------------

for comparing, this code(2) works well also after garbage collection occurs.
The difference is how to call the function - whether call with function name or function pointer taken globals() with it's function name.

--(2)-----------------------------------------------------------------
do_file("/testcode.py");

while (1) {
do_str("function_A(\"on\")");
}
----------------------------------------------------------------------

(1) actually has several(3) python operation within it. could it makes issue with gc?
The section for garbage collector search is BSS, Data, Stack, register.
Could you give some opinion?
Thank you for reading this.

[Damien]

Hi.

That's an interesting bug... It could be that there is something wrong with the way globals are stored and scanned by the GC. Did you try this code on the unix version?

[Indiacurry]

Thank you for your reply.
I found it's not produced in unix.
Now I need to consider which platform dependent difference cause this symptom.
Do you have any suggestion for direction in this situation?
Thank you.

[Damien]

There might be a problem in how your garbage collection root-pointer scanner is implemented. Can you post your code for gccollect?

[Indiacurry]

gc_collect_root implementation is almost same with your reference except the section to search is extended to data.

Now please let me share additional info.
The difference of code (1) and code (2) above could be raising parsing.
After do_file(usercode.py), calling repeatedly py function in usercode.py with it's name or it's function pointer mp object doesn't get the fault.

In more test, just execute do_str("print(\"hello python\")") in while loop also get the fault.
and, execute do_file("testcode.py") in while loop get the fault.
all commands those require parsing get this symptom, as I look.
some command always get hardfault just after gc as I told before,
but other command is ok after gc then get fault in the middile of do_str in more test.

The code that gets all faults is same -mp_node_parse_free.

as tracking of gc_alloc/gc_free log,
there are gc_free for 0x000000 and gc_free for already freed address by previous gc_free.
consecutive free for invalidate address end up with hard fault.

FYI, All these issue and strange log is not produced in unix version.

Now I need to figure out what happens in parsing in this environment.
Could you give some advice for this?

[stijn]

I think you're going to have to post actual code, both for gc_collect and the minimum python code needed to reproduce the issue, else it's going to be hard to guess what the problem is.

[Damien]

In more test, just execute do_str("print(\"hello python\")") in while loop also get the fault.

I tried this infinite loop on pyboard by editting main.c and there is no problem.

gc_free for already freed address by previous gc_free

This should not be happening.

The parser may be running out of memory. Or the compiler may be running out of memory and raising an uncaught exception.

It looks like an issue with the garbage collection. Are you tracing all your root pointers? It's difficult to help any further without seeing your code and having your hardware in front of me!