Open gwideman opened 4 months ago
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.
Could you try the upstream version?
I can try that, but it will probably take me a day to get to it.
OK, I have not tried anything new yet.
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.
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%.
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
Update to this issue, using newly updated:
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.
Conclusions:
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"
}
}
+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.
Conversation on this issue seems to have stalled. Anything we can do to help diagnose this issue?
I have the same issue.
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.
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.
@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:
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.
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?
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.
As there are file operations, the GUI works in the following way:
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).
@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: 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.
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?
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?
Sorry but I am hesitant to do this because I find that it usually takes most of a day to install Kikit and actually get it to work, and I am very busy at the moment. Maybe when I have some spare time.
Hello,
same problem for me. KiCad 8.0.6 KiKit V1.0.6
GUI stalls when tryin to generate the board
@Deadeye5589 : It is not helpful to say: "I am also affected," if you don't provide further details. Also, I asked the users to verify if they observed the problem with the current upstream version (not the released one). That is helpful information that can help resolve this issue. Please, if you want to get this fixed, try the upstream version and report if it helped or at least partially helped.
@gwideman: No one so far has been able to give me step-by-step instructions on how to reproduce the issue.
For my part... I just want to apologize for not getting back to this to install the latest stuff and provide some feedback. Life has intervened and I've been swamped.
Prerequisites
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
Of course, if you don't see the stall, then there's some factor outside this repro setup that's somehow in play.