I am getting repeatable runtime exceptions on OS X trying to use an ImageViewer or PCLVisualizer from a thread that is not the main thread.
NOTE: In all cases I am creating the object and calling APIs on it from only a single thread. It just explodes when that thread is not the main thread.
OS X 10.8.4
PCL trunk 28d22bca0422
VTK 5.10.1
This is OS X specific. Similar code works fine on Ubuntu.
Test case here: https://gist.github.com/martyvona/6471785
Full spew:
objc[21120]: Object 0x7ffcd90006d0 of class __NSDictionaryM autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
(SEVERAL MORE LIKE THAT)
2013-09-06 20:39:50.334 test_viz_from_thread[21120:1203] *** Assertion failure in +[NSUndoManager _endTopLevelGroupings], /SourceCache/Foundation/Foundation-945.18/Misc.subproj/NSUndoManager.m:328
2013-09-06 20:39:50.336 test_viz_from_thread[21120:1203] +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.
2013-09-06 20:39:50.338 test_viz_from_thread21120:1203
(SEVERAL MORE LIKE THAT)
libc++abi.dylib: terminate called throwing an exception
Abort trap: 6
I wonder if this is PCL related or VTK related. I remember discussions where OSX had issues with UI and threads (e.g., http://www.vtk.org/pipermail/vtkusers/2008-August/096340.html, http://stackoverflow.com/questions/10710064/vtk-java-on-os-x-cocoa-exceptions)
Wouldn't be surprised if it's vtk related. Or maybe even a fundamental
limitation of OS X (actually I would be a little surprised about that).
If you can't fix it in PCL then at least documenting it would be helpful.
On Sat, Sep 7, 2013 at 2:34 PM, rbrusu [email protected] wrote:
I wonder if this is PCL related or VTK related. I remember discussions
where OSX had issues with UI and threads (e.g.,
http://www.vtk.org/pipermail/vtkusers/2008-August/096340.html,
http://stackoverflow.com/questions/10710064/vtk-java-on-os-x-cocoa-exceptions
)—
Reply to this email directly or view it on GitHubhttps://github.com/PointCloudLibrary/pcl/issues/253#issuecomment-24007016
.
Marty, agreed - we should document this somewhere. What would be a good place to add it?
Well I did see the notes you have already in the comments for the
PCLVisualizer constructor regarding only calling APIs from a single thread.
Why not add a sentence or two there stating that in fact that thread may
need to be the main thread on OS X.
I don't know if there is similar documentation in ImageViewer, and I also
don't know what other visualization entry points you may have where this is
an issue (is CloudViewer deprecated?).
Best,
Marty
On Sat, Sep 7, 2013 at 2:44 PM, rbrusu [email protected] wrote:
Marty, agreed - we should document this somewhere. What would be a good
place to add it?—
Reply to this email directly or view it on GitHubhttps://github.com/PointCloudLibrary/pcl/issues/253#issuecomment-24007202
.
We've been trying to deprecate CloudViewer, but we don't want to break the API, so realistically, it will hang around in the 1.x series for a while. Can you please submit a pull request with a comment for ImageViewer, CloudViewer, and maybe even PCLVisualizer that would help future users understand this issue? Thanks in advance.
Sorry but that will require a few hours of reading github documentation and
learing more git, and I just can't afford the hours right now.
On Sat, Sep 7, 2013 at 3:00 PM, rbrusu [email protected] wrote:
We've been trying to deprecate CloudViewer, but we don't want to break the
API, so realistically, it will hang around in the 1.x series for a while.
Can you please submit a pull request with a comment for ImageViewer,
CloudViewer, and maybe even PCLVisualizer that would help future users
understand this issue? Thanks in advance.—
Reply to this email directly or view it on GitHubhttps://github.com/PointCloudLibrary/pcl/issues/253#issuecomment-24007504
.
Also, I don't claim to understand the issue. I just observed the behavior. Maybe it is a but that is easily fixed. I do not know enough about os x or vtk to definitively talk about this other than to notify it to people who do know about those things. I would love to become knowledgeable enough about those topics, but again, the hours.
Marty, understood, but it's really not a big deal. All you need to do is clone PCL by clicking the Fork button in the right part of the screen, check that out locally on your hard drive, add whatever comments you'd like, then do git commit and git push, and then back in the GitHub interface submit a pull request by comparing your branch with the master branch. Click-click.
Shouldn't take you more than 10 minutes all in all, and it's information that can be reused for other purposes lately. Other folks that run into the same issue will thank you.
As I mentioned on the mailing list, we understand frustration very well, but this has to be a 2-way street in order for things to work smoothly. We can't just drop complains and yell at open source developers to fix things, and expect them to do it - we need to help each other. I understand that 10 minutes of your time is valuable, but so is others'. ;)
I'm sorry, I don't think I've yelled, or complained. If you could point
out the text were I did so I would appreciate it so I could avoid doing so
in the future.
I don't think I even asked you to fix this issue. I'm just telling you
about it. I worked around it in my code by switching the visualization
calls to the main thread.
I submitted a detailed bug report. Is that not helpful? Sorry that in
addition to the bug report I cannot afford additional time to actually fix
the bug for you right now. I truly would like to help and I will even try
to do a pull request like you asked but such a task simply must go into my
priority queue. I'm trying to say that in the nicest possible way.
Returning to the technical matter of this bug report, in my mind it
probably requires more investigation by people more expert than I and more
familiar than I with this stuff. That is my perspective. OTOH it sounds
to me like you may already feel confident that this is something that
should be just documented as known behavior. If so then perhaps it would
have taken you less time to just fix your documentation than ask me to do
it, when I am not even fully sure personally that is the right thing to do,
and I am not sure of the implications of exactly how to word it, what other
parts of your code may be affected, etc?
If I had developed more than a few lines of code to fix something in PCL,
and I already had it done, and it was clearly the right way to fix the
problem, and you wanted it, and it would help others in the near term, then
yes I would probably doing a pull request for it right now. Those factors,
together, would push the task to the top of my queue. In fact I submitted
about 1k LOC patch to another open source project earlier this month
(jv-extension), included directly with my bug report, because I'd already
written the code, and because their thing had just critically broken (and
because they were happy to accept a simple patch file and I didn't have to
teach myself more git and github; those things are definitely on my list
too).
To attempt to end on a note of at least minor humor: I will submit that it
has almost certainly taken me longer to craft this message than it would
have taken to at least try to do a pull request, so if you are thinking
that about now, I would agree =)
On Sat, Sep 7, 2013 at 3:08 PM, rbrusu [email protected] wrote:
Marty, understood, but it's really not a big deal. All you need to do is
clone PCL by clicking the Fork button in the right part of the screen,
check that out locally on your hard drive, add whatever comments you'd
like, then do git commit and git push, and then back in the GitHub
interface submit a pull request by comparing your branch with the master
branch. Click-click.Shouldn't take you more than 10 minutes all in all, and it's information
that can be reused for other purposes lately. Other folks that run into the
same issue will thank you.As I mentioned on the mailing list, we understand frustration very well,
but this has to be a 2-way street in order for things to work smoothly. We
can't just drop complains and yell at open source developers to fix things,
and expect them to do it - we need to help each other. I understand that 10
minutes of your time is valuable, but so is others'. ;)—
Reply to this email directly or view it on GitHubhttps://github.com/PointCloudLibrary/pcl/issues/253#issuecomment-24007641
.
:) No worries, we'll get to the bottom of it. I think the Mac OS issue is coming from VTK, and the threads that we saw seem to indicate this. We'll wait a bit to see if others can confirm it and then try to document it better in our header files.
I can confirm this issue for both ImageViewer and PCLVisualizer. I am using g++, gcc, Xcode 5.0.1, PCL trunk, and otherwise followed directions of Ken Spratlin (thank you Ken Spratlin ;) below:
http://www.pcl-users.org/file/n4026240/PCL_Development_Build_-_Mac_OS_X_%2820_Feb_2013%29.pdf
Christopher, we'd be happy if someone submits a pull request with better documentation on this issue.
So far as I can tell, this a VTK issue. The sample program martyvona provided at https://gist.github.com/martyvona/6471785 does not work when either PCLVisualizer or ImageViewer are instantiated and run on a thread other than the main thread. Therefore CloudViewer, for example, does not work, since I believe it spawns a thread to run PCLVisualizer. The problem was not mitigated by the following steps: (1) instantiating an NSThread to tell Cocoa to start multithreading - this is already done in vtkCocoaRenderWindow anyway, but adding it did not help; (2) disabling registration on the NSUndoManager for the NSView corresponding to the window; (3) adding an additional autorelease pool. When run on a non-main thread, spinOnce() gets called about 100 times on my machine before the assert gets triggered, so it may have something to do with GC mechanisms - but that's just a guess. I can add a pull request if that would help.
Even more than VTK, it seems to be a Cocoa limitation.
Fair enough ;) but VTK does not seem to abide by Cocoa's limitations.
Is there something specific that we can do to close this issue? Since it's a Cocoa limitation, I'm not sure what we can do other than improve our documentation. We can add a separate pull request for that.
I'm experiencing this problem with the tutorial for CloudViewer. http://pointclouds.org/documentation/tutorials/cloud_viewer.php
$ ./a.out
2014-01-27 14:38:44.111 a.out[23301:1903] *** Assertion failure in +[NSUndoManager _endTopLevelGroupings], /SourceCache/Foundation/Foundation-1056/Misc.subproj/NSUndoManager.m:328
2014-01-27 14:38:44.113 a.out[23301:1903] +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.
2014-01-27 14:38:44.121 a.out[23301:1903] (
0 CoreFoundation 0x00007fff9709441c __exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff8f4e5e75 objc_exception_throw + 43
2 CoreFoundation 0x00007fff970941f8 +[NSException raise:format:arguments:] + 104
3 Foundation 0x00007fff8f811c61 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 189
4 Foundation 0x00007fff8f77c22c +[NSUndoManager(NSPrivate) _endTopLevelGroupings] + 156
5 AppKit 0x00007fff8aa39a53 -[NSApplication run] + 688
6 libpcl_visualization.1.7.dylib 0x0000000103c6c2ed _ZN3pcl13visualization13PCLVisualizer8spinOnceEib + 173
7 libpcl_visualization.1.7.dylib 0x0000000103c9c463 _ZN3pcl13visualization11CloudViewer16CloudViewer_implclEv + 963
8 libboost_thread-mt.dylib 0x000000010a97524a thread_proxy + 186
9 libsystem_pthread.dylib 0x00007fff90f9f899 _pthread_body + 138
10 libsystem_pthread.dylib 0x00007fff90f9f72a _pthread_struct_init + 0
11 libsystem_pthread.dylib 0x00007fff90fa3fc9 thread_start + 13
)
2014-01-27 14:38:44.122 a.out[23301:1903] *** Assertion failure in +[NSUndoManager _endTopLevelGroupings], /SourceCache/Foundation/Foundation-1056/Misc.subproj/NSUndoManager.m:328
2014-01-27 14:38:44.123 a.out[23301:1903] An uncaught exception was raised
2014-01-27 14:38:44.124 a.out[23301:1903] +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.
2014-01-27 14:38:44.124 a.out[23301:1903] (
0 CoreFoundation 0x00007fff9709441c __exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff8f4e5e75 objc_exception_throw + 43
2 CoreFoundation 0x00007fff970941f8 +[NSException raise:format:arguments:] + 104
3 Foundation 0x00007fff8f811c61 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 189
4 Foundation 0x00007fff8f77c22c +[NSUndoManager(NSPrivate) _endTopLevelGroupings] + 156
5 AppKit 0x00007fff8aa39afd -[NSApplication run] + 858
6 libpcl_visualization.1.7.dylib 0x0000000103c6c2ed _ZN3pcl13visualization13PCLVisualizer8spinOnceEib + 173
7 libpcl_visualization.1.7.dylib 0x0000000103c9c463 _ZN3pcl13visualization11CloudViewer16CloudViewer_implclEv + 963
8 libboost_thread-mt.dylib 0x000000010a97524a thread_proxy + 186
9 libsystem_pthread.dylib 0x00007fff90f9f899 _pthread_body + 138
10 libsystem_pthread.dylib 0x00007fff90f9f72a _pthread_struct_init + 0
11 libsystem_pthread.dylib 0x00007fff90fa3fc9 thread_start + 13
)
2014-01-27 14:38:44.125 a.out[23301:1903] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '+[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff9709441c __exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff8f4e5e75 objc_exception_throw + 43
2 CoreFoundation 0x00007fff970941f8 +[NSException raise:format:arguments:] + 104
3 Foundation 0x00007fff8f811c61 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 189
4 Foundation 0x00007fff8f77c22c +[NSUndoManager(NSPrivate) _endTopLevelGroupings] + 156
5 AppKit 0x00007fff8aa39afd -[NSApplication run] + 858
6 libpcl_visualization.1.7.dylib 0x0000000103c6c2ed _ZN3pcl13visualization13PCLVisualizer8spinOnceEib + 173
7 libpcl_visualization.1.7.dylib 0x0000000103c9c463 _ZN3pcl13visualization11CloudViewer16CloudViewer_implclEv + 963
8 libboost_thread-mt.dylib 0x000000010a97524a thread_proxy + 186
9 libsystem_pthread.dylib 0x00007fff90f9f899 _pthread_body + 138
10 libsystem_pthread.dylib 0x00007fff90f9f72a _pthread_struct_init + 0
11 libsystem_pthread.dylib 0x00007fff90fa3fc9 thread_start + 13
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Abort trap: 6
Out of curiosity, why have a tutorial on your website for something that is deprecated?
Experiencing this same issue with the region growing tutorial just fyi
How did you guys make sure spinOnce is only called from the main thread? Can anyone post a code snippet please?
Sorry, I am super late. What is the final solution for this thread? I am running into a similar or identical situation.
I ran into this issue when trying the region growing segmentation example. Solved it by using the PCLVisualizer class instead of CloudViewer.
The PCLVisualizer has the same problem, actually.