https://bugs.winehq.org/show_bug.cgi?id=50227
--- Comment #13 from Anastasius Focht focht@gmx.net --- Hello Frank,
--- quote --- What would the best way to get a helpful Backtrace? It seems that the commands I tried from the WineHQ Wiki just continue with the same spamming of the parse_url error --- quote ---
well, the message from your console logs indicate the process got killed by Linux out of memory manager. In that case there is nothing the app or Wine's crash reporter can do about it. The process is killed externally. One could use:
--- snip --- $ sudo sh -c "echo -1000 > /proc/$PID/oom_score_adj" --- snip ---
to prevent the process from being picked first by OOM killer in low memory situation. But if there is a real (fast) leak it will go to 100% and cause the system to freeze or panic, depending on the system setting. Another more advanced approach is to put the process with another one in a v2 cgroup with memory constraints and use one as sacrificial process with a low OOM score. The kill signal of the sacrificial process (due to OOM) could be trapped and then used to suspend all threads of the memory eating process. At that point the process state could be checked with regards to resource usage/mappings/handle leakage etc. Still, it would be hard to diagnose application specific resources, such as object/handled from .NET world.
How does the 64-bit .NET indexer process behave on Windows in the same situation (assuming same Logos 9.x installation/dataset)? Some bugs aren't necessarily Wine bugs but application ones.
Regards