DRC error with conda environment

[erendn]

We are trying to use conda environment for the tools used by OpenRAM. I have a recipe for klayout (which I got from conda-eda and modified); however, some of our unit tests are failing. This is the setup I used to replicate one of these errors. You can install the conda environment (install_conda.sh) and run the DRC script (run_drc.sh) to see the output below. We are using a specific commit of klayout (which works with Docker). You can see how we build klayout in the conda recipe. How can I solve this issue?

ERROR: Signal number: 11
Address: 0x109
Program Version: KLayout 0.27.4 (2023-01-23 rea1bf40a1)

Backtrace:
/home/erdogan/workspace/miniconda/bin/../lib/libklayout_lay.so.0 +0x29870b lay::signal_handler(int, siginfo*, void*) [:?]
/lib/x86_64-linux-gnu/libc.so.6 +0x43090 __restore_rt [sigaction.c:?]
/home/erdogan/workspace/miniconda/bin/../lib/./libklayout_db.so.0 +0x4e1854 _ZN2db4Cell6shapesEj
/usr/local/klayout/db_plugins/libgds2.so +0x38885 _ZN2db14GDS2ReaderBase13read_boundaryERNS_6LayoutERNS_4CellEb
/usr/local/klayout/db_plugins/libgds2.so +0x3d40f _ZN2db14GDS2ReaderBase7do_readERNS_6LayoutE
/home/erdogan/workspace/miniconda/bin/../lib/./libklayout_db.so.0 +0x51bc47 _ZN2db12CommonReader4readERNS_6LayoutERKNS_17LoadLayoutOptionsE
/home/erdogan/workspace/miniconda/bin/../lib/./libklayout_db.so.0 +0x51294d _ZN2db12CommonReader4readERNS_6LayoutE
/home/erdogan/workspace/miniconda/bin/../lib/./libklayout_db.so.0 +0x6aa582 _ZN2db6Reader4readERNS_6LayoutE
/home/erdogan/workspace/miniconda/bin/../lib/./libklayout_db.so.0 +0xd7699c
/home/erdogan/workspace/miniconda/bin/../lib/./libklayout_db.so.0 +0xd75852
/home/erdogan/workspace/miniconda/bin/../lib/libklayout_rba.so.0 +0x2a79d
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x243197
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x24d70e
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x25041e
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x25552f rb_vm_exec
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x256059
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x2597a2
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x243197
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x24d70e
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x25041e
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x25552f rb_vm_exec
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x25e016 rb_funcallv
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0xb8b17 rb_protect
/home/erdogan/workspace/miniconda/bin/../lib/libklayout_rba.so.0 +0x444dd
/home/erdogan/workspace/miniconda/bin/../lib/libklayout_rba.so.0 +0x48efb
/home/erdogan/workspace/miniconda/bin/../lib/libklayout_gsi.so.0 +0x80809
/home/erdogan/workspace/miniconda/bin/../lib/libklayout_gsi.so.0 +0x80a79
/home/erdogan/workspace/miniconda/bin/../lib/libklayout_tl.so.0 +0xa66a0 _ZN2tl10Executable10do_executeEv
/home/erdogan/workspace/miniconda/bin/../lib/./libklayout_lym.so.0 +0x2bf99 _ZN3lym16MacroInterpreter13execute_macroEPKNS_5MacroE
/home/erdogan/workspace/miniconda/bin/../lib/./libklayout_lym.so.0 +0x3769e _ZNK3lym5Macro3runEv
/home/erdogan/workspace/miniconda/bin/../lib/libklayout_lay.so.0 +0x1246ce _ZN3lay15ApplicationBase3runEv
/home/erdogan/workspace/miniconda/bin/klayout +0x4216
/home/erdogan/workspace/miniconda/bin/../lib/libklayout_rba.so.0 +0x21300
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x243197
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x24d70e
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x25041e
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0x25552f rb_vm_exec
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0xb6771
/home/erdogan/workspace/miniconda/bin/../lib/./libruby.so.3.1 +0xbadb8 ruby_run_node
/home/erdogan/workspace/miniconda/bin/../lib/libklayout_rba.so.0 +0x23396 _ZN3rba15RubyInterpreter10initializeERiPPcPFiS1_S3_E
/home/erdogan/workspace/miniconda/bin/klayout +0x3f13
/home/erdogan/workspace/miniconda/bin/klayout +0x35f9
/lib/x86_64-linux-gnu/libc.so.6 +0x24083 __libc_start_main
/home/erdogan/workspace/miniconda/bin/klayout +0x36a5

[mithro]

Any ideas @proppy?

[klayoutmatthias]

0.27.4 is very old. Do you have change to update to 0.27.13 and try again?

[klayoutmatthias]

Nicely prepared testcase BTW :)

A quick check with 0.28.3 on Ubuntu 22.04 (package from www.klayout.org) shows no crash and no DRC violations:

$ klayout -b -r freepdk45.lydrc -rd input=sram_bank.gds -rd topcell=sram_bank -rd output=sram_bank.drc.report
...
Writing report database: /home/matthias/klayout/testdata/issue-1263/sram_bank.drc.report ..
Total elapsed: 3.650s  Memory: 1114.00M

You can also try version 0.28.3, but the 0.28 branch is still annealing.

Matthias

[proppy]

conda-eda conda channel: https://anaconda.org/LiteX-Hub/klayout/files should have more recent version than 0.27, see https://anaconda.org/LiteX-Hub/klayout/files

@erendn any reason you're staying on 0.27?

[erendn]

@klayoutmatthias - When I try 0.28.3, I get this error. It seems like there is an issue with ruby. This is the setup I used for 0.28.3.

@proppy - We were using 0.27.4 in the Docker image of OpenRAM. @mguthaus might better know why.

I built other tools with python 3.8 and conda-eda/klayout is built with python 3.7. So there is a version conflict when I try to install conda-eda/klayout along with other tools. To try this specific test case with conda-eda/klayout, I installed miniconda with python 3.7, and the error I got is below. I also built klayout with my recipe using python 3.7 and klayout 0.28.3, and I got the same error as above.

ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/libcif.so
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/libdxf.so
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/libgds2.so
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/liblefdef.so
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/libmag.so
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/libnet_tracer.so
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/liboasis.so
ERROR: Unable to load plugin: /usr/local/klayout/db_plugins/libpcb.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libbool_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libcif_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libcommon_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libd25_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libdiff_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libdxf_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libgds2_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libimport_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/liblefdef_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libmag_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libnet_tracer_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/liboasis_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libpcb_ui.so
ERROR: Unable to load plugin: /usr/local/klayout/lay_plugins/libxor_ui.so
ERROR: In freepdk45.lydrc: 'source': Stream has unknown format: sram_bank.gds in Layout::read
ERROR: 'source': Stream has unknown format: sram_bank.gds in Layout::read in Executable::execute
  freepdk45.lydrc:13:in `execute'
  :/built-in-macros/drc_interpreters.lym:27:in `instance_eval'
  :/built-in-macros/drc_interpreters.lym:27:in `execute'

[proppy]

@erendn can you comment in hdl/conda-eda#260 about this affecting you for klayout, that way we can focus the discussion here on klayout and discuss the packaging aspect over there.

[mguthaus]

We are using 27.4 because it was the latest when I debugged using it. It just hasn't been bumped since then.

[erendn]

I managed to find one of the issues. $KLAYOUT_PATH was pointing to another klayout installation, and klayout failed to load those plugins. Now, I'm getting the following error (klayout 0.28.3):

ERROR: In freepdk45.lydrc: 'source': Stream has unknown format: sram_bank.gds in Layout::read
ERROR: 'source': Stream has unknown format: sram_bank.gds in Layout::read in Executable::execute
  freepdk45.lydrc:13:in `execute'
  :/built-in-macros/drc_interpreters.lym:27:in `instance_eval'
  :/built-in-macros/drc_interpreters.lym:27:in `execute'

[erendn]

I fixed this issue by setting $KLAYOUT_PATH to miniconda/lib/klayout.

@proppy - I can reproduce the same issue with conda-eda/klayout if $KLAYOUT_PATH is unset.

[proppy]

@erendn, thanks! filed hdl/conda-eda#281

[klayoutmatthias]

I'm not sure - is this problem fixed?

The stream format error usually means that the stream reader plugins cannot be loaded. In that case, the GDS stream format reader is not available.

The way these plugins are loaded is that KLayout will look up a folder called "db_plugins" next to the "db" library. In my case that is

db_plugins/...
libklayout_db.so -> libklayout_db.so.0.28.3
libklayout_db.so.0 -> libklayout_db.so.0.28.3
libklayout_db.so.0.28 -> libklayout_db.so.0.28.3
libklayout_db.so.0.28.3

"db_plugins" contains .so files with the stream readers:

libcif.so -> libcif.so.0.28.3
libcif.so.0 -> libcif.so.0.28.3
libcif.so.0.28 -> libcif.so.0.28.3
libcif.so.0.28.3
libdxf.so -> libdxf.so.0.28.3
libdxf.so.0 -> libdxf.so.0.28.3
libdxf.so.0.28 -> libdxf.so.0.28.3
libdxf.so.0.28.3
libgds2.so -> libgds2.so.0.28.3
libgds2.so.0 -> libgds2.so.0.28.3
libgds2.so.0.28 -> libgds2.so.0.28.3
libgds2.so.0.28.3
...

$KLAYOUT_PATH should not be involved here.

So now, if "db_plugins" sits somewhere else or there is a problem loading these Libraries, then GDS is not available (among all other formats).

If the .so files are there and cannot be loaded you can try:

$ klayout -d 31

prints:
...
Loading plugin: /usr/lib/klayout/db_plugins/libcif.so
Loading plugin: /usr/lib/klayout/db_plugins/libdxf.so
Loading plugin: /usr/lib/klayout/db_plugins/libgds2.so
Loading plugin: /usr/lib/klayout/db_plugins/liblefdef.so
Loading plugin: /usr/lib/klayout/db_plugins/libmag.so
Loading plugin: /usr/lib/klayout/db_plugins/libmebes.so
Loading plugin: /usr/lib/klayout/db_plugins/libnet_tracer.so
Loading plugin: /usr/lib/klayout/db_plugins/liboasis.so
Loading plugin: /usr/lib/klayout/db_plugins/libpcb.so
...

or debug the problem mit LD_DEBUG:

$ LD_DEBUG=files klayout -d 31

prints in my case:

...
   1356582:	calling init: /usr/lib/klayout/lay_plugins/libgds2_ui.so
   1356582:	
   1356582:	opening file=/usr/lib/klayout/lay_plugins/libgds2_ui.so [0]; direct_opencount=1
   1356582:	
   1356582:	/usr/lib/klayout/lay_plugins/libgds2_ui.so: error: symbol lookup error: undefined symbol: klp_init (fatal)
Loaded plugin '/usr/lib/klayout/lay_plugins/libgds2_ui.so'
...

The message "error: symbol lookup error: undefined symbol: klp_init (fatal)" is OK - KLayout tries to find a custom initialization entry point which this plugin does not have. Other errors may give you some hint about the solution for your problem.

Matthias

[erendn]

The problem was with the conda environment. KLayout's db_plugins were installed in miniconda/lib/klayout/db_plugins while the other .so files were installed in miniconda/lib. KLayout searched in miniconda/lib/db_plugins but not miniconda/lib/klayout/db_plugins/.

[erendn]

It seems like the error isn't fixed yet :/

We have many unit tests running in parallel and some of them fail randomly. When I inspect the output, I can see that they give errors similar to the ones above. So it seems like KLayout fails to load plugins randomly. But when I manually run the scripts, KLayout can load the plugins without any error. I'm still unsure if something is wrong with the environment or the KLayout installation.

Also, running klayout -d 31 gives:

Warning: could not connect to display
Info: Could not load the Qt platform plugin "xcb" in "" even though it was found.
Fatal: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, minimal, minimalegl, offscreen, vnc, webgl, xcb.

[klayoutmatthias]

That error comes from Qt. I assume it means something similar - the shared objects can be found, but not loaded. Usually because some references are not found.

I found this thread about a similar issue, but I don't know if that helps: https://stackoverflow.com/questions/57362015/how-to-fix-could-not-load-the-qt-platform-plugin-xcb-in-even-though-it-was

But I don't see this as a KLayout issue. Conda packaging is not something I deal with here.

Matthias

[klayoutmatthias]

I'll close this issue for now.