New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

layout.read twice segfaults for a normal GDS #121

Closed
thomaslima opened this Issue May 15, 2018 · 7 comments

Comments

Projects
None yet
2 participants
@thomaslima
Copy link
Collaborator

thomaslima commented May 15, 2018

When I do layout.read twice from python in a particular gds file, the second time it segfaults for some reason.
I am attaching the gds file here. It contains polygons and a Basic.TEXT pcell.

inductor_1030pH.gds.zip

@thomaslima

This comment has been minimized.

Copy link
Collaborator

thomaslima commented May 15, 2018

Luckily I realized my mistake:

https://www.klayout.de/forum/comments.php?DiscussionID=146

But it should still not segfault in my opinion.

@klayoutmatthias

This comment has been minimized.

Copy link
Collaborator

klayoutmatthias commented May 16, 2018

You're right, segfaults shouldn't happen. I just wonder what's the mistake in particular ... the discussion mentioned is a bit lengthy :-)

@thomaslima

This comment has been minimized.

Copy link
Collaborator

thomaslima commented May 16, 2018

Hi Matthias. It was about not passing the layer map as a read option. That fixed this particular read.
But let me ask you this. Maybe it is minor, but when I read a second "almost identical (different names)" layout with a Basic.TEXT pcell, the first Basic.TEXT pcell gets replaced with the new one, instead of there being an extra one added.

@klayoutmatthias

This comment has been minimized.

Copy link
Collaborator

klayoutmatthias commented May 16, 2018

I see .. actually the layer map should not be required. Reading should be perfectly fine. But maybe there is an issue when the file is identical.

I need to look into the PCell replacement issue, but I'm afraid that the "read twice" approach is not safe against PCell merging. That's somewhat intrinsic - the "read twice" merge approach is based on a low-level feature that allows "reopening" of cells: when a cell is encountered a second time, the content of the new cell will be read into the first one. That's unsafe in general: if you accidentally used the same cell name in two layouts, reading the second into the first will combine those cells into one, whether that makes sense or not. In case of PCells the actual cell names are not carrying the PCell parameters to be compatible with GDS. So the cell may be called "Basic.TEXT" in both cases, regardless of the actual parameters and KLayout will decide for one parameter set. That's why the cells get messed up.

A safe approach is to load the the layouts into two Layout objects and use "copy_hier" to copy over one layout into the other. But I'm afraid this feature does not preserve the PCells as such - they are turned into normal cells.

@thomaslima

This comment has been minimized.

Copy link
Collaborator

thomaslima commented May 19, 2018

Sorry just to clarify, do you mean 'copy_tree'? That works, I believe. Except that for my application case I wanted to save individual cells with shared instances into individual .gds files and upon loading them together, the instances would point to the same cell.

@klayoutmatthias

This comment has been minimized.

Copy link
Collaborator

klayoutmatthias commented May 19, 2018

@thomaslima

This comment has been minimized.

Copy link
Collaborator

thomaslima commented Jun 15, 2018

Thank you for looking into this. =)

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Sep 22, 2018

mef
Updated cad/klayout to 0.25.4
0.25.4          (2018-08-25):
* Bugfix: KLayout/klayout#121
       Issue with multiple reads of GDS2 layouts including PCells
* Bugfix: KLayout/klayout#134
       Error in cell.fill_region caused by big polygon with
       spikes
* Bugfix: KLayout/klayout#139
       Libraries have not been reassigned when loading a GDS file
       from command line (does not happen on File/Open)
* Bugfix: KLayout/klayout#141
       Issue with RBA::QHostAddress (ambiguous overload) on Qt5
* Bugfix: KLayout/klayout#142
       Issue with RBA::RecursiveShapeIterator#region=
* Bugfix: KLayout/klayout#144
       The Salt package descriptions are not shown with Motif
       style
* Bugfix: KLayout/klayout#148
       Wrong font is used
* Bugfix: KLayout/klayout#152
       Shapes#size reported a wrong shape count in viewer mode
* Bugfix: KLayout/klayout#153
       Application crash when editing guiding shape properties
* Bugfix: KLayout/klayout#155
       Program freezes after replacing nothing by something in
       Macro editor
* Bugfix: KLayout/klayout#157
       "Replace cell with ..." rejected cell names with a library
       prefix
* Bugfix: KLayout/klayout#158
       Repaint issue on cell context
* Bugfix: KLayout/klayout#159
       Tech specific macros and DRC scripts were not shown in tech
       manager
* Bugfix: 8 bit indexed GIF images can be used for package icons now
* Enhancement: Provide a way to specify the type of a macro
       This feature is mainly useful for command line arguments.
       If you run KLayout with "klayout -b -r myscript"
       it will not be able to determine the type of macro without
       a suffix.

       You can now explicitly specify a certain type by
       giving the suffix implicitly like: "klayout -b -r myscript[rb]"
       This will read "myscript" but pretend it was "myscript.rb"
       and execute it as Ruby script.

       This feature is handy if you need to run a file with a
       specific interpreter but cannot modify the file name.
* Enhancement: Selection now shows PCell display names
       Before, the internal name was shown for instances
* Enhancement: There is an option in the View menu to show or hide markers
       Markers may hide layout under them. With this feature you can
       quickly disable all markers and the layout becomes visible.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment