Comment 6 for bug 1794570

I am fiddling with my projects from May of 2018. These were created with kicad 5.0.0 RC2 on debian, using the deprecated libraries for kicad 4.
My goal is to prepare the projects such that they work independently of the libraries installed on the system. Then I plan to transition to
kicad 5.0.2 "release" in debian stretch-backports. While doing all this, I stumbled over this issue and a way to reproduce it.

Open the schematic from the provided demo project using kicad 5.0.2. Even if you have all symbols provided by kicad from
https://github.com/KiCad/kicad-symbols enabled, you should be prompted to rescue two symbols: "Mechanical:Mounting_Hole_PAD"
and "Relay:FINDER-40.52". Choose NOT to rescue at least one symbol.

In eeschema, choose Tools -> Edit Symbol Library References...

You'll see an assertion dialog. When clicking "Continue", you'll see one for each symbol instance without a valid library
reference.

ASSERT INFO:
/build/kicad-UO6Edp/kicad-5.0.2+dfsg1/eeschema/component_references_lister.cpp(721): assert "aComponent != __null && aLibPart != __null" failed in SCH_REFERENCE().

BACKTRACE:
[1] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[3] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[4] wxEvtHandler::TryHereOnly(wxEvent&)
[5] wxEvtHandler::DoTryChain(wxEvent&)
[6] wxEvtHandler::ProcessEvent(wxEvent&)
[7] wxWindowBase::TryAfter(wxEvent&)
[8] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[9] wxMenuBase::SendEvent(int, int)
[10] g_closure_invoke
[11] g_signal_emit_valist
[12] g_signal_emit
[13] gtk_widget_activate
[14] gtk_menu_shell_activate_item
[15] g_closure_invoke
[16] g_signal_emit_valist
[17] g_signal_emit
[18] gtk_propagate_event
[19] gtk_main_do_event
[20] g_main_context_dispatch
[21] g_main_loop_run
[22] gtk_main
[23] wxGUIEventLoop::DoRun()
[24] wxEventLoopBase::Run()
[25] wxAppConsoleBase::MainLoop()
[26] wxEntry(int&, wchar_t**)
[27] __libc_start_main
[28] _start

I assume this assertion makes sense, in a way, but in this particular circumstance, it seems that this assertion is expected.