ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

It doesn't look like rosbag is being killed because it's out of memory; rather it looks like it's dying because it doesn't write the expected number of bytes to disk.

The causes for this sort of failure are fairly obscure. The man page for write(2) suggests a few possible causes: 1. The disk is full 2. You've hit your maximum file size limit (RLIMIT_FSIZE) 3. The call to write was interrupted

You've already indicated that that disk isn't full, which rules out #1 It fails at different sizes for different runs, which probably rules out #2

That leaves #3, which suggests that the call is being interrupted for some reason. I don't really have much insight into what might be interrupting it, and the error reporting within rosbag isn't reporting which errno was set after the failed write, so it's difficult to diagnose further.

The write man page also suggests that there are other, system-specific reasons that write could fail, but they're even more obscure and difficult to diagnose.

You may want to try some experiments with a simpler file creation tool to determine if the particular chunk size or file systems limits are getting in the way. I would try:

dd if=/dev/zero of=test1.data bs=13M count=1 # write a 13MB chunk to disk. If this fails, the chunk size may be the problem
dd if=/dev/zero of=test2.data bs=1M # write 1MB chunks to disk until it's full. This is similar to how rosbag writes, but much simpler. If this fails for any reason other than the disk being full, that is very interesting
dd if=/dev/zero of=test3.data bs=13M # write 13MB chunks to disk until it's full.

If you can provide the flags that you're passing to rosbag, those may also help debug the problem further.

It doesn't look like rosbag is being killed because it's out of memory; rather it looks like it's dying because it doesn't write the expected number of bytes to disk.

The causes for this sort of failure are fairly obscure. The man page for write(2) suggests a few possible causes: 1. The disk is full 2. causes:

  1. The disk is full
  2. You've hit your maximum file size limit (RLIMIT_FSIZE) 3. (RLIMIT_FSIZE)
  3. The call to write was interrupted

You've already indicated that that disk isn't full, which rules out #1 It fails at different sizes for different runs, which probably rules out #2

That leaves #3, which suggests that the call is being interrupted for some reason. I don't really have much insight into what might be interrupting it, and the error reporting within rosbag isn't reporting which errno was set after the failed write, so it's difficult to diagnose further.

The write man page also suggests that there are other, system-specific reasons that write could fail, but they're even more obscure and difficult to diagnose.

You may want to try some experiments with a simpler file creation tool to determine if the particular chunk size or file systems limits are getting in the way. I would try:

dd if=/dev/zero of=test1.data bs=13M count=1 # write a 13MB chunk to disk. If this fails, the chunk size may be the problem
dd if=/dev/zero of=test2.data bs=1M # write 1MB chunks to disk until it's full. This is similar to how rosbag writes, but much simpler. If this fails for any reason other than the disk being full, that is very interesting
dd if=/dev/zero of=test3.data bs=13M # write 13MB chunks to disk until it's full.

(you should probably remove the test files created between tests)

If you can provide the flags that you're passing to rosbag, those may also help debug the problem further.