Hello,
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
Lukas
# Read about DRC scripts in the User Manual under "Design Rule Check (DRC)"
# This is a sample:
report("DRC")
## minimum feature size of 60nm
Si=input(1,0)
Si.width(0.06).output("Silicon_width","minimum feature size violation")
## make sure the devices are within the floor plan layer region;
#boundary=input(99)
#Si.outside(boundary).output("Boundary","devices are out of boundary")
Comments
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?
Matthias
https://www.dropbox.com/s/ye7yzkw55y3l9ol/klayout_DRC_crash.mp4?dl=0
The layer properties file used (I checked without one, and it still crashes):
https://www.dropbox.com/s/0y8ea7471vr9ged/klayout_Layers_EBeam.lyp?dl=0
And finally below is the crash report.
https://www.dropbox.com/s/j6ynjdnuwystchh/klayout_DRC_crash.txt?dl=0
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?
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)
Backtrace:
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'
Hello
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
(2) Clang-Ruby19Python27
The valgrind log file and stack trace are captured for both the builds.
Please refer to:
Hope this will help Mattias investigate causes further.
Regards,
Kazzz
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:
which probably is related to:
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:
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:
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:
Best regards,
Matthias
Hello Matthias,
Thank you for your valuable suggestions.
By inserting the assertion statement (into 0.24.3), I could get it as below.
So I have modified the code as suggested by you:
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
Regards,
Kazzz
Hello,
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:
Regards,
Kazzz