Heap corruption/access violation while using custom search monitor in routing

[jzdfm]

What version of OR-Tools and what language are you using?
Version: 9.0.9048
Language: Python (3.8)

Which solver are you using (e.g. CP-SAT, Routing Solver, GLOP, BOP, Gurobi)
Routing solver

What operating system (Linux, Windows, ...) and version?
Windows 10

What did you do?
I created quite complicated model. Due to one of requirements I had to be able to validate solutions on later stage (when all routes are known). The way I managed to do it is creating own SearchMonitor and returning True or False in AcceptSolution. The part of code that I added to my program is:

...
def make_search_monitor(routing_model, input_data, manager, veh_list):
    class MMonitor(pywrapcp.SearchMonitor):
        def __init__(self, solver, d, mod, man, veh_list):
            pywrapcp.SearchMonitor.__init__(self, solver)                  
            self.lastRes = True
        def AtSolution(self) -> bool:
            return super().AtSolution()        
        def AcceptSolution(self) -> bool:            
            if self.lastRes:
                self.lastRes = False
                return True 
            return False
                                                        
    return MMonitor(routing_model.solver(), input_data, routing_model, manager, veh_list)
...
sm = make_search_monitor(routing, data, manager, vehicles)    
routing.AddSearchMonitor(sm)
solution = routing.SolveWithParameters(search_parameters)

This is modified version of my SearchMonitor, it accepts only the first solution and rejects all other (the "real" one does some calculations in AcceptSolution and returns True or False depending on solution, but issue occurs in both versions). Everything seems to work fine in most situations, but sometimes I get two errors interchangeably, sometimes it is exception 0xc0000005 at 0x00000000001afb5a (_pywrapcp.pyd), sometimes exception 0xc0000374 at 0x00000000000ff0b9 (ntdll.dll).
When disable the monitor by commenting out these lines

# sm = make_search_monitor(routing, data, manager, vehicles)    
# routing.AddSearchMonitor(sm)

then I get no error, but also results are not filtered as I need.

What did you expect to see
No exceptions.

What did you see instead?
Exceptions.

Make sure you include information that can help us debug (full error message, model Proto).

Anything else we should know about your project / environment
I am not sure if that matters, I use portable Python.
I attached files (Python scipts + data) that demonstrate the issue, planowanie_v2.py is the main file to run.
rp.zip

[jzdfm]

I stripped the code even more, there are only cost calculation and capacity dimension left, the issue persists.
rp.zip

[jzdfm]

Can you please tell me when approximately this issue will be resolved?

[lperron]

I think the python search monitored is GCed before the end of the search. Please make sure you keep a reference that outlives the search. Le jeu. 27 mai 2021 à 07:50, jzdfm ***@***.***> a écrit :

…

Can you please tell me when approximately this issue will be resolved? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2559 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3MN4R74Q7QRVLGCUETTPXMSRANCNFSM45ENI5EA> .

[jzdfm]

I am not sure if I understood you, you mean that monitor gets garbage collected? I think it is not the case, when I run the code:

... 
    sm = make_search_monitor(routing)
    routing.AddSearchMonitor(sm)
    print(sys.getrefcount(sm)) # => prints 2
    
    print('Starting solver.')
    
    # Solve the problem.
    solution = routing.SolveWithParameters(search_parameters)
...

then sys.getrefcount returns 2 for monitor reference, so as far as I understand Python GC mechanism it should not be released.