kicad-developers team mailing list archive

Thread
Date
Re: Stability drive? [was Re: Version 6 release schedule]

To: Ruth Ivimey-Cook <ruth@xxxxxxxxxx>
From: Jon Evans <jon@xxxxxxxxxxxxx>
Date: Mon, 8 Nov 2021 11:49:23 -0500
Cc: KiCad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
In-reply-to: <ee0a64b0-180a-247e-3c10-df8e818b71cf@ivimey.org>
I certainly agree with a stability drive, I would just caution to not
assume that the devs see the same issues you do, and therefore are ignoring
the stability problems you see.

> Finally, I know issues that are GTK or WX based might be hard or even
impossible for Kicad to fix, but in the past I have often found it best to
fix them (if possible) anyway because they could be hiding other issues,
either in a wood-trees way or because of side effects. The same applies to
warnings from the compiler, etc.

I agree with this in principle, but in practice, some of these issues are
either inconsequential (such as the GTK warnings), very hard to figure out
how to fix, or both.
We always welcome people to work on these issues, but if they don't result
in an actual impact to KiCad users, and they are hard to fix (or require
upstream changes to fix), it is hard to prioritize them internally in the
KiCad dev team.

-Jon

On Mon, Nov 8, 2021 at 11:46 AM Ruth Ivimey-Cook <ruth@xxxxxxxxxx> wrote:

> Jon,
>
> I realize there was a lot of content, but I also know that little of it
> was of very much use, because in most cases the issues seen have not been
> repeatable. I will see what I can do, though.
>
> Mostly, this mail was about making the case for the devs to agree to a
> stability drive, and go looking for problems.
>
> Finally, I know issues that are GTK or WX based might be hard or even
> impossible for Kicad to fix, but in the past I have often found it best to
> fix them (if possible) anyway because they could be hiding other issues,
> either in a wood-trees way or because of side effects. The same applies to
> warnings from the compiler, etc.
>
> Regards,
>
> Ruth
>
>
> On 08/11/2021 16:38, Jon Evans wrote:
>
> Hi Ruth,
>
> Thanks for the notes.  There is a lot of content in your email, and I
> worry it will get lost if it doesn't get split up into multiple issues on
> the issue tracker.
>
> Some of the issues you mention (GTK warnings, ASan issues related to
> Python, etc) are known issues and we don't plan to fix them at this time
> because we don't think they relate to any actual stability issues that
> KiCad users will experience or observe when running a release build.  Some
> of these are caused by wxWidgets itself, and some will be fixed when we
> move away from SWIG for the Python API in V7.
>
> Any of the issues you mention that are actually KiCad issues should get
> addressed if possible.  However, each of them will require its own
> discussion thread, maybe including more specific reproduction steps,
> example projects that cause the issue, etc.  We'd really appreciate it if
> you could report the crashes and other misbehavior you see on GitLab (or
> via the Report Bug entry in the Help menu) one by one, so that they can be
> addressed.
>
> Best,
> Jon
>
> On Mon, Nov 8, 2021 at 11:12 AM Ruth Ivimey-Cook <ruth@xxxxxxxxxx> wrote:
>
>> From my recent experience with self-built flatpak versions of KiCad 5.99
>> (head), I love the recent changes in the program.
>>
>> I also feel there is an amount of work still needed to improve stability.
>> I would suggest people use the program from a debug build with address
>> sanitisation enabled, which among other things enables the Wx assertions.
>> (I would encourage devs to include more assertions in the kicad code as
>> well!)
>>
>> I have had several crashes recently, though only a few repeatably. There
>> is a bug somewhere in the pcb track drag code when lots of suggested track
>> segments are being created/deleted, perhaps to do with an out of bounds
>> (indexing) error; there is a bug that can put "-1" in the Line Style of
>> netclasses and perhaps in other properties too (reported elsewhere); there
>> is a bug somewhere that spams the console with "pixman_region32_init_rect:
>> Invalid rectangle passed" when accessing menus; there is another that threw
>> this:
>>
>> /usr/include/c++/11.2.0/bits/stl_vector.h:1063: std::vector<_Tp,
>> _Alloc>::const_reference std::vector<_Tp,
>> _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) const [with _Tp =
>> VECTOR2<int>; _Alloc = std::allocator<VECTOR2<int> >; std::vector<_Tp,
>> _Alloc>::const_reference = const VECTOR2<int>&; std::vector<_Tp,
>> _Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()'
>> failed.
>>
>> ... but where from I know not. There is another in eeschema to do with
>> replacing a symbol footprint using the footprint chooser, though I cannot
>> replicate it and the trace (below) is unhelpful.
>>
>> The memory leak detector shows a lot of memory leaks on exit, though
>> mostly related to Python Eval and to Wx fonts / pango. This latter group
>> might be all Wx, fontconfig or pango's fault, not kicad --
>> wxCairoContext::GetTextExtent is one common denominator,
>> wxWindow::GetCharHeight is another. [[ I did attempt to compile with
>> wxwindows head, which is significantly advanced over the 3.1.5 currently
>> being used, but sadly wxpython doesn't build against head (probably not a
>> big thing - there's a patch already which might just need extending).
>> Probably worth pursuing a little though. ]]
>>
>> The python leaks are mostly from dictresize, and I think they result from
>> old dict memory, rather than being directly freed on resize, being added to
>> the keys_free_list and then never freed from that. See
>> https://github.com/python/cpython/blob/9942f42a93ccda047fd3558c47b822e99afe10c0/Objects/dictobject.c#L1281
>> . In turn this would suggest _PyDict_ClearFreeList / _PyDict_Fini is
>> never called.
>>
>> I also think there is a regression: when selecting things at a Via, the
>> Via itself is always selected and the normal select-what menu list doesn't
>> appear. This makes it impossible to select anything within the area of a
>> Via unless you move the Via first. The select-what does appear in other
>> cases. I'm not 100% sure, but I think I've seen similar behaviour where
>> tracks are selected when a graphic line could also have been selected. I
>> may be wrong there though.
>>
>> Relating to Wx and HiDPI displays, even compiled with wx 3.1.5, many of
>> the text widgets are too small (by roughly the factor of the DPI adjustment
>> my display is using, 1.75) and either in consequence or also, the default
>> window sizes are also too small, not encompassing their content.
>>
>> Finally, I have frequently been surprised by windows being raised or not
>> raised. For example, I did a DRC check last night having not started
>> eeschema in that session. The previous session had crashed, so when DRC
>> started eeschema, eeschema posted an 'oops' message dialog asking to
>> recover. All well and good, except the pcbnew window obscured both eeschema
>> and its oops dialog, and pcbnew was left hung as if it had died. I did
>> eventually realize it hadn't, and why, but it was not at all obvious.
>>
>> Another weirdness is that if I add a new part in eeschema, then update
>> pcbnew, once I say 'do update', the eeschema window is raised with the part
>> highlighted, obscuring the update dialog and its dialog with its close
>> button. It is easy to recover from this but also startling and a bit
>> annoying - I don't need eeschema to be raised and highlight the part in
>> that case, ever.
>>
>> I hope this report is somewhat useful,
>>
>> Best wishes,
>>
>> Ruth
>>
>>
>> $ flatpak run --devel org.kicad.KiCad.Nightly
>> 04:35:27: Debug: ScreenToClient cannot work when toplevel window is not
>> shown
>> 04:35:37: Debug: ScreenToClient cannot work when toplevel window is not
>> shown
>> ==2==WARNING: ASan is ignoring requested __asan_handle_no_return: stack
>> type: default top: 0x7ffe6a8e1000; bottom 0x7f28c4074000; size:
>> 0x00d5a686d000 (917621886976)
>> False positive error reports may follow
>> For details see https://github.com/google/sanitizers/issues/189
>> =================================================================
>> ==2==ERROR: AddressSanitizer: stack-use-after-scope on address
>> 0x7f28c4076730 at pc 0x7f28d293c2e7 bp 0x7f28c4076700 sp 0x7f28c4075ea8
>> WRITE of size 24 at 0x7f28c4076730 thread T0
>>     #0 0x7f28d293c2e6 in __interceptor_sigaltstack.part.0
>> (/usr/lib/x86_64-linux-gnu/libasan.so.6+0x582e6)
>>     #1 0x7f28d29a26a5 in __asan::PlatformUnpoisonStacks()
>> (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xbe6a5)
>>     #2 0x7f28d29a84e4 in __asan_handle_no_return
>> (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xc44e4)
>>     #3 0x7f28bf648bbf  (/app/bin/_eeschema.kiface+0x885bbf)
>>     #4 0x7f28c084f783  (/app/bin/_eeschema.kiface+0x1a8c783)
>>     #5 0x7f28c0431de1  (/app/bin/_eeschema.kiface+0x166ede1)
>>     #6 0x7f28c04327ef  (/app/bin/_eeschema.kiface+0x166f7ef)
>>     #7 0x7f28bfe30d79  (/app/bin/_eeschema.kiface+0x106dd79)
>>     #8 0x7f28c1180d3d  (/app/bin/_eeschema.kiface+0x23bdd3d)
>>     #9 0x7f28c11810ea  (/app/bin/_eeschema.kiface+0x23be0ea)
>>     #10 0x7f28d1d8329d in
>> wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&,
>> wxEvtHandler*, wxEvent&) (/app/lib/libwx_baseu-3.1.so.5+0x21729d)
>>     #11 0x7f28d1d8377e in wxEvtHandler::SearchDynamicEventTable(wxEvent&)
>> (/app/lib/libwx_baseu-3.1.so.5+0x21777e)
>>     #12 0x7f28d1d83b2c in wxEvtHandler::TryHereOnly(wxEvent&)
>> (/app/lib/libwx_baseu-3.1.so.5+0x217b2c)
>>     #13 0x7f28d1d83bdf in wxEvtHandler::ProcessEventLocally(wxEvent&)
>> (/app/lib/libwx_baseu-3.1.so.5+0x217bdf)
>>     #14 0x7f28d1d83cf1 in wxEvtHandler::ProcessEvent(wxEvent&)
>> (/app/lib/libwx_baseu-3.1.so.5+0x217cf1)
>>     #15 0x7f28d243d384 in wxWindowBase::TryAfter(wxEvent&)
>> (/app/lib/libwx_gtk3u_core-3.1.so.5+0x5a8384)
>>     #16 0x7f28d1d85553 in wxEvtHandler::SafelyProcessEvent(wxEvent&)
>> (/app/lib/libwx_baseu-3.1.so.5+0x219553)
>>     #17 0x7f28d2286cc4  (/app/lib/libwx_gtk3u_core-3.1.so.5+0x3f1cc4)
>>     #18 0x7f28d0e53577 in _g_closure_invoke_va
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x16577)
>>     #19 0x7f28d0e6d82a in g_signal_emit_valist
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x3082a)
>>     #20 0x7f28d0e6da42 in g_signal_emit
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x30a42)
>>     #21 0x7f28d11d6357 in gtk_real_button_released
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x156357)
>>     #22 0x7f28d0e53577 in _g_closure_invoke_va
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x16577)
>>     #23 0x7f28d0e6d82a in g_signal_emit_valist
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x3082a)
>>     #24 0x7f28d0e6da42 in g_signal_emit
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x30a42)
>>     #25 0x7f28d11d452c in multipress_released_cb
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x15452c)
>>     #26 0x7f28d14b18bc in _gtk_marshal_VOID__INT_DOUBLE_DOUBLEv
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x4318bc)
>>     #27 0x7f28d0e53577 in _g_closure_invoke_va
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x16577)
>>     #28 0x7f28d0e6d82a in g_signal_emit_valist
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x3082a)
>>     #29 0x7f28d0e6da42 in g_signal_emit
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x30a42)
>>     #30 0x7f28d12aa019 in gtk_gesture_multi_press_end
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x22a019)
>>     #31 0x7f28d0e56922 in g_cclosure_marshal_VOID__BOXEDv
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x19922)
>>     #32 0x7f28d0e53577 in _g_closure_invoke_va
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x16577)
>>     #33 0x7f28d0e6d82a in g_signal_emit_valist
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x3082a)
>>     #34 0x7f28d0e6da42 in g_signal_emit
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x30a42)
>>     #35 0x7f28d12a6d47 in _gtk_gesture_check_recognized
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x226d47)
>>     #36 0x7f28d12a858a in gtk_gesture_handle_event
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x22858a)
>>     #37 0x7f28d12ab99d in gtk_gesture_single_handle_event
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x22b99d)
>>     #38 0x7f28d126f1c4 in gtk_event_controller_handle_event
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x1ef1c4)
>>     #39 0x7f28d144f525 in _gtk_widget_run_controllers
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x3cf525)
>>     #40 0x7f28d14ab440 in _gtk_marshal_BOOLEAN__BOXED
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x42b440)
>>     #41 0x7f28d0e53348 in g_closure_invoke
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x16348)
>>     #42 0x7f28d0e664a2 in signal_emit_unlocked_R
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x294a2)
>>     #43 0x7f28d0e6d1ba in g_signal_emit_valist
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x301ba)
>>     #44 0x7f28d0e6da42 in g_signal_emit
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x30a42)
>>     #45 0x7f28d1450ea3 in gtk_widget_event_internal.part.0
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x3d0ea3)
>>     #46 0x7f28d12f609e in propagate_event
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x27609e)
>>     #47 0x7f28d12f7cab in gtk_main_do_event
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x277cab)
>>     #48 0x7f28d0063191 in _gdk_event_emit
>> (/usr/lib/x86_64-linux-gnu/libgdk-3.so.0+0x3f191)
>>     #49 0x7f28d00993ae in gdk_event_source_dispatch
>> (/usr/lib/x86_64-linux-gnu/libgdk-3.so.0+0x753ae)
>>     #50 0x7f28d0d5f2a0 in g_main_context_dispatch
>> (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x592a0)
>>     #51 0x7f28d0d5f547 in g_main_context_iterate.constprop.0
>> (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x59547)
>>     #52 0x7f28d0d5f862 in g_main_loop_run
>> (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x59862)
>>     #53 0x7f28d12f6d84 in gtk_main
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x276d84)
>>     #54 0x7f28d221eb04 in wxGUIEventLoop::DoRun()
>> (/app/lib/libwx_gtk3u_core-3.1.so.5+0x389b04)
>>     #55 0x7f28d1c3c2d9 in wxEventLoopBase::Run()
>> (/app/lib/libwx_baseu-3.1.so.5+0xd02d9)
>>     #56 0x7f28c118081c  (/app/bin/_eeschema.kiface+0x23bd81c)
>>     #57 0x7f28c0ab6e54  (/app/bin/_eeschema.kiface+0x1cf3e54)
>>     #58 0x7f28c0aba9a7  (/app/bin/_eeschema.kiface+0x1cf79a7)
>>     #59 0x7f28c15fb504  (/app/bin/_eeschema.kiface+0x2838504)
>>     #60 0x7f28c183c9e0 in make_fcontext
>> (/app/bin/_eeschema.kiface+0x2a799e0)
>>
>> 0x7f28c4076730 is located 1019696 bytes inside of 1048576-byte region
>> [0x7f28c3f7d800,0x7f28c407d800)
>> allocated by thread T0 here:
>>     #0 0x7f28d299e527 in operator new[](unsigned long)
>> (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xba527)
>>     #1 0x7f28c15fc7a0  (/app/bin/_eeschema.kiface+0x28397a0)
>>     #2 0x7f28c15da1f7  (/app/bin/_eeschema.kiface+0x28171f7)
>>     #3 0x7f28c15e98d0  (/app/bin/_eeschema.kiface+0x28268d0)
>>     #4 0x7f28c15ebdd3  (/app/bin/_eeschema.kiface+0x2828dd3)
>>     #5 0x7f28c14dcfc4  (/app/bin/_eeschema.kiface+0x2719fc4)
>>     #6 0x7f28c15eb22d  (/app/bin/_eeschema.kiface+0x282822d)
>>     #7 0x7f28c15f1b49  (/app/bin/_eeschema.kiface+0x282eb49)
>>     #8 0x7f28c15aa0c0  (/app/bin/_eeschema.kiface+0x27e70c0)
>>     #9 0x7f28c1ae4018  (/app/bin/_eeschema.kiface+0x2d21018)
>>     #10 0x7f28d1d8329d in
>> wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&,
>> wxEvtHandler*, wxEvent&) (/app/lib/libwx_baseu-3.1.so.5+0x21729d)
>>     #11 0x7f28d1d8377e in wxEvtHandler::SearchDynamicEventTable(wxEvent&)
>> (/app/lib/libwx_baseu-3.1.so.5+0x21777e)
>>     #12 0x7f28d1d83b2c in wxEvtHandler::TryHereOnly(wxEvent&)
>> (/app/lib/libwx_baseu-3.1.so.5+0x217b2c)
>>     #13 0x7f28d1d83bdf in wxEvtHandler::ProcessEventLocally(wxEvent&)
>> (/app/lib/libwx_baseu-3.1.so.5+0x217bdf)
>>     #14 0x7f28d1d83cf1 in wxEvtHandler::ProcessEvent(wxEvent&)
>> (/app/lib/libwx_baseu-3.1.so.5+0x217cf1)
>>     #15 0x7f28d24ab566 in
>> wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
>> (/app/lib/libwx_gtk3u_core-3.1.so.5+0x616566)
>>     #16 0x7f28d1d85553 in wxEvtHandler::SafelyProcessEvent(wxEvent&)
>> (/app/lib/libwx_baseu-3.1.so.5+0x219553)
>>     #17 0x7f28d224d38d  (/app/lib/libwx_gtk3u_core-3.1.so.5+0x3b838d)
>>     #18 0x7f28d14ab440 in _gtk_marshal_BOOLEAN__BOXED
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x42b440)
>>     #19 0x7f28d0e53348 in g_closure_invoke
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x16348)
>>     #20 0x7f28d0e66a7e in signal_emit_unlocked_R
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x29a7e)
>>     #21 0x7f28d0e6d1ba in g_signal_emit_valist
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x301ba)
>>     #22 0x7f28d0e6da42 in g_signal_emit
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x30a42)
>>     #23 0x7f28d1450ea3 in gtk_widget_event_internal.part.0
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x3d0ea3)
>>     #24 0x7f28d147407a in gtk_window_propagate_key_event
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x3f407a)
>>     #25 0x7f28d2235a45  (/app/lib/libwx_gtk3u_core-3.1.so.5+0x3a0a45)
>>     #26 0x7f28d14ab440 in _gtk_marshal_BOOLEAN__BOXED
>> (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0+0x42b440)
>>     #27 0x7f28d0e53348 in g_closure_invoke
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x16348)
>>     #28 0x7f28d0e66a7e in signal_emit_unlocked_R
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x29a7e)
>>     #29 0x7f28d0e6d1ba in g_signal_emit_valist
>> (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0+0x301ba)
>>
>> SUMMARY: AddressSanitizer: stack-use-after-scope
>> (/usr/lib/x86_64-linux-gnu/libasan.so.6+0x582e6) in
>> __interceptor_sigaltstack.part.0
>> Shadow bytes around the buggy address:
>>   0x0fe598806c90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f2
>>   0x0fe598806ca0: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x0fe598806cb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x0fe598806cc0: 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 f3
>>   0x0fe598806cd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> =>0x0fe598806ce0: f1 f1 f1 f1 f1 f1[f8]f2 f8 f2 f8 f2 f8 f3 f3 f3
>>   0x0fe598806cf0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
>>   0x0fe598806d00: 00 00 00 f2 00 00 00 f2 00 00 00 f2 00 00 00 f2
>>   0x0fe598806d10: 00 00 00 f2 f2 f2 00 00 00 00 00 f3 f3 f3 f3 f3
>>   0x0fe598806d20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>   0x0fe598806d30: f1 f1 f1 f1 f1 f1 01 f2 01 f2 01 f2 01 f2 00 00
>> Shadow byte legend (one shadow byte represents 8 application bytes):
>>   Addressable:           00
>>   Partially addressable: 01 02 03 04 05 06 07
>>   Heap left redzone:       fa
>>   Freed heap region:       fd
>>   Stack left redzone:      f1
>>   Stack mid redzone:       f2
>>   Stack right redzone:     f3
>>   Stack after return:      f5
>>   Stack use after scope:   f8
>>   Global redzone:          f9
>>   Global init order:       f6
>>   Poisoned by user:        f7
>>   Container overflow:      fc
>>   Array cookie:            ac
>>   Intra object redzone:    bb
>>   ASan internal:           fe
>>   Left alloca redzone:     ca
>>   Right alloca redzone:    cb
>>   Shadow gap:              cc
>> ==2==ABORTING
>>
>>
>>
>> On 28/10/2021 22:09, Wayne Stambaugh wrote:
>>
>> The lead development team has agreed on a version 6 release schedule as
>> follows:
>>
>>
>> - String freeze November 1.
>> - Tag RC1 on November 15.
>> - All repos frozen on December 14.
>> - Tag all repos with 6.0.0 on December 15.
>> - 6.0.0 release announcement December 31 (maybe the day before Christmas
>>   just for fun).
>> - Branch V6 and open master for new feature development on January 1.
>>
>> Our goal is to stick to that as closely as possible so if you have any
>> outstanding work, please use this schedule as a reference to get it done.
>>
>> Going forward, we will be following the new stable release policy[1]
>> which will move us to an annual release schedule.
>>
>> Thank you everyone for your continued support of the KiCad project.
>> Hopefully the version 6 release will go reasonably smoothly and we can get
>> started on version 7 in 2022.
>>
>> Cheers,
>>
>> Wayne
>>
>> [1]: https://dev-docs.kicad.org/en/rules-guidelines/release-policy/
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>> --
>> Tel: 01223 414180
>> Blog: http://www.ivimey.org/blog
>> LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> --
> Tel: 01223 414180
> Blog: http://www.ivimey.org/blog
> LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/
>
>
Follow ups

Re: Stability drive? [was Re: Version 6 release schedule]
From: Jon Evans, 2021-11-08
References

Version 6 release schedule
From: Wayne Stambaugh, 2021-10-28
Stability drive? [was Re: Version 6 release schedule]
From: Ruth Ivimey-Cook, 2021-11-08
Re: Stability drive? [was Re: Version 6 release schedule]
From: Jon Evans, 2021-11-08
Re: Stability drive? [was Re: Version 6 release schedule]
From: Ruth Ivimey-Cook, 2021-11-08