[Bug 195970] emulators/virtualbox-ose-kmod & memory allocator problem: "dd: stdout: Cannot allocate memory"

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195970

--- Comment #3 from Martin Birgmeier <la5lbtyi at aon.at> ---
I have tried to refine the scenario where the problem appears, and the results
are as follows.
- I run a 3 GB VB client on an 8 GB machine
- On this machine I start a dd with a blocksize of 128k to copy a 250G disk
slice to standard output (the purpose being to make an image backup of the
Windows partition).

The difference is how I start dd:
- Just running
    dd if=/dev/ada0s2 of=/dev/null bs=128
  works.
- Running
    dd if=/dev/ada0s2 bs=128k | cat > /dev/null
  works.
- *On another machine*, running
    rsh -n <the machine running the VB client> "dd if=/dev/ada0s2 bs=128k" >
/dev/null
  produces "dd: stdout: Cannot allocate memory" quite soon (but after a
non-deterministic number of blocks have been transferred).

If I do this using ssh, the behavior is slightly different but still erroneous:
    ssh -n <the machine running the VB client> "dd if=/dev/ada0s2 bs=128k" >
/dev/null
  produces "Connection to <the machine running the VB client> closed by remote
host." without a message from dd.

I could not note any anomalies in memory usage as monitored by "top" and
"systat -vm 1".

If, after the tests above, I shut down the VB client while keeping everything
else the same, issuing the rsh command runs to completion correctly.

Note that in that other scenario where I was using "zfs send", "zfs send" was
also invoked via "rsh -n".

So it seems that sending data via rsh while a VB client is running leads to the
problem.

-- Martin

-- 
You are receiving this mail because:
You are the assignee for the bug.