kikit stalls from plugin, but fast from CLI

[gwideman]

Prerequisites

• I have read FAQ
• I have searched existing issues (including closed ones)
• I use KiKit at least version 1.5.1 (older version are not supported)

KiKit version

kikit, version 1.5.1

KiCAD version

8.0.3

Operating system

Windows 10 Pro 10.0.19045

Description

This report may have insufficient detail to spot a cause, but I'm hoping for suggestions on how to help narrow down that cause.

Symptom:
A panelization job, as specified in a json file, runs in seconds from the command line, but when launched from the Kicad PCB kikit plugin UI "Panelize" button, the kikit process stalls for several minutes.

Sample stall time: For a 35x35mm board with 5 SMD ICs and a few dozen other SMD parts, to be panelized 3x4 boards, from CLI it runs in 6 seconds. From plugin UI, it runs in 5 minutes.

Stall time does vary with complexity. A 20mm square board with just one SMD transistor panelized 3x4 takes less than 2 secs for CLI, but 7 secs from plugin UI, so hard to notice much difference.

I have seen this symptom on all of the four boards I tried, on two different PCs, with significantly different kikit parameters (eg: mousebite tabs vs vcuts). I did not see any boards on which kikit UI ran without stalling.

When launched from GUI, the progress bar advances to a certain point (position varies: one example boards stalls at say 10%, another say 40%), then stops there for the majority of the several minutes, then suddenly sprints to 100%.

Inspecting the stalled kikit in Windows Resource monitor, there's no high disk activity (ie: no obvious virtual memory disk thrashing). CPU is about 12%, which is 100% of one "logical processor" on my "4-core, 8 logical processor" i7-6700 machine.

Steps to Reproduce

1. Select a candidate panelization-friendly PCB, say 60x60mm, with 10 ICs and several dozen other components. I don't know if it matters, but all my sample boards had at least one QFP-44.
2. Configure a kikit config json file to create a panel of say 3x3 boards.
3. Run this from the kikit plugin GUI > Panelize button.
4. Observe stall of several minutes
5. Compare to speed running from CLI, likely just a few seconds.

Of course, if you don't see the stall, then there's some factor outside this repro setup that's somehow in play.

[yaqwsx]

Could you try the upstream version? There were some significant changes in the way GUI operates, so I want to be sure the problem is present.

The only difference between CLI and GUI is that after successful penalization, GUI has to copy the panel into the currently open window. It is possible there might be some inefficiency there, I will check it out.

[gwideman]

Could you try the upstream version?

I can try that, but it will probably take me a day to get to it.

[gwideman]

OK, I have not tried anything new yet.

1. I see that there's a new version of Kicad just released (8.0.4). I should probably install that to make any further tests relevant.
2. I see you uploaded revised KiKit to PyPi. That's the backend, right? And shared between CLI and GUI. I can easily install it of course, but I think we're not suspecting that as the culprit, right?
3. I believe it's the GUI plugin that is most suspicious at the moment. I did not see an updated plugin in Plugin and Content Manager yet. Is that imminent?
4. If you still would like me to "try the upstream version", I realize I don't know how to do that. I'm happy to try it if you could point me to a procedure to install the upstream version of whatever is the thing you'd like me to test.

[yaqwsx]

The GUI is part of the backend. The KiCAD plugin is just a tiny loader. Definitely try to reproduce this with the v1.6.0. At the moment, there is no point in trying upstream version as it is the same as the just released v1.6.0.

[shuki25]

I have an exact same problem. It stalled after hitting on the panelize button. I didn't have that issue until I upgraded KiCad to 8.0.4 and kikit to 1.6.0. I even upgraded your GUI backend to 1.6.0.

The overall CPU when stalled is at 3-4%.

[shuki25]

I want to add that it stalls on BOTH Windows version and Mac OS (silicon) Ventura 13.5.1. When hitting panelize button, it crashed. Looks like a segmentation fault as it was trying to access to memory outside of memory region for the process.

Although the panelization was partially done. When I reopened KiCad, all I can see was a generated Edge.Cuts layer but not the rest of the design with all other layers. See screenshot:

Although I could panelize it without any issues if I run from CLI. Both were on KiCad 8.0.4 and I've updated to the most recent versions of kikit (shell command) and kikit-gui (KiCad plug-in).

Below is the crash report:

Process:               pcbnew [33202]
Path:                  /Applications/KiCad/KiCad.app/Contents/Applications/pcbnew.app/Contents/MacOS/pcbnew
Identifier:            org.kicad.pcbnew
Version:               8.0.4 (8.0.4)
Code Type:             ARM-64 (Native)
Parent Process:        kicad [31371]
Responsible:           kicad [31371]
User ID:               501

Date/Time:             2024-07-20 12:20:18.5048 -0400
OS Version:            macOS 13.5.1 (22G90)
Report Version:        12
Anonymous UUID:        94DCB19B-8018-E78F-AD75-5D423B7ED59F


Time Awake Since Boot: 840000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x2626269602020207 -> 0x0000269602020207 (possible pointer authentication failure)
Exception Codes:       0x0000000000000001, 0x2626269602020207

Termination Reason:    Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process:   exc handler [33202]

VM Region Info: 0x269602020207 is not in any region.  Bytes after previous region: 41944684298760  Bytes before following region: 63127395630585
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      commpage (reserved)        1000000000-7000000000   [384.0G] ---/--- SM=NUL  ...(unallocated)
--->  GAP OF 0x5f9000000000 BYTES
      MALLOC_NANO              600000000000-600008000000 [128.0M] rw-/rwx SM=PRV  

Kernel Triage:
VM - (arg = 0x0) pmap_enter retried due to resource shortage
VM - (arg = 0x0) pmap_enter retried due to resource shortage
VM - (arg = 0x0) pmap_enter retried due to resource shortage
VM - (arg = 0x0) pmap_enter retried due to resource shortage

[gwideman]

Update to this issue, using newly updated:

• Kicad 8.0.4
• kikit 1.6.0 plugin installed from Kicad Plugin and Content Manager
• kikit 1.6.0 installed via pip and PyPi

In brief testing I was not able to get kikit to complete error free. Here's a list of what I noted along the way.

1. In kikit's "Panelize a board" dialog, the Input File edit box slot is missing. So the GUI no longer shows what file you have selected (though you can read the CLI command to figure it out.)
2. There's a new Output File button. It also is missing an edit box showing the current selection. But more to the point -- does this represent a change of workflow, or that kikit will save the output file? Because at the moment, having kikit NOT save the output file is good because it supports iterating on the parameters and generating the panel into the open Kicad PCB Editor window to check the results. Maybe the idea of the Output File was just to show the composed CLI command?
3. With a source PCB and JSON file (that I had used in a previous run, hence comparable), I tried running the Panelize button.

• The "Running kikit" dialog appears, progress bar advances to perhaps 10% then stops.
• After 10 secs, the kikit UI flashes and the titlebar changes to "Running kikit (Not Responding)".
• After 2:40, an error dialog appears "Cannot perform: 'PCB_TEXT' object has no attribute 'GetWidth' " The previously-stalled progress bar changes to rapidly scanning bar ( "indeterminate mode").
• If I dismiss that error dialog, the progress bar abruptly goes to 100%, and a panel appears in PCB Editor. But I don't know if it's actually complete, given the error condition that likely interrupted composition of the panel.
• If I don't dismiss that error dialog, but instead click on either the kikit or PCB Editor window, the error dialog disappears behind and now there's no way to proceed. Neither kikit not PCB Editor respond to UI interaction, and there's no way I could find to bring the error dialog to the front to dismiss it. So this requires killing Kicad from Task Manager.

Conclusions:

1. The lengthy hang that's the main topic of this issue does not appear to be solved by the Kicad or kikit updates.
2. I have mentioned some other issues in Kikit that may not be directly pertinent to the current issue, and if warranted I can create separate issues..

JSON settings used:

{
    "layout": {
        "hspace": "0.mm",
        "rows": "3",
        "cols": "4"
    },
    "tabs": {
        "type": "full"
    },
    "cuts": {
        "type": "vcuts",
        "clearance": "0.2mm",
        "layer": "Edge.Cuts"
    },
    "framing": {
        "type": "frame",
        "hspace": "0mm",
        "vspace": "0mm",
        "width": "10mm",
        "maxtotalheight": "300mm",
        "maxtotalwidth": "300mm"
    },
    "text": {
        "type": "simple",
        "voffset": "3mm",
        "text": "[REDACTED]        07 JUL 2024       2024 [REDACTED]       STEP= xxxx"
    },
    "post": {
        "origin": "bl",
        "dimensions": "True"
    }
}

[elessargr]

+1
also impacted from this.
Dont know why its getting stuck/stalls which in the end crushes the KiCad.

Can we download the 1.5.x version (unofficial upstream version) that was before the 1.6.0 release?
For me that was working fine.

[gwideman]

Conversation on this issue seems to have stalled. Anything we can do to help diagnose this issue?

[dartrax]

I have the same issue.

[CreativeRobotics]

I've never use the CLI but since installing the latest update KiKit has been painfully slow whe I use it with the UI, and this issue looks like the reason why. I now find myself waiting up to 20 minutes for it to panelise some boards despite my computer CPU's GPU's and disks doing very little for most of that time.

[gwideman]

I've never use the CLI but since installing the latest update KiKit has been painfully slow whe I use it with the UI, and this issue looks like the reason why. I now find myself waiting up to 20 minutes for it to panelise some boards despite my computer CPU's GPU's and disks doing very little for most of that time.

Yeah, it's a bit disappointing that this hasn't been addressed, and I'm still hoping for some suggestion as to how to help diagnose the problem. But that said, it's well worth trying out the command line approach, which is both fast and actually quite convenient. So I encourage you to try it out and not get stalled with the GUI issue.

[yaqwsx]

@gwideman: No one so far has been able to give me step-by-step instructions on how to reproduce the issue. All inputs were processed, but none of them led to a crash. Believe me, it is really hard to fix a bug that you cannot trigger. Saying "Hey, I also suffer from this" without providing any other info is not helping. I know that there are users suffering from this issues, but that's it. Your reports are better, but e.g., you haven't provided the input files.

It is definitely possible that KiKit does something shady (we are on the edge of what the API allows for), however, a specific combination of something triggers this erroneous behavior. And I wasn't able to trigger it so far, hence, I cannot diagnose it.

There's a new Output File button. It also is missing an edit box showing the current selection. But more to the point -- does this represent a change of workflow, or that kikit will save the output file? Because at the moment, having kikit NOT save the output file is good because it supports iterating on the parameters and generating the panel into the open Kicad PCB Editor window to check the results. Maybe the idea of the Output File was just to show the composed CLI command?

The intended KiKit workflow is:

• use GUI to tweak the panel design (you can quickly iterate as you quickly see the result) and then,
• use the preset or CLI options to integrate it into your build process.
• You are not supposed to ever save the files generated by GUI and use it for production.

Why? KiCAD's API regarding DRC, project, paper size is non-existent. We handle these cases via direct manipulation of the output files. And there is no way in the current API to bring these changes into the currently opened file in Pcbnew However, people complained that this is not what they want. They want to click in the GUI and directly use the output. Hence, the change of GUI - we ask the user for the output file so the user gets a valid file. And we render a huge text warning that says, you are not supposed save this preview, but instead, use the file on the disk.

[yaqwsx]

FYI: I just rebased an experimental branch (ui_stall) on top of current upstream. It is a long shot, but it could help here. Overall, the changes made should ensure the OS doesn't consider KiCAD to be frozen. Could you try installing it via pip install https://github.com/yaqwsx/KiKit/archive/ui_stall.zip and test if it addresses this issue?

[CreativeRobotics]

Maybe there is no crash, but its just taking so long that some people think it has crashed, and kill the process using the task manager? - this is what I did a few times with the latest update before I discovered that I just had to leave it for as long as it needed. I also found that the time it takes to run varies significantly with the complexity of the board design, and boards that take longer to panelise in Kikit also take longer to open in KiCad

Its been suggested that the problem may be to do with loading the panel data into the preview window? If this is the case then is it possible to include a work around in the UI with a checkbox to 'show preview' ... or something like that?

Its a slightly less convienient workflow but re-openming the finished file to check it would be far faster than waiting for Kikit to finish and load the preview ... assuming that is the cause.

[yaqwsx]

As there are file operations, the GUI works in the following way:

• a panel is generated into a temporary file, and
• then, the panel is brought to the current window in Pcbnew.

The experimental branch ui_stall shows which operation is currently in progress. I am under the impression that the currently opened board manipulation got notably slower in KiCAD 8 at least on some computers – we haven't faced any problems before.

I'll wait for the feedback of the affected users, then I will decide what we can do about it (though, looking at the current API, I am afraid, not much).

[yaqwsx]

@CreativeRobotics:

I've never use the CLI but since installing the latest update KiKit has been painfully slow whe I use it with the UI, and this issue looks like the reason why.

If you can track down which KiKit version is fast, I can compare them. As I generally struggle to reproduce this issue, I can't do it on my own.

[CreativeRobotics]

@CreativeRobotics:
If you can track down which KiKit version is fast, I can compare them. As I generally struggle to reproduce this issue, I can't do it on my own.

All I can tell you is that it got slow when I upgraded to the version that askes for an output file. All the versions before this were fast for me.

If it helps, I am on Windows 10, on a Dell precision mobile workstation with a CPU that is just old enough to be non-upgradeable to windows 11.

[yaqwsx]

To avoid hunting ghosts, could you install the version you are referring to, validate that it is actually faster/not stalling, and give me the precise version number?