Re: [Kicad-developers] Stability drive? [was Re: Version 6 release schedule]

[Jon Evans]

To give another example:  the wxWidgets team knows that better HiDPI
support is needed, and has been working on it.

I don't have access to a system where I would prefer to run at a scaling
factor other than 1, so I'm not sure what issues you see.  If you report
them, we can determine:

- is the issue in wx or kicad?
- if in wx, is the wx team already tracking it?

We usually do not have the resources to fix upstream wxWidgets bugs
ourselves, except for cases where we can make fixes to our fork for macOS
or Windows (the burden is obviously higher to get something upstreamed for
Linux users).  However, if we at least know that a problem exists upstream,
than we can track it and volunteer devs who may have time to work on it can
find it.

-Jon

On Mon, Nov 8, 2021 at 11:49 AM Jon Evans  wrote:

> 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  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  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; _Alloc = std::allocator >; 

Re: [Kicad-developers] Stability drive? [was Re: Version 6 release schedule]

[Jon Evans]

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  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  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; _Alloc = std::allocator >; std::vector<_Tp,
>> _Alloc>::const_reference = const VECTOR2&; 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 

Re: [Kicad-developers] Stability drive? [was Re: Version 6 release schedule]

[Ruth Ivimey-Cook]

  
  
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  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; _Alloc =
  std::allocator >;
  std::vector<_Tp, _Alloc>::const_reference = const
  VECTOR2&; 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 

Re: [Kicad-developers] Stability drive? [was Re: Version 6 release schedule]

[Jon Evans]

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  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; _Alloc = std::allocator >; std::vector<_Tp,
> _Alloc>::const_reference = const VECTOR2&; 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