Some times I have a program (EiskaltDC++) running at 100% of CPU.
This seems odd considering it looks more or less like file sharing software -- unless of course it is interacting with hundreds or thousands of other nodes at once. I guess it is up to you to decide whether that is appropriate.
the Raspbian kill it in order to avoid the system to crash
No, a process running a CPU up to 100% is fine, at least in terms of operating system tolerances. Of course, if this is on a single core machine, the user interface is going to become sluggish or unusable, but there is nothing the OS can do about that (except kill the process, but again it absolutely will not do that).
To the extent that there are critical kernel threads that need to run that aren't servicing the greedy process directly, these have scheduling priority, so they will get to run. However, what they need to do is not processor intensive so you will not notice this impact the usage of the greedy process.
Keep in mind that user processes cannot really cause a system crash (running the system out of memory is one sort of exception I'll get to), at least not by accident, and as long as they are not run with root privilleges. A privileged process that can crash the system in some sense (e.g., by killing off other processes or overwriting critical libraries and application code on disk) will simply be allowed to do so. An unprivileged process won't have permission to do any of that, so there is no need to kill it.
There are two scenarios in which the OS will kill a process:
Memory access violation, aka. segmentation fault. This is when a process attempts to write to memory that has not been allocated to it. Once upon a time (think 1970s or early 80s), this was a real potential threat to other processes and the system, but processes on a modern operating system run in a virtual address space whereby addresses outside of that simply refer to space that does not exist. Which is why, when they attempt to access it, they are trying to do something impossible, and the OS will kill it.
The system has run out of physical memory. On linux, if you occupy 100% of RAM, as soon as something wants more the kernel invokes the "OOM killer". This selects a process to kill to free up memory. Generally this will be something that has been allocated a lot, or has recently been asking for more and more.
It seems to me that #2 is unlikely if the trigger is you clicking a button. In any case, it is easy to verify if you check memory use (e.g., with
Anyway can I avoid this behavior?
For #1 (seg fault), no, not unless you can fix the program. There is no logical reason for a program to try and access non-existent memory and anyone who programs in a language which would permit this (many of them don't) tries their best to avoid doing so. If they fail, then this constitutes a bug in the program, which is what your problem actually sounds like. Such bugs can always be fixed, but this does not mean they all have been.
To make sure that last point is clear, although technically it is the OS that kills the process, this is a bit like shooting yourself in the head and saying technically I did not kill myself, the gun did. There is nothing else that can happen.
With regard to the out-of-memory issue, you should first identify this is actually the problem. If, before you hit the button,
free shows almost no memory available, then after the system crashes, run
sudo journalctl -n 500 | grep -i "oom.killer". If it says anything, then this would confirm what is happening.
If that is the case, again there's not much that can be done if there is some bug in this program that keeps gobbling memory, or if it simply needs more than the Pi can provide.