Inconsistent segmentation fault

[havokraven]

I have the script running in a CI pipeline with the following args:

InteractiveHtmlBom/generate_interactive_bom.py --include-tracks --include-nets --no-browser --extra-data-file BOARDNAME.net --extra-fields "Datasheet" BOARDNAME.kicad_pcb

Where BOARDNAME is the name of the kicad project/board. This has worked fine on one design, but attempting to generate an ibom for a different board altogether causes a segmentation fault to occur. I've been able to reproduce the fault in a VM to get a core dump:

           PID: 21602 (generate_intera)
           UID: 1000 (user)
           GID: 1000 (user)
        Signal: 11 (SEGV)
     Timestamp: Wed 2025-01-22 14:56:07 UTC (16h ago)
  Command Line: /usr/bin/python3 /home/user/InteractiveHtmlBom/InteractiveHtmlBom/generate_interactive_bom.py --include-tracks --include-nets --no-browser --extra-data-file FAULTBOARD.net --extra-fields Datasheet FAULTBOARD.kicad_pcb
    Executable: /usr/bin/python3.8
 Control Group: /user.slice/user-1000.slice/session-1.scope
          Unit: session-1.scope
         Slice: user-1000.slice
       Session: 1
     Owner UID: 1000 (user)
       Boot ID: f8d9623ee4e14d5cb4b85a6b1bd30a85
    Machine ID: 24357aa653934fce819bd2973b6c947b
      Hostname: debugvm
       Storage: /var/lib/systemd/coredump/core.generate_intera.1000.f8d9623ee4e14d5cb4b85a6b1bd30a85.21602.1737557767000000000000.lz4
       Message: Process 21602 (generate_intera) of user 1000 dumped core.
                
                Stack trace of thread 21602:
                #0  0x00007f796f50e7e4 _ZN7wxMutex4LockEv (libwx_baseu-3.2.so.0 + 0x1e97e4)
                #1  0x00007f796f9911ae _ZN5wxApp6DoIdleEv (libwx_gtk3u_core-3.2.so.0 + 0x3461ae)
                #2  0x00007f796f991337 n/a (libwx_gtk3u_core-3.2.so.0 + 0x346337)
                #3  0x00007f796e3be04e g_main_context_dispatch (libglib-2.0.so.0 + 0x5204e)
                #4  0x00007f796e3be400 n/a (libglib-2.0.so.0 + 0x52400)
                #5  0x00007f796e3be6f3 g_main_loop_run (libglib-2.0.so.0 + 0x526f3)
                #6  0x00007f796eb2a2e7 gtk_dialog_run (libgtk-3.so.0 + 0x1b32e7)
                #7  0x00007f796fa4b41a _ZN15wxMessageDialog9ShowModalEv (libwx_gtk3u_core-3.2.so.0 + 0x40041a)
                #8  0x00007f796f975770 _Z12wxMessageBoxRK8wxStringS1_lP8wxWindowii (libwx_gtk3u_core-3.2.so.0 + 0x32a770)
                #9  0x00007f796fc48672 _ZN8wxLogGui5FlushEv (libwx_gtk3u_core-3.2.so.0 + 0x5fd672)
                #10 0x00007f796f45cd06 _ZN5wxLog15SetActiveTargetEPS_ (libwx_baseu-3.2.so.0 + 0x137d06)
                #11 0x00007f796f452b5c _Z14wxEntryCleanupv (libwx_baseu-3.2.so.0 + 0x12db5c)
                #12 0x00007f79702b50a7 n/a (_core.cpython-38-x86_64-linux-gnu.so + 0x37b0a7)
                #13 0x00000000006b2c44 n/a (python3.8 + 0x2b2c44)
                #14 0x00000000006528c4 n/a (python3.8 + 0x2528c4)
                #15 0x000000000067f788 Py_FinalizeEx (python3.8 + 0x27f788)
                #16 0x00000000006b68dd Py_RunMain (python3.8 + 0x2b68dd)
                #17 0x00000000006b6b4d Py_BytesMain (python3.8 + 0x2b6b4d)
                #18 0x00007f797139b083 __libc_start_main (libc.so.6 + 0x24083)
                #19 0x00000000005fa98e _start (python3.8 + 0x1fa98e)
                
                Stack trace of thread 21624:
                #0  0x00007f7971363376 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0 + 0xf376)
                #1  0x00007f796f213e30 _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE (libstdc++.so.6 + 0xd0e30)
                #2  0x00007f796238cd6c n/a (_pcbnew.so + 0x18c6d6c)
                #3  0x00007f796f219df4 n/a (libstdc++.so.6 + 0xd6df4)
                #4  0x00007f797135c609 start_thread (libpthread.so.0 + 0x8609)
                #5  0x00007f7971496353 __clone (libc.so.6 + 0x11f353)

What's interesting is that the ibom does generate, and is exactly in the directory where it's supposed to go, and looks complete. It's just that at the end of running, something causes python to segfault. This wouldn't be a problem if the segfault didn't cause my CI runner to look at the job as failed.

Due to reasons I can't share the board files publicly, but I can try my best to provide any other available logs.

[qu1ck]

Ibom is purely python code and can't segfault itself.

You are either crashing in kicad's pcbnew module, which is cpp, or wxwidgets. The core dump shows both threads, if you launch under gdb it will tell you which thread specifically caused the crash. If you also install kicad's debug symbols gdb may give better info on what the pcbnew module was doing when crash happened.

There are few things you should try:

1. Update your vm OS/image, python 3.8 is quite old
2. Make sure the project does not pop any warnings when you open it normally in kicad. pcbnew has a tendency to leak those GUI warnings into cli api.
3. Use INTERACTIVE_HTML_BOM_NO_DISPLAY=true env var to suppress ibom's own usage of gui libs.

Also not related to the crash but don't use .net file for your extra data if you have kicad 7 or later, use pcb file itself, less chances to have out of sync data.

[qu1ck]

Oh and also try to cut down the board file to a minimum that reproduces the issue and share that if you can't share the full design.

[havokraven]

Project opens with no warnings or errors in kicad. I tried running with INTERACTIVE_HTML_BOM_NO_DISPLAY=true env var set and it didn't cause a segmentation fault on my vm. This would lead me to assume it's an issue with wxwidgets? In any case it seems to work with no problem now, on my vm at least. All I get is a notice that my custom drawing sheet can't be found but frankly that's not really an issue when generating an ibom as the draw sheet isn't used. It also still works on the file that worked before.

After some testing it looks like it's working fine on my CI runner too. Same notice about the drawing sheet but that's not breaking anything so I'm comfortable with leaving it there. This issue can be closed imo