kicad-developers team mailing list archive

["Steven A. Falco" <stevenfalco@xxxxxxxxx>]

On 02/04/2018 03:46 PM, Nick Østergaard wrote:
> I just did test cdad023 by compiling myself, but I don't get any issue with the filling here.
> 
> This is on archlinux.
> 
> 2018-02-04 3:40 GMT+01:00 Steven A. Falco <stevenfalco@xxxxxxxxx <mailto:stevenfalco@xxxxxxxxx>>:
> 
>     On 02/03/2018 08:40 PM, Steven A. Falco wrote:
>     > On 02/03/2018 07:04 PM, Tomasz Wlostowski wrote:
>     >> On 03/02/18 18:40, Steven A. Falco wrote:
>     >>> Thanks, but now I'm confused.
>     >>
>     >> Sorry, I got confused by the date of your PCB file. You're indeed
>     >> running fresh Feb 2018 build. I tried opening your design in today's
>     >> latest master and it doesn't hang while filling zones.
>     >>
>     >> Could you get a stack trace (Ctrl-C in gdb while pcbnew is hanged)? It
>     >> would let us find the source of the problem faster.
>     >>
>     >> Thanks,
>     >> Tom
>     >
>     > Ok - below are two dumps from running pcbnew directly in gdb (kicad-r11969.dc66b73-nightlies.fc27.x86_64 version) - I ran it twice in case I caught it at a different point.  I also put an strace in the Dropbox directory.  The strace is missing carriage returns for some reason, but seems to be showing an endless repeat of EAGAIN errors.
>     >
>     >       Steve
>     >
>     > fedora27$ gdb pcbnew
>     > GNU gdb (GDB) Fedora 8.0.1-35.fc27
>     > Copyright (C) 2017 Free Software Foundation, Inc.
>     > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html <http://gnu.org/licenses/gpl.html>>
>     > This is free software: you are free to change and redistribute it.
>     > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>     > and "show warranty" for details.
>     > This GDB was configured as "x86_64-redhat-linux-gnu".
>     > Type "show configuration" for configuration details.
>     > For bug reporting instructions, please see:
>     > <http://www.gnu.org/software/gdb/bugs/ <http://www.gnu.org/software/gdb/bugs/>>.
>     > Find the GDB manual and other documentation resources online at:
>     > <http://www.gnu.org/software/gdb/documentation/ <http://www.gnu.org/software/gdb/documentation/>>.
>     > For help, type "help".
>     > Type "apropos word" to search for commands related to "word"...
>     > Reading symbols from pcbnew...Reading symbols from /home/sfalco/pcbnew...(no debugging symbols found)...done.
>     > (no debugging symbols found)...done.
>     > Missing separate debuginfos, use: dnf debuginfo-install kicad-r11969.dc66b73-nightlies.fc27.x86_64
>     > (gdb) run
>     > Starting program: /usr/bin/pcbnew
>     > [Thread debugging using libthread_db enabled]
>     > Using host libthread_db library "/lib64/libthread_db.so.1".
>     > Detaching after fork from child process 4987.
>     > Detaching after fork from child process 4989.
>     > Detaching after fork from child process 4991.
>     > Detaching after fork from child process 4993.
>     > Detaching after fork from child process 4995.
>     > [New Thread 0x7fffd75a8700 (LWP 4997)]
>     > [New Thread 0x7fffcd14e700 (LWP 4998)]
>     > [New Thread 0x7fffcc94d700 (LWP 4999)]
>     > [Thread 0x7fffcc94d700 (LWP 4999) exited]
>     > SetProjectFullName: old:'' new:'/home/sfalco/kicad/new_weather/main/main.pro <http://main.pro>'
>     > 08:31:12 PM: Debug: Loading project '/home/sfalco/kicad/new_weather/main/main.pro <http://main.pro>' settings.
>     > [Thread 0x7fffcd14e700 (LWP 4998) exited]
>     > ^C
>     > Thread 1 "pcbnew" received signal SIGINT, Interrupt.
>     > 0x00007ffff3932f50 in nanosleep () from /lib64/libpthread.so.0
>     > (gdb) bt
>     > #0  0x00007ffff3932f50 in nanosleep () from /lib64/libpthread.so.0
>     > #1  0x00007ffff6531cbc in wxMicroSleep(unsigned long) ()
>     >    from /lib64/libwx_baseu-3.0-gtk2.so.0
>     > #2  0x00007fffdfeee7d2 in PROGRESS_REPORTER::KeepRefreshing(bool) ()
>     >    from /usr/bin/_pcbnew.kiface
>     > #3  0x00007fffdfbe0010 in ZONE_FILLER::Fill(std::vector<ZONE_CONTAINER*, std::allocator<ZONE_CONTAINER*> >) [clone ._omp_fn.0] () from /usr/bin/_pcbnew.kiface
>     > #4  0x00007ffff3d64cdf in GOMP_parallel () from /lib64/libgomp.so.1
>     > #5  0x00007fffdfbdce1e in ZONE_FILLER::Fill(std::vector<ZONE_CONTAINER*, std::allocator<ZONE_CONTAINER*> >) () from /usr/bin/_pcbnew.kiface
>     > #6  0x00007fffdfc434f4 in ZONE_FILLER_TOOL::ZoneFillAll(TOOL_EVENT const&) ()
>     >    from /usr/bin/_pcbnew.kiface
>     > #7  0x00007fffdffd25b0 in COROUTINE<int, TOOL_EVENT const&>::callerStub(long)
>     >     () from /usr/bin/_pcbnew.kiface
>     > #8  0x00007fffe0018ec1 in make_fcontext () from /usr/bin/_pcbnew.kiface
>     > #9  0x3cb0d83000000000 in ?? ()
>     > #10 0x00000000be151450 in ?? ()
>     > #11 0xb25800003a98f660 in ?? ()
>     > #12 0x0000000000030061 in ?? ()
>     > #13 0x00007ffff391c430 in main_arena () from /lib64/libc.so.6
>     > #14 0x00007ffff391c430 in main_arena () from /lib64/libc.so.6
>     > #15 0x00005555580c0900 in ?? ()
>     > #16 0x00005555580c0900 in ?? ()
>     > #17 0x00005555580e2910 in ?? ()
>     > #18 0x0000000000000000 in ?? ()
>     > (gdb)
>     >
>     >
>     > fedora27$ gdb pcbnew
>     > GNU gdb (GDB) Fedora 8.0.1-35.fc27
>     > Copyright (C) 2017 Free Software Foundation, Inc.
>     > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html <http://gnu.org/licenses/gpl.html>>
>     > This is free software: you are free to change and redistribute it.
>     > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>     > and "show warranty" for details.
>     > This GDB was configured as "x86_64-redhat-linux-gnu".
>     > Type "show configuration" for configuration details.
>     > For bug reporting instructions, please see:
>     > <http://www.gnu.org/software/gdb/bugs/ <http://www.gnu.org/software/gdb/bugs/>>.
>     > Find the GDB manual and other documentation resources online at:
>     > <http://www.gnu.org/software/gdb/documentation/ <http://www.gnu.org/software/gdb/documentation/>>.
>     > For help, type "help".
>     > Type "apropos word" to search for commands related to "word"...
>     > Reading symbols from pcbnew...Reading symbols from /home/sfalco/pcbnew...(no debugging symbols found)...done.
>     > (no debugging symbols found)...done.
>     > Missing separate debuginfos, use: dnf debuginfo-install kicad-r11969.dc66b73-nightlies.fc27.x86_64
>     > (gdb) run
>     > Starting program: /usr/bin/pcbnew
>     > [Thread debugging using libthread_db enabled]
>     > Using host libthread_db library "/lib64/libthread_db.so.1".
>     > Detaching after fork from child process 5017.
>     > Detaching after fork from child process 5019.
>     > Detaching after fork from child process 5021.
>     > Detaching after fork from child process 5023.
>     > Detaching after fork from child process 5025.
>     > SetProjectFullName: old:'' new:'/home/sfalco/kicad/new_weather/main/main.pro <http://main.pro>'
>     > 08:36:46 PM: Debug: Loading project '/home/sfalco/kicad/new_weather/main/main.pro <http://main.pro>' settings.
>     > [New Thread 0x7fffd75a8700 (LWP 5027)]
>     > [New Thread 0x7fffd0da0700 (LWP 5028)]
>     > [Thread 0x7fffd0da0700 (LWP 5028) exited]
>     > ^C
>     > Thread 1 "pcbnew" received signal SIGINT, Interrupt.
>     > 0x00007ffff3932f50 in nanosleep () from /lib64/libpthread.so.0
>     > (gdb) bt
>     > #0  0x00007ffff3932f50 in nanosleep () from /lib64/libpthread.so.0
>     > #1  0x00007ffff6531cbc in wxMicroSleep(unsigned long) ()
>     >    from /lib64/libwx_baseu-3.0-gtk2.so.0
>     > #2  0x00007fffdfeee7d2 in PROGRESS_REPORTER::KeepRefreshing(bool) ()
>     >    from /usr/bin/_pcbnew.kiface
>     > #3  0x00007fffdfbe0010 in ZONE_FILLER::Fill(std::vector<ZONE_CONTAINER*, std::allocator<ZONE_CONTAINER*> >) [clone ._omp_fn.0] () from /usr/bin/_pcbnew.kiface
>     > #4  0x00007ffff3d64cdf in GOMP_parallel () from /lib64/libgomp.so.1
>     > #5  0x00007fffdfbdce1e in ZONE_FILLER::Fill(std::vector<ZONE_CONTAINER*, std::allocator<ZONE_CONTAINER*> >) () from /usr/bin/_pcbnew.kiface
>     > #6  0x00007fffdfc434f4 in ZONE_FILLER_TOOL::ZoneFillAll(TOOL_EVENT const&) ()
>     >    from /usr/bin/_pcbnew.kiface
>     > #7  0x00007fffdffd25b0 in COROUTINE<int, TOOL_EVENT const&>::callerStub(long)
>     >     () from /usr/bin/_pcbnew.kiface
>     > #8  0x00007fffe0018ec1 in make_fcontext () from /usr/bin/_pcbnew.kiface
>     > #9  0x000000003f800000 in ?? ()
>     > #10 0x0000000000000000 in ?? ()
>     > (gdb)
>     >
> 
>     I ran a bisection of the versions on COPR and got this:
> 
>     kicad-r11487.694ad93-nightlies.fc27.x86_64.rpm good 2017-12-02 <tel:2017-12-02>
>     kicad-r11497.cd3122d-nightlies.fc27.x86_64.rpm good 2017-12-05
>     kicad-r11516.cdad023-nightlies.fc27.x86_64.rpm bad 2017-12-06
>     kicad-r11518.f44d4d0-nightlies.fc27.x86_64.rpm bad 2017-12-07
>     kicad-r11542.d205366-nightlies.fc27.x86_64.rpm bad 2017-12-09
>     kicad-r11563.c18b638-nightlies.fc27.x86_64.rpm bad 2017-12-14
>     kicad-r11655.b05a40e-nightlies.fc27.x86_64.rpm bad 2017-12-24
> 
>     Somewhere between cd3122d and cdad023 the zone fill breaks (for me).  I cannot bisect it more finely, because there are no other intermediate COPR builds, and I don't know how the SRPM files are generated that COPR uses to do its builds.  I do have a "mock" setup here and could try making intermediate builds if someone can enlighten me on how the SRPM files are generated.
> 
>     Regardless, here are the commits between the working cd3122d build on 2017-12-05 and the broken cdad023 build on 2017-12-06.  At least several of them touch the zone code:
> 
>     commit cdad02336d270d04406f06ead4a04ac55364dfc1 fix minor compil warnings
>     commit 000f810161b9ff052d3833ac28c7961052517b55 pcbnew: fixed build error with python-enabled builds
>     commit c50da7e1631169a8ef8e762e596e9e3c9ca7ba37 poly2tri: fixed some warnings
>     commit 7ad436c7aae72c15e7a9fe939a529751c2b095e3 pcbnew: now PROGRESS_REPORTER should work in multi-threaded context under Windows...
>     commit 4bf90f971719923bc1a822c19928f26a5b098fef WX_PROGRESS_REPORTER: fixed windows build error
>     commit 4facfd846a73aa4861433293b8dd4d6a1f880eb9 WX_PROGRESS_REPORTER: fix assert warnings
>     commit f34b86d39e6e6ff39e54e4b775ebfcc45a6ba7d4 pcbnew: made zone filling algorithm thread-safe. etc
>     commit 8df299a6bca5c41f9cba60e5b9b7bdc21f4fd4b8 pcbnew: Optimized zone filling algorithm: code cleanup
>     commit d1d9e57b863828244a0c26d2ef7d7d6441e48c51 pcbnew: removed unused files
>     commit fdd5023aee741c7fd6f23f55f315b6e3af9f6a87 pcbnew: factored out ZONE_FILLER to a separate file
>     commit 56336fdafeea43096009c3f135c4f9d06bf33ab6 POINT_EDITOR: migrate to ZONE_FILLER class
>     commit 83b020d4da0627bd8b5618cae14d1270eed9e6e0 PCB_TOOL: added convenience methods for accessing current SELECTION
>     commit fa31d5308ac63f7575a8adc20065592597184b43 Sample tool for generating board geometyr as polygons
>     commit 58ce8653521c48a64e5c4d4824d8ba9e9594873e pcbnew: made TransformShapeWithClearanceToPolygon virtual
>     commit c6a15f1b9bd0ed2fce7a50b69f03a8145ee2d32d SHAPE_POLY_SET: fix empty triangulation bug
>     commit dbdf085555ac468080677c10088717807ecd6ae4 SHAPE_FILE_IO: default constructor outputs to stdout
>     commit 316ddadec1dbcc274c3ec2cda758473b7ea6487b pcbnew: Optimized zone filling algorithm.
>     commit 8b68a1736adc42011604b1ecc2ee92104d6367a2 Eeschema: Set "edited" flag on newly created sheets
>     commit bdc1fb04bee39953686d5f4a30dc435c59e6894a Eeschema: Correct wire/bus/entry connections
>     commit cd3122d8cd214c13657e9e28fee85d4a6748b997 Refactor hierarch.cpp: remove old dead code and clean current code.
> 
>             Steve

I've gotten to where I can build Kicad on my Fedora 27 machine, so I did a further bisection:

bad	commit cdad02336d270d04406f06ead4a04ac55364dfc1 fix minor compil warnings
	commit 000f810161b9ff052d3833ac28c7961052517b55 pcbnew: fixed build error with python-enabled builds
bad	commit c50da7e1631169a8ef8e762e596e9e3c9ca7ba37 poly2tri: fixed some warnings
bad	commit 7ad436c7aae72c15e7a9fe939a529751c2b095e3 pcbnew: now PROGRESS_REPORTER should work in multi-threaded context under Windows...
good	commit 4bf90f971719923bc1a822c19928f26a5b098fef WX_PROGRESS_REPORTER: fixed windows build error
	commit 4facfd846a73aa4861433293b8dd4d6a1f880eb9 WX_PROGRESS_REPORTER: fix assert warnings
	commit f34b86d39e6e6ff39e54e4b775ebfcc45a6ba7d4 pcbnew: made zone filling algorithm thread-safe. etc
	commit 8df299a6bca5c41f9cba60e5b9b7bdc21f4fd4b8 pcbnew: Optimized zone filling algorithm: code cleanup
good	commit d1d9e57b863828244a0c26d2ef7d7d6441e48c51 pcbnew: removed unused files
	commit fdd5023aee741c7fd6f23f55f315b6e3af9f6a87 pcbnew: factored out ZONE_FILLER to a separate file
	commit 56336fdafeea43096009c3f135c4f9d06bf33ab6 POINT_EDITOR: migrate to ZONE_FILLER class
	commit 83b020d4da0627bd8b5618cae14d1270eed9e6e0 PCB_TOOL: added convenience methods for accessing current SELECTION
	commit fa31d5308ac63f7575a8adc20065592597184b43 Sample tool for generating board geometyr as polygons
	commit 58ce8653521c48a64e5c4d4824d8ba9e9594873e pcbnew: made TransformShapeWithClearanceToPolygon virtual
	commit c6a15f1b9bd0ed2fce7a50b69f03a8145ee2d32d SHAPE_POLY_SET: fix empty triangulation bug
	commit dbdf085555ac468080677c10088717807ecd6ae4 SHAPE_FILE_IO: default constructor outputs to stdout
	commit 316ddadec1dbcc274c3ec2cda758473b7ea6487b pcbnew: Optimized zone filling algorithm.
	commit 8b68a1736adc42011604b1ecc2ee92104d6367a2 Eeschema: Set "edited" flag on newly created sheets 
	commit bdc1fb04bee39953686d5f4a30dc435c59e6894a Eeschema: Correct wire/bus/entry connections
good	commit cd3122d8cd214c13657e9e28fee85d4a6748b997 Refactor hierarch.cpp: remove old dead code and clean current code.

It looks like the problem was introduced by commit 7ad436c7a.  This makes some sense, because the symptom on my machine is that I get a dialog "Calculating zone fills" that never shows any progress and never completes.  The progress bar shows no progress, and the elapsed time counter stays at 0:00:00.  So perhaps the real problem is in the PROGRESS_REPORTER rather than the zone fill, or perhaps it is in the way they interact.

I don't know why others have not been able to reproduce this, but if it is triggered by a race condition, perhaps the timing on my system just happens to expose the problem.

I'd be happy to test a patch if someone proposes one, and I'd be happy to gather additional data - just let me know what to gather.  I'm not familiar enough with the code to tinker with it on my own, though. :-)

	Steve