Solderjumper bug?

Layout
1

I’m running into an odd effect with the SolderJumper-2 from the library and how it interacts with a filled zone. When I first create it, it’s good. One side is supposed to connect to the filled zone and it does.

mss-good

After a while of working with the board and some number of zone refills, it gets broken and does this. Now both pads are connected to the filled zone.

mss-bad

It’s like it’s forgotten to leave space around the footprint’s pads. Sometimes if I move the footprint around then it’ll work again for a while. Sometimes not. And if I kill and restart pcb-new then it works again for a while.

In another place I have a three-pad jumper which never seems to have this problem. At least I haven’t seen it fail yet. Any idea what’s going on or how I might work around the problem? Thanks for any help.

The KiCad files can be found here, if that helps: GitHub - dabridgham/MSS-Crossover-Tiny: An MSS Crossover Node

And here’s the KiCad version info:

Application: KiCad PCB Editor x86_64 on x86_64

Version: 8.0.8+dfsg-1, release build

Libraries:
wxWidgets 3.2.6
FreeType 2.13.3
HarfBuzz 10.1.0
FontConfig 2.15.0
libcurl/8.12.1 OpenSSL/3.4.1 zlib/1.3.1 brotli/1.1.0 zstd/1.5.6 libidn2/2.3.7 libpsl/0.21.2 libssh2/1.11.1 nghttp2/1.64.0 nghttp3/1.6.0 librtmp/2.3 OpenLDAP/2.6.9

Platform: Debian GNU/Linux trixie/sid, 64 bit, Little endian, wxGTK, X11, fluxbox, x11
OpenGL: NVIDIA Corporation, NVIDIA GeForce GTX 1050/PCIe/SSE2, 4.6.0 NVIDIA 535.216.03

Build Info:
Date: Jan 12 2025 08:43:51
wxWidgets: 3.2.6 (wchar_t,wx containers) GTK+ 3.24
Boost: 1.83.0
OCC: 7.8.1
Curl: 8.11.1
ngspice: 44.2
Compiler: GCC 14.2.0 with C++ ABI 1019

Build settings:

2

Works for me. I can select the whole footprint, select drag with D, then after placing it, type B, the fill gets refreshed and it avoids the 7A pad.

image
image800×400 30.8 KB

Typing ` on each pad shows that they are distinct nets. The copper rectangle in the middle is because it’s a bridged jumper.

KiCad 8.0.9.

3

It works for me too, at first. And then for a while thereafter. Then at some point, and I haven’t figured out what causes it to flip, it stops working. It starts doing what I showed in that second image and it continues doing that until I restart pcb-new.

Ah! I may have figured it out. It has to do with running DRC. The first DRC works but filling the zones after running DRC then produces the problem. At least it’s looking like that’s the trigger.

4

If you can reliably reproduce it then submit a bug report.

5

Until just now, it happened to me regularly but I couldn’t reproduce it on demand. Now I think I can. I’ll see if I can figure out the bug report system. That’s on gitlab, right?

6

Fastest way is from Help > Report Bug

But upgrade to 8.0.9 just in case because someone is sure to point this out. Oh, I just did. :wink:

7

I’m just using the version that’s in the Debian testing release. It looks like the unstable release has 9.0.0 so that’s probably the next one I’ll get. I’ve never had much luck when I’ve tried downloading the source and building it myself. There are just too many dependencies and I never get them right.

8

I agree that this looks very much like a bug, and a bug report should be created. Bugs have to be able to be re-created before they can be fixed. It helps if the state of your project actually shows a moment where the GND zone is rendered incorrectly.

9
10

Thanks, eelik. That looks like some really useful information for the next time I try building from sources.

And thanks everyone, I’ve entered a bug report, issue 20130. Hopefully I was clear.

11

Looks like someone else had already reported the bug and I just didn’t find it. And it’s been fixed in 8.0.9 like retiredfeline suspected. Oh well.

12

I agree that bugs should always be reported.

This is false. It’s much easier if the bug can be recreated at will, but it’s not an absolute necessity.

A bug report must include enough information to allow a programmer to analyze the problem, identify the cause, and develop a fix. Sometimes it’s not possible to reproduce the bug at will, but this is no excuse for not attempting to identify the problem.