)
at /usr/include/c++/7/bits/std_function.h:316
```
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [February 4, 2020, 8:41pm UTC](https://discourse.kitware.com/t/introduction-to-rgg-session/355/5 "2020-02-04T20:41:05Z")
That part of the stack trace indicates that the RGG session is trying to use the new smtk::geometry::Geometry… what resource type does it inherit? If it inherits the VTK session’s resource, then it will need to be updated to use the new rendering backend (this should also improve speed).
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [February 4, 2020, 8:43pm UTC](https://discourse.kitware.com/t/introduction-to-rgg-session/355/6 "2020-02-04T20:43:00Z")
When I look at the RGG repo, it does not appear to inherit the VTK session’s resource. So… I am surprised that this code is exercised at all.
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [February 4, 2020, 9:17pm UTC](https://discourse.kitware.com/t/introduction-to-rgg-session/355/7 "2020-02-04T21:17:39Z")
Some followup: via both debugger and std::cout, we verified that the size of the resource’s `m_geometry` map was 0 but nonetheless, `for (auto& entry : m_geometry) { ... }` was invoking code inside the loop (on what was clearly nonsense, since the map was empty). Looks like either memory stomping or a compiler error.
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [February 4, 2020, 9:43pm UTC](https://discourse.kitware.com/t/introduction-to-rgg-session/355/8 "2020-02-04T21:43:23Z")
On a lark, try iterating `m_geometry` in a different way (e.g. use iterators explicitly, or a good old-fashioned `for` loop).
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [February 4, 2020, 9:44pm UTC](https://discourse.kitware.com/t/introduction-to-rgg-session/355/9 "2020-02-04T21:44:59Z")
Simply putting an `if (m_geometry.empty()) { return; }` before the loop was enough to get past the crash. But that’s not something I would commit to the repo until we know what it causing the problem.
---
### Author:  [@aron.helser](https://discourse.kitware.com/u/aron.helser)
#### Post date: [February 4, 2020, 9:53pm UTC](https://discourse.kitware.com/t/introduction-to-rgg-session/355/10 "2020-02-04T21:53:05Z")
Something must be messing with memory. Updated to smtk master, rebuilt, now I get this printout (reversed from the last one):
```auto
> 4 0x7f48ff46b2cb smtk::geometry::Manager::visitBackends(std::function) const + 187
> 3 0x7f48ff469dd4 smtk::geometry::Resource::geometry(smtk::geometry::Backend const&) + 324
> 2 0x7f48ff46ab36 smtk::common::Generator, smtk::geometry::Backend const&>, std::unique_ptr >, smtk::common::detail::NullGeneratorBase>::operator()(std::tuple, smtk::geometry::Backend const&> const&) + 246
> 1 0x7f48f3bcbf27 smtk::session::polygon::vtk::RegisterPolygonVTKBackend::valid(std::tuple, smtk::geometry::Backend const&> const&) const + 39
> 0 0x7f49292e6890 /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890) [0x7f49292e6890]
```
In any case, modelbuilder has never functioned correctly for me after I click ‘reset server’ - after opening a file, the resource panel doesn’t populate. We could go down this rabbit hole, or concentrate on behavior when RGG is auto-loaded.
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [February 4, 2020, 10:45pm UTC](https://discourse.kitware.com/t/introduction-to-rgg-session/355/11 "2020-02-04T22:45:03Z")
I suspect that ‘reset server’ is doing something naughty. It would be nice to understand what it is doing (perhaps with valgrind?), but I agree getting RGG working on auto-load is the priority and should also be the easier thing to do (since you know how to discover what is resetting the selection).
---
### Author:  [@aron.helser](https://discourse.kitware.com/u/aron.helser)
#### Post date: [February 5, 2020, 9:59pm UTC](https://discourse.kitware.com/t/introduction-to-rgg-session/355/12 "2020-02-05T21:59:39Z")
RGG session was clearing the selection intentionally: [MR](https://gitlab.kitware.com/cmb/plugins/rgg-session/merge_requests/60)
The purpose was to avoid drawing the geometry with the purple selection color. Ideas on how to avoid that without clearing the selection?
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [February 5, 2020, 10:16pm UTC](https://discourse.kitware.com/t/introduction-to-rgg-session/355/13 "2020-02-05T22:16:23Z")
I don’t see an easy way. There might be a hack or two in addition to the “right way.”
- Instead of emptying the selection, maybe changing the selection value to something non-standard would leave the part selected but not highlighted? I don’t remember offhand how selected bits are processed by the representation, but it is possible that selecting the part with a value of 4 (or any value that does not set the lower 2 bits that are used for the primary and hover selections) would render as desired but still register the selection as far as the operation panel is concerned. I would consider this a hack.
- Currently, vtkSMTKResourceRepresentation invokes a function named something like “SelectedFootprint” (search for Footprint) to choose what renderable objects should be highlighted to illustrate a selection. We should at some point allow plugins to provide custom logic. That part is not a hack, but using such a mechanism to prevent highlighting for RGG would be a hack.
- IMNSHO, the non-hack solution is to have a modal workflow such that when users select a part, the operation and resource panels respond by showing tasks contextual to that part. But this will require some work that Bob has yet to do…
---
### Author:  [@aron.helser](https://discourse.kitware.com/u/aron.helser)
#### Post date: [February 6, 2020, 8:36pm UTC](https://discourse.kitware.com/t/introduction-to-rgg-session/355/14 "2020-02-06T20:36:44Z")
> [@dcthomp](#):
>
> Instead of emptying the selection, maybe changing the selection value to something non-standard would leave the part selected but not highlighted?
Looks like RGG is already doing this - the selection label being used is in `smtkRGGSelectionBehavior::m_selectionValue("rgg selected")`. This results in selected pins and ducts not being drawn with the selected color, but assemblies and the core have a boundary that is still drawn with the selected color. I’ll investigate why the boundary doesn’t get the new selection label.
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [February 6, 2020, 8:38pm UTC](https://discourse.kitware.com/t/introduction-to-rgg-session/355/15 "2020-02-06T20:38:23Z")
This is probably a difference between how glyphs and “regular” surfaces are handled by the representation. They should behave the same way.