#18 "-q" flag is causing a oom-kill

[MisterE2002]

Can someone help with debugging this strange problem. The "-q" flag is causing a oom-kill in my debian VM. And the process is terminated with exit code 137.

Situation:
I have a freenas box. This box is exporting a share "/mnt/tank/vboxsf_share"
It is running a jail with Virtualbox. In the VM i am running a Debian instance.
I mount the share with this command.
mount -t vboxsf -o rw vboxsf_share /mnt/vboxsf_share/
So, now i have a loopback to the freenas share (without using the network overhead)

After i switched i noticed the crash of a script of mine. I traced it to the "-q" flag.
If i omit this flag everything is working, but i have have "output" (and i am not sure if it will output exit codes?)
It is reproducable. All other hash calculation programms (cksfv/md5sum/sha1sum) execute normally.

I can not enable verbose logging because this solves the problem :P

It looks like this fix "Work around bug in Python (only manifests with 64-bit Python version >= 2.5) which causes checksums of files > 4GB to be incorrectly calculated (when using mmap, eg, when the progress meter is disabled or not shown."
But this is fixed in version v1.18.2 (https://sourceforge.net/p/cfv/code/415/), and i am using version 1.18.3-2 (official packaged version)

KILLED:
cfv -C -q -f /root/tmp.csv "/mnt/vboxsf_share/file"

NOT KILLED:
cfv -C -f /root/tmp.csv "/mnt/vboxsf_share/file"

KILLED:
cfv -C -tmd5 -q -f /root/tmp.csv "/mnt/vboxsf_share/file"

NOT KILLED:
cfv -C -tmd5 -Q -f /root/tmp.csv "/mnt/vboxsf_share/file"

[folti_]

Hi,

if the problem still persist, could you try to run the errorneous commands with the CFV_NOMMAP=1 environment variable set?

For example:
CFV_NOMMAP=1 cfv -C -q -f /root/tmp.csv "/mnt/vboxsf_share/file"

Problem could be that your VM is limited memory wise, and reading through mmap accidentally consumes too much memory, triggering the OOM killer.

And it doesn't cause a problem without -q, because writing to the terminal inserts small delays in the file reading operation, allowing the kernel to shuffle around the data in the buffers.

[MisterE2002]

see my reaction below :)

[MisterE2002]

i tried a couple of times. It seems to help. In fact, if i use "export CFV_NOMMAP=0" it works also.
It seems to fail every time if i use "export CFV_NOMMAP="

To be honest, i switched to using "cksfv" instead.
Thanks for your reply.

[folti_]

"export CFV_NOMMAP=" exports the variable with a zero length string, whose detection is buggy with thecurrent code (and in shell scripts too), as zero length string is evaluated as False, which is means the value not set. So cfv doesn't care about the value of the variable, only that it have some non-zero string value.

That's why these kind of variables are always set with some variable that's not an empty string.

cksfv don't have this problem, as it doesn't use mmap.