DRC crashing

edited January 2015 in KLayout Support

I have been trying to use DRC on KLayout since the first v0.23, but it crashes KLayout when I run it. I tried this on a few computers, and the two most recent OSX versions. I just downloaded the latest version, 0.23.9, and it crashes there too.

Here are the step taken:
Open a layout. It has a layer 1, type 0.
Edit the DRC script. Run. And see a complete crash of the program.

Below is the script. Any others with this problem?

thank you

# Read about DRC scripts in the User Manual under "Design Rule Check (DRC)"
# This is a sample:

## minimum feature size of 60nm
Si.width(0.06).output("Silicon_width","minimum feature size violation")

## make sure the devices are within the floor plan layer region;
#Si.outside(boundary).output("Boundary","devices are out of boundary")


  • edited 11:42AM

    Hi Lukas,

    That's a plain and simple DRC runset, so I don't see why it shouldn't work.

    Is there any error message giving more details?

    Or maybe it's related to the kind of input? Can you reproduce this issue with a simple testcase?


  • edited January 2015
    Here is a video showing the crash with a simple test case (a single rectangle). Also shown is a screenshot of the "Console".


    The layer properties file used (I checked without one, and it still crashes):

    And finally below is the crash report.

  • edited January 2015

    Hi Lukas,

    thanks - bright idea to show the problem in a video!

    But unfortunately I can just guess. It's not as easy to reproduce on Linux or Windows - in fact I can't reproduce it there at all (I could proof by video, but I hope you believe that :-) )

    I tried to guess from the stack trace what might be happening. It's pretty easy to locate the piece of code that causes this issue, but difficult to guess the reason. There is no obvious code path leading to that condition. I have tried valgrind which sometimes gives hints about unstable code, but I don't find issues here.

    Maybe the following is worth a try: before you run the DRC, save your layout and leave KLayout. Enter KLayout again, this time in viewer mode. Load the layout and run the DRC in viewer mode. Does that make a difference?


  • edited 11:42AM
    Hi Matthias,

    The problem still exists in the the latest binary on OSX, 0.24.2. I know some of my students were able to get it to work (presumably on Windows).

    Here's the crash report. Though now the app doesn't close, but rather brings up useful diagnostics...

    Also, I tried your idea of using Viewer mode, and it was worse... the program crashes and closes. In contrast, the edit mode allows you to keep working!

    Signal number: 11
    Address: 0xffffffff
    Program Version: KLayout 0.24.2 (2015-10-02 r3034)
    2 ??? 0x0000000000000004 0x0 + 4
    3 klayout 0x0000000105f8b810 _ZNK2db6Region12begin_mergedEv + 48
    4 klayout 0x0000000105f9a280 _ZNK2db6Region24run_single_polygon_checkENS_18edge_relation_typeEibNS_12metrics_typeEdjj + 448
    5 klayout 0x000000010659ffce _ZN3gsiL6width2EPKN2db6RegionEjbRKN2tl7VariantES7_S7_S7_ + 174
    6 klayout 0x00000001065c0b12 _ZNK3gsi10ExtMethod6IKN2db6RegionENS1_9EdgePairsEjbRKN2tl7VariantES8_S8_S8_E4callEPvRNS_10SerialArgsESC_ + 434
    7 klayout 0x0000000106d58201 _ZN3rba14method_adaptorEiiPmmb + 5089
    8 libruby.2.0.0.dylib 0x0000000110000376 rb_ruby_debug_ptr + 22929
    9 libruby.2.0.0.dylib 0x000000010ffffd55 rb_ruby_debug_ptr + 21360
    10 libruby.2.0.0.dylib 0x0000000110000b2a rb_ruby_debug_ptr + 24901
    11 libruby.2.0.0.dylib 0x000000010fffff03 rb_ruby_debug_ptr + 21790
    12 libruby.2.0.0.dylib 0x000000010ffed4c9 rb_vm_get_insns_address_table + 11081
    13 libruby.2.0.0.dylib 0x000000010fff8062 rb_iseq_eval + 524
    14 libruby.2.0.0.dylib 0x000000010fffcbf6 rb_ruby_debug_ptr + 8721
    15 libruby.2.0.0.dylib 0x000000010fff6be0 rb_obj_instance_eval + 426
    16 libruby.2.0.0.dylib 0x0000000110000376 rb_ruby_debug_ptr + 22929
    17 libruby.2.0.0.dylib 0x000000010ffffd55 rb_ruby_debug_ptr + 21360
    18 libruby.2.0.0.dylib 0x000000010ffed577 rb_vm_get_insns_address_table + 11255
    19 libruby.2.0.0.dylib 0x000000010fff8062 rb_iseq_eval + 524
    20 libruby.2.0.0.dylib 0x000000010fffd65f rb_ruby_debug_ptr + 11386
    21 libruby.2.0.0.dylib 0x000000010fff2b5b rb_funcall2 + 337
    22 libruby.2.0.0.dylib 0x000000010ff01056 rb_protect + 232
    23 klayout 0x0000000106d56337 _ZN3rbaL19rb_funcall2_checkedEmmiPm + 295
    24 klayout 0x0000000106d559d3 _ZN3rba5Proxy4callEiRN3gsi10SerialArgsES3_ + 515
    25 klayout 0x0000000106815fa2 _ZNK3gsi8Callback5issueINS_16MacroInterpreterEPKN3lay5MacroEEEvMT_KFvT0_ES8_ + 226
    26 klayout 0x000000010ab09563 _ZNK3lay5Macro3runEv + 195
    27 klayout 0x000000010ab10154 _ZN3lay18MacroSignalAdaptor3runEv + 20
    28 QtCore 0x0000000110dc47e7 _ZN11QMetaObject8activateEP7QObjectPKS_iPPv + 2471
    29 QtGui 0x00000001102a1a5a _ZN7QAction8activateENS_11ActionEventE + 250
    30 QtGui 0x0000000110254b61 _ZNK16QMacInputContext11isComposingEv + 26417
    31 libsystem_trace.dylib 0x00007fff85cd3cd7 _os_activity_initiate + 75
    32 AppKit 0x00007fff91070eb1 -[NSApplication sendAction:to:from:] + 452
    33 AppKit 0x00007fff91070c4e -[NSMenuItem _corePerformAction] + 382
    34 AppKit 0x00007fff9107097c -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 114
    35 libsystem_trace.dylib 0x00007fff85cd3cd7 _os_activity_initiate + 75
    36 AppKit 0x00007fff91137b00 -[NSMenu performActionForItemAtIndex:] + 131
    37 AppKit 0x00007fff91137a66 -[NSMenu _internalPerformActionForItemAtIndex:] + 35
    38 AppKit 0x00007fff911378b2 -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] + 107
    39 AppKit 0x00007fff91058d6b NSSLMMenuEventHandler + 724
    40 HIToolbox 0x00007fff86e87b6c _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1260
    41 HIToolbox 0x00007fff86e86fae _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 386
    42 HIToolbox 0x00007fff86e9ccb6 SendEventToEventTarget + 40
    43 HIToolbox 0x00007fff86ed6f45 _ZL18SendHICommandEventjPK9HICommandjjhPKvP20OpaqueEventTargetRefS5_PP14OpaqueEventRef + 428
    44 HIToolbox 0x00007fff86f14b8d SendMenuCommandWithContextAndModifiers + 59
    45 HIToolbox 0x00007fff86f14b30 SendMenuItemSelectedEvent + 188
    46 HIToolbox 0x00007fff86f14a09 _ZL19FinishMenuSelectionP13SelectionDataP10MenuResultS2_ + 96
    47 HIToolbox 0x00007fff86f15481 _ZL14MenuSelectCoreP8MenuData5PointdjPP13OpaqueMenuRefPt + 702
    48 HIToolbox 0x00007fff86f150fe _HandleMenuSelection2 + 446
    49 AppKit 0x00007fff90f76ce0 _NSHandleCarbonMenuEvent + 277
    50 AppKit 0x00007fff90eadbfd _DPSNextEvent + 1828
    51 AppKit 0x00007fff90eace58 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346
    52 AppKit 0x00007fff90ea2af3 -[NSApplication run] + 594
    53 QtGui 0x000000011025e45e _ZN14QDesktopWidget11resizeEventEP12QResizeEvent + 7166
    54 QtCore 0x0000000110da8fd8 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE + 504
    55 QtCore 0x0000000110dac197 _ZN16QCoreApplication4execEv + 199
    56 klayout 0x0000000106b2819b _ZN3lay11Application4execEv + 2187
    57 klayout 0x0000000106b27247 _ZN3lay11Application3runEv + 5207
    58 klayout 0x0000000105d88635 _Z12klayout_mainiPPc + 341
    59 klayout 0x0000000105d8844b main + 251
    60 libdyld.dylib 0x00007fff919a15c9 start + 1

    Operation cancelled in Region::width_check in MacroInterpreter::execute
    /Users/lukasc/.klayout/drc/drc.lydrc:10:in `execute_drc'
    :/built-in-macros/drc_interpreters.lym:16:in `instance_eval'
    :/built-in-macros/drc_interpreters.lym:16:in `execute_drc'
    :/built-in-macros/drc_interpreters.lym:57:in `execute'
  • edited November 2015


    I could reproduce the DRC crash.

    Since I came to know that valgrind supports OSX 10.10 (and 10.11, too), I ran klayout-0.24.2 under valgrind-3.12.0.SVN.

    I've rebuilt two different executables of klayout-0.24.2 in debug mode:

    (1) Xcode-Ruby20Python27

     * This is the debug build of "klayout-0.24.2-MacOSX-Yosemite-3-Qt487mp.dmg.bz2"
       binary package, which is currently posted.
     Compiler: Xcode 7.1 (from Apple)
     Ruby:     Ruby 2.0 (bundled with OSX)
     Python:   Python 2.7 (bundled with OSX)
     Qt:       Qt 4.8.7 (from MacPorts)

    (2) Clang-Ruby19Python27

     Compiler: clang++ version 3.8.0 (trunk 252158) (built from the source code)
     Ruby:     Ruby 1.9 (from MacPorts)
     Python:   Python 2.7 (from MacPorts)
     Qt:       Qt 4.8.7 (from MacPorts)

    The valgrind log file and stack trace are captured for both the builds.

    Please refer to:


    Hope this will help Mattias investigate causes further.



  • edited 11:42AM
    Thanks Kazzz!
  • edited November 2015

    Hi Kazzz,

    thanks very much providing the valgrind log.

    I see the usual noise from Python and Ruby, but there is a scary message here:

    ==44245== Use of uninitialised value of size 8
    ==44245==    at 0x10020EA0C: db::Region::ensure_merged_polygons_valid() const (vector:1476)
    ==44245==    by 0x100202ABF: db::Region::begin_merged() const (dbRegion.cc:1200)
    ==44245==    by 0x10021154F: db::Region::run_single_polygon_check(db::edge_relation_type, int, bool, db::metrics_type, double,

    which probably is related to:

    ==44245== Conditional jump or move depends on uninitialised value(s)
    ==44245==    at 0x10020E9E8: db::Region::ensure_merged_polygons_valid() const (dbRegion.h:292)
    ==44245==    by 0x100202ABF: db::Region::begin_merged() const (dbRegion.cc:1200)
    ==44245==    by 0x10021154F: db::Region::run_single_polygon_check(db::edge_relation_type, int, bool, db::metrics_type, double, unsigned int, unsigned int) const (dbRegion.cc:1642)

    I recall a discussion (was that on the forum?) about a build problem on MacOS. It boiled down to the following code in dbRegion.h:

    RegionIterator (const db::RecursiveShapeIterator &iter, const db::ICplxTrans &trans)
      : m_rec_iter (iter), m_iter_trans (trans), m_from (), m_to ()
      set ();

    In order to work properly, the initialization of m_from and m_to has to happen and it's a least required that m_from == m_to initially. That seemed not to be the case sometimes. My compilers (gcc and VC++) and the STL I am using (STLPort) provide a proper initialization of m_from and m_to to the same value. Both are basically of type std::vector::const_iterator. But on MacOS, the default initialization of these objects apparently has failed at least once. So maybe this problem hits here too.

    Following the scientific approach, first thing to test this hypothesis is to insert the following assert:

    RegionIterator (const db::RecursiveShapeIterator &iter, const db::ICplxTrans &trans)
      : m_rec_iter (iter), m_iter_trans (trans), m_from (), m_to ()
      tl_assert (m_from == m_to); // tl_assert also asserts on release builds 
      set ();

    This assertion should never fail. If it does, the question is how to avoid this. I don't know what STL is being used. Some STL implementations use pointers for iterators, but still I'd expect a pointer would be initialized to NULL when I explicitly default-initialize it. The STL appears to have the concept of a "singular iterator value" which comes into play for that purpose, but I don't know whether this singular value is guaranteed to be the same for both initializations ...

    Anyway, a hard hack would be to enforce the equality:

    RegionIterator (const db::RecursiveShapeIterator &iter, const db::ICplxTrans &trans)
      : m_rec_iter (iter), m_iter_trans (trans), m_from (), m_to ()
      m_from = m_to;  // required on MacOS?
      set ();

    Best regards,


  • edited January 2016

    Hello Matthias,

    Thank you for your valuable suggestions.

    By inserting the assertion statement (into 0.24.3), I could get it as below.

    *** ERROR: /Users/sekigawakazunari/SVNWork/klayout-0.24.3/src/dbRegion.h,346,m_from == m_to
    *** ERROR: In /Users/sekigawakazunari/.klayout/drc/drc_lukasc.lydrc: Internal error:
                  m_from == m_to was not true in Region::width_check
    *** ERROR: /Users/sekigawakazunari/.klayout/drc/drc_lukasc.lydrc:3: Internal error:
                  m_from == m_to was not true in Region::width_check in MacroInterpreter::execute

    So I have modified the code as suggested by you:

      RegionIterator (const db::RecursiveShapeIterator &iter, const db::ICplxTrans &trans)
        : m_rec_iter (iter), m_iter_trans (trans), m_from (), m_to ()
    #if defined(__APPLE__)
        // http://klayout.de/forum/comments.php?DiscussionID=570&page=1#Item_8
        // On MacOSX Yosemite, the assertion below raised!
        //                     *tl_assert also asserts on release builds
        // tl_assert (m_from == m_to);
        // a suggested hard hack is to enforce the equality:
        m_from = m_to;
        set ();

    A new binary package "klayout-0.24.3-MacOSX-Yosemite-1-Qt487mp.dmg.bz2" will be posted soon.

    Please note the issue of "Drag & Drop from Finder" is not yet resolved.

    If you are in a hurry, please get it from: Here




  • ksks
    edited 11:42AM
    Thank you Kazzz & Matthias for your OS X support - The latest binary works great
  • edited December 2015


    Thank you for your feedback.

    The 1st binary package of "0.24.4" for Mac OSX will be published by Matthias soon.

    If you are in a hurry, you can get it from:

    MD5 is:  5a4528780fca7f1868a73d973fe94fe8 *klayout-0.24.4-MacOSX-Yosemite-1-Qt487mp.dmg.bz2



Sign In or Register to comment.