Wrapping is a hard problem, there is no simple method of finding where to wrap lines on the screen, it can only be found by laying out each line and seeing by trial and error if it fills the screen width ... for each screen line at a time. So it takes a lot of work each time the wrapping has to be done, and if your file is only one line of source then up to the point that is shown on the screen has to be laid out to find where the visible wrapping lines start. There are various cunning caching methods to assist it, but if you do something like make a change at the start of the buffer then move to the end of the buffer the wrapping of the _whole_ buffer has to be found again, and that will be a delay.
And it may be slow, hence an apparent "freeze" while it happens. This is a known "issue" but not one that can be removed, although as @nyamatongwe pointed out, it may be possible to use some more of your CPU cores to divide and conquer the work. But Geany does not support that yet.
So for debugging purposes it might be better to make your file bigger to get that problem to show up quicker to see if it is the cause, maybe double or triple the file for testing purposes. But those freezes should only be temporary and the bigger file should make wrapping more obviously the cause, though possibly slow, but there should be no permanent freezes.
Since you have mentioned permanent freezes, that may be something different and is really a real problem if it exists. So the thing is to see if you can catch the permanent freeze in GDB after it has been permanent for a significant period on a relatively smaller file so the distinction between a slow wrapping freeze and a permanent freeze is more obvious.