Pcl: [tools] pcl_viewer does not show clouds anymore

[themightyoarfish]

In commit fa71f8044598cd7c285be7bbca22acb6cd39e807, the pcl_viewer binary does not display clouds anymore. I have tested with the test/colored_cloud.pcd PCD file. It still works in tag pcl-1.9.1.

Expected behavior
Cloud from pcd file is shown

Current Behavior

Black viewport, no cloud.

To Reproduce

1. Compile aforementioned commit from source
2. Run ./bin/pcl_viewer ../test/colored_cloud.pcd

Your Environment (please complete the following information):

• OS: ElementaryOS Hera (Ubuntu 18.04)
• Compiler: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.
• PCL Version fa71f8044598cd7c285be7bbca22acb6cd39e807

[kunaltyagi]

Can you perform a git bisect and tell us when the issue arose? I have my suspicions but I'd like to know for sure

[themightyoarfish]

I bisected on macos and found that 920a346bd2e0faf7756b3608b76116d39da8b8ce is the first offending commit.

I have to note I had to uninstall openmp after the first 1 or 2 steps because linking with it fails at those commits, but I hope this does not falsify the result.

[themightyoarfish]

I guess the change here has the deletion of the point cloud as an unintended side effect?

commit 920a346bd2e0faf7756b3608b76116d39da8b8ce
Author: Kunal Tyagi <[email protected]>
Date:   Wed Mar 25 00:16:06 2020 +0900

    Fix a memory leak in `OctreeBase::operator=` (#3787)

    Fixing a leak in OctreeBase::operator=

diff --git a/octree/include/pcl/octree/octree_base.h b/octree/include/pcl/octree/octree_base.h
index 56e65cb8d..6b516c365 100644
--- a/octree/include/pcl/octree/octree_base.h
+++ b/octree/include/pcl/octree/octree_base.h
@@ -247,6 +247,9 @@ public:
   {
     leaf_count_ = source.leaf_count_;
     branch_count_ = source.branch_count_;
+    if (root_node_) {
+      delete root_node_;
+    }
     root_node_ = new (BranchNode)(*(source.root_node_));
     depth_mask_ = source.depth_mask_;
     max_key_ = source.max_key_;

[kunaltyagi]

My suspicions were wrong. If you remove this patch from master, does the issue go away?

[themightyoarfish]

Master does not actually seem to have this code … but it still does not work. I am confused.

[themightyoarfish]

Looks like f934d1d2e0056ae04cc6b202b425ce6ae3f66e9d removed the change again, but clearly this did not fix the issue. Either I'm doing something wrong, or the problem has two separate causes.

[kunaltyagi]

The problem might have a different cause. We haven't received any other bugs/complaint. Please try to bisect again to confirm. It'll be difficult to know what causes the error otherwise. My guesses:

• your compilation wasn't clean and it picked up artifacts from previous builds: usually CMake and make take care of this
• your display module and VTK don't interact well with each other: why would 1.9.1 work?
• PCL and VTK have a subtle change in their interaction since 1.9.1: more errors reports should have been reported

You can start experimenting to remove the uncertainty in the origin:

• Eliminate Point 1: If possible in your bisect, try for a clean build. You can use ccache to save time the first time around, but if the bisect fails to pin down, you'd have to use build pcl_viewer clean, every-time.
• Eliminate Point 2: Try using different versions of VTK, eg: 6, 7 to see of the situation changes

Point 3 would be a bug in PCL, eliminated only by a PR

[taketwo]

Also, try to press "r" to reset the virtual camera and get the clouds into the FoV.

[themightyoarfish]

I have ruled out point 1: Removing the entire build folder before compilation now shows the problem appearing with commit b3af6c12487ce9f7723399c7c54ec69ff5ca2fd7, which is a different one from earlier.

[themightyoarfish]

Interestingly, the default grid scale has steps in the order of 1e38.

[themightyoarfish]

I'll bisect again with a complete clean build each time.

[themightyoarfish]

i have arrived at a different culprit: f45fa48b2e7e6cdc1cf9e77db832250cc70f9d84

Probably cleaning the build folder in between was important.

[themightyoarfish]

But again, if i move backwards from this commit, i still get the problem. Somehow, bisecting is ineffective here.

[themightyoarfish]

Each time I bisect between known good and bad commits I get a different result. not sure what to do here.

[themightyoarfish]

for reference, I've been running this from the root dir at each commit:

rm -rf build/* && cmake -B build/ -S . && make -C build pcl_viewer && ./build/bin/pcl_viewer.app/Contents/MacOS/pcl_viewer ./test/colored_cloud.pcd

[themightyoarfish]

I could _un_install ccache I guess, but I've never seen ccache be the source of any errors.

[kunaltyagi]

You can also unconfigure ccache as the compiler in the cmake. The issue might be from headers which are almost the same, but not quite. I really don't know what's happening here.

[larshg]

I have reproduced this error on windows 10, vs2019 and vtk 8.2

It seems to fail to delete an array, when it will update the pointdata with new scalars, ie. colors from the colorhandle.

Seems to be a heap error:

[kunaltyagi]

That's great news. How did you reproduce it? Can you perhaps aid in find the offending commit?

[larshg]

I have tried a checkout 10 months ago and it still fails. I tried 1.9.1, but I had linker errors with lz library.

[themightyoarfish]

Fwiw, I encountered this problem on ubuntu 18.04, 16.04 and then macos, so it probably isn't specific to the environment I was bisecting in.

[larshg]

My above errors is not relevant. It was VTK/VCPKG debug/release mix failure again :S

Now I also just get a black view, with no points rendered.

[kunaltyagi]

@themightyoarfish Can you please test the PR and confirm that @larshg's diff works for you too? (It should)
CI can't do this for us 🤔