Your file is not corrupted; On Linux and POSIX systems, as long as a running process has an opened file descriptor to some file that it is writing, it will be able to continue writing it, even if you remove or rename that file (because a file descriptor is related to an i-node, not to a file name). in particular
logadm -or any sequence of external commands- won't do anything useful about the disk space.
I am assuming you are on Linux.
If your process has pid 1234, you could look into
/proc/1234/ in particular list the
/proc/1234/fd/ directory. Read proc(5).
You probably should stop the offending process (using
kill -TERM then
kill -QUIT then at last
kill -KILL; see signal(7) & kill(1)), then remove the file, and at last correct and/or configure your program to do some more useful logs, and start it again.
You probably have lost all the computation done by your program. So better stop it ASAP, improve it (perhaps you want some application checkpointing, or persistence, or add some way to have it close, then rename, and then re-open the log file), and restart an improved version of your program.
You should read Advanced Linux Programming. You probably have several bugs in your program (perhaps related to logging). You might use strace(1) to understand the syscalls done by your process, and you could use syslog(3) inside your (improved) program.
Very probably, you have a design bug in your program. So better stop it now, think, improve it, and start again. Waiting for the disk to be entirely filled won't help you (and it would make the matter worse).
For future testing purposes, you might consider setting some disk quotas and or some resource limits (e.g. setrlimit(2), and bash
In the future, always design your program to be able to afford restarting the process. Not being able to afford that is always a huge mistake (in particular, you need some backup strategy, and you need some revision control on your source code; I recommend git for that).