Bug#896706: pcbnew: crashes with a failed assertion on i386, starts fine on amd64

2018-06-03 Thread Carsten Schoenert
Control: severity -1 serious

Hello Mirko,

On Sat, Jun 02, 2018 at 02:41:38PM +0200, Mirko Parthey wrote:
> OK, I got kicad 5.0.0~rc2+dfsg1-2 from unstable.
> Here's a typescript of my gdb session with a backtrace.
> ...
> #26 0x0041cd2d in PGM_SINGLE_TOP::OnPgmInit (this=) at 
> ./common/single_top.cpp:322
> #27 0x0042053e in APP_SINGLE_TOP::OnInit (this=0x4b2600) at 
> ./common/single_top.cpp:128
> #28 0xb7518176 in wxEntry(int&, wchar_t**) () from 
> /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0
> #29 0xb7518f83 in wxEntry(int&, char**) () from 
> /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0
> #30 0x00419e56 in main (argc=, argv=0xb414) at 
> ./common/single_top.cpp:239
> (gdb) quit
> A debugging session is active.

I picked up a older laptop and installed a Debian testing i386 on it and
I can reproduce that segfault here too. I also did a GDB trace of such a
segfault and forwarded it to the bug report on the upstream bug tracker.

It's now mostly up to the upstream developers to find the origin of the
segfault which we see. Could be some additional compiler flags that are
needed but also some specific platform macros that are needed.
I'm not a expert in reading GDB logs so I hope the upstream developers
can detect the issues in the logs.

I marked this report now as serious as this is a RC bug. Until it's
solved we wont see a migration of the kicad packages to testing.

Regards
Carsten



Bug#896706: pcbnew: crashes with a failed assertion on i386, starts fine on amd64

2018-06-02 Thread Mirko Parthey
On Fri, Jun 01, 2018 at 06:41:35AM +0200, Carsten Schoenert wrote:
> So there is one more thing you could provide then. Please create a gdb
> backtrace, this is helpful for the developers as they can see some
> useful information mostly what's the reason for the segfault.
> 
> https://wiki.debian.org/HowToGetABacktrace
> 
> PS: Due the curl transition the packages from experimental aren't usable
> anymore as thy are using Curl3. I uploaded yesterday KiCad into
> unstable, now with using Curl4 instead. You will probbaly need to pull
> the newer packages from there.

OK, I got kicad 5.0.0~rc2+dfsg1-2 from unstable.
Here's a typescript of my gdb session with a backtrace.

Script started on 2018-06-02 14:26:03+02:00
mpa@buster32:~$ gdb /usr/bin/pcbnew
GNU gdb (Debian 7.12-6+b2) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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 "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/pcbnew...Reading symbols from 
/usr/lib/debug/.build-id/c1/79dc22b22fe60a6d11a147205e20856974f3ae.debug...done.
done.
(gdb) set pagination 0
(gdb) run
Starting program: /usr/bin/pcbnew 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
14:26:55: Debug: Checking template path '/usr/share/kicad/template' exists
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debug: wxColour::Set - couldn't set to colour string 'NONE'
14:27:00: Debu

Bug#896706: pcbnew: crashes with a failed assertion on i386, starts fine on amd64

2018-05-31 Thread Carsten Schoenert
Hi,

On Fri, Jun 01, 2018 at 01:55:40AM +0200, Mirko Parthey wrote:
> It happens in both situations.  When pcbnew is started from the manager,
> the same message is printed and the manager also aborts.

o.k. That leads to an issue in pcbnew only.

> > This is no crash?
> 
> Well, what do you consider a crash?
> pcbnew does not display any GUI before terminating.

That's something I'd calling a crash. The difference to an assertation
is the termination of the program without any chance for saving my
workspace. KiCad uses some techniques to not segfaulting in
circumstances and shows a assert message then.

So there is one more thing you could provide then. Please create a gdb
backtrace, this is helpful for the developers as they can see some
useful information mostly what's the reason for the segfault.

https://wiki.debian.org/HowToGetABacktrace

PS: Due the curl transition the packages from experimental aren't usable
anymore as thy are using Curl3. I uploaded yesterday KiCad into
unstable, now with using Curl4 instead. You will probbaly need to pull
the newer packages from there.

> > I opened a new upstream bug report about this.
> > 
> > https://bugs.launchpad.net/kicad/+bug/1774316
> > 
> > Please check if the system information is correct so far within the bug
> > report.
> 
> Looks OK to me.
> This is the diff from your bugreport to my version info:
> 
> --- kicad-bugreport.txt 2018-06-01 01:35:35.095539211 +0200
> +++ kicad-versioninfo.txt   2018-06-01 01:37:18.614939232 +0200
> @@ -5,2 +5,2 @@
> -libcurl/7.58.0 OpenSSL/1.0.2o zlib/1.2.11 libidn2/2.0.4 libpsl/0.20.1 
> (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.31.1 librtmp/2.3
> -Platform: Linux 4.16.0-1-amd64 x86_64, 64 bit, Little endian, wxGTK
> +libcurl/7.60.0 OpenSSL/1.0.2o zlib/1.2.11 libidn2/2.0.4 libpsl/0.20.1 
> (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.32.0 librtmp/2.3
> +Platform: Linux 4.16.0-1-686-pae i686, 32 bit, Little endian, wxGTK

Yep, as expected, the only difference here is the used kernel.

Regards
Carsten



Bug#896706: pcbnew: crashes with a failed assertion on i386, starts fine on amd64

2018-05-31 Thread Mirko Parthey
Hello Carsten,

On Thu, May 31, 2018 at 05:55:09AM +0200, Carsten Schoenert wrote:
> just for clarity, this issue is happen if you running pcbnew in
> standalone mode or is this happen also if start pcbnew from the kicad
> manager?

It happens in both situations.  When pcbnew is started from the manager,
the same message is printed and the manager also aborts.

> This is no crash?

Well, what do you consider a crash?
pcbnew does not display any GUI before terminating.

> I opened a new upstream bug report about this.
> 
> https://bugs.launchpad.net/kicad/+bug/1774316
> 
> Please check if the system information is correct so far within the bug
> report.

Looks OK to me.
This is the diff from your bugreport to my version info:

--- kicad-bugreport.txt 2018-06-01 01:35:35.095539211 +0200
+++ kicad-versioninfo.txt   2018-06-01 01:37:18.614939232 +0200
@@ -5,2 +5,2 @@
-libcurl/7.58.0 OpenSSL/1.0.2o zlib/1.2.11 libidn2/2.0.4 libpsl/0.20.1 
(+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.31.1 librtmp/2.3
-Platform: Linux 4.16.0-1-amd64 x86_64, 64 bit, Little endian, wxGTK
+libcurl/7.60.0 OpenSSL/1.0.2o zlib/1.2.11 libidn2/2.0.4 libpsl/0.20.1 
(+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.32.0 librtmp/2.3
+Platform: Linux 4.16.0-1-686-pae i686, 32 bit, Little endian, wxGTK

Regards
Mirko



Bug#896706: pcbnew: crashes with a failed assertion on i386, starts fine on amd64

2018-05-30 Thread Carsten Schoenert
Hello Mirko,

On Thu, May 31, 2018 at 02:16:20AM +0200, Mirko Parthey wrote:
> Hello Carsten,
> 
> On Mon, May 28, 2018 at 05:36:40PM +0200, Carsten Schoenert wrote:
> > could you please try out the current version 5.0.0~rc2+dfsg1 from
> > experimental and check if the issue is still alive?
> 
> yes, the issue still exists on an updated Buster system with the new
> KiCad from experimental.

just for clarity, this issue is happen if you running pcbnew in
standalone mode or is this happen also if start pcbnew from the kicad
manager?
This is no crash?

I opened a new upstream bug report about this.

https://bugs.launchpad.net/kicad/+bug/1774316

Please check if the system information is correct so far within the bug
report.

Regards
Carsten



Bug#896706: pcbnew: crashes with a failed assertion on i386, starts fine on amd64

2018-05-30 Thread Mirko Parthey
Hello Carsten,

On Mon, May 28, 2018 at 05:36:40PM +0200, Carsten Schoenert wrote:
> could you please try out the current version 5.0.0~rc2+dfsg1 from
> experimental and check if the issue is still alive?

yes, the issue still exists on an updated Buster system with the new
KiCad from experimental.

Regards
Mirko



Bug#896706: pcbnew: crashes with a failed assertion on i386, starts fine on amd64

2018-05-28 Thread Carsten Schoenert
Hello Mirko,

On Mon, Apr 23, 2018 at 11:35:50PM +0200, Mirko Parthey wrote:
> On the i386 architecture, I get this error when starting pcbnew:
> 
> pcbnew: 
> /build/kicad-9PGPiJ/kicad-5.0.0~rc1+dfsg1+20180318/include/geometry/rtree.h:1642:
>  void RTree TMINNODES>::Classify(int, int, RTree ELEMTYPEREAL, TMAXNODES, TMINNODES>::PartitionVars*) [with DATATYPE = 
> KIGFX::VIEW_ITEM*; ELEMTYPE = int; int NUMDIMS = 2; ELEMTYPEREAL = float; int 
> TMAXNODES = 8; int TMINNODES = 4]: Assertion `!a_parVars->m_taken[a_index]' 
> failed.
> 
> Conversely, on an amd64 system, pcbnew starts fine.
> 
> Both systems are up-to-date installations of Debian buster,
> with kicad pulled from Debian experimental.

could you please try out the current version 5.0.0~rc2+dfsg1 from
experimental and check if the issue is still alive?

Regards
Carsten



Bug#896706: pcbnew: crashes with a failed assertion on i386, starts fine on amd64

2018-04-23 Thread Mirko Parthey
Package: kicad
Version: 5.0.0~rc1+dfsg1+20180318-3
Severity: normal

On the i386 architecture, I get this error when starting pcbnew:

pcbnew: 
/build/kicad-9PGPiJ/kicad-5.0.0~rc1+dfsg1+20180318/include/geometry/rtree.h:1642:
 void RTree::Classify(int, int, RTree::PartitionVars*) [with DATATYPE = KIGFX::VIEW_ITEM*; 
ELEMTYPE = int; int NUMDIMS = 2; ELEMTYPEREAL = float; int TMAXNODES = 8; int 
TMINNODES = 4]: Assertion `!a_parVars->m_taken[a_index]' failed.

Conversely, on an amd64 system, pcbnew starts fine.

Both systems are up-to-date installations of Debian buster,
with kicad pulled from Debian experimental.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 4.15.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kicad depends on:
ii  libc6   2.27-3
ii  libcairo2   1.15.10-1
ii  libcurl37.58.0-2
ii  libgcc1 1:8-20180414-1
ii  libgl1  1.0.0-2
ii  libglew2.0  2.0.0-5
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  libgomp18-20180414-1
ii  libpixman-1-0   0.34.0-2
ii  libpython2.72.7.15~rc1-1
ii  libssl1.1   1.1.0h-2
ii  libstdc++6  8-20180414-1
ii  libwxbase3.0-0v53.0.4+dfsg-3
ii  libwxgtk3.0-gtk3-0v53.0.4+dfsg-3
ii  python  2.7.15~rc1-1
ii  python-wxgtk3.0 3.0.2.0+dfsg-7

Versions of packages kicad recommends:
ii  kicad-demos  5.0.0~rc1+dfsg1+20180318-3
ii  kicad-libraries  5.0.0~rc1+dfsg1+20180318-3
ii  xsltproc 1.1.29-5

Versions of packages kicad suggests:
pn  extra-xdg-menus   
ii  kicad-doc-en  5.0.0~rc1+dfsg1+20180318-3
pn  kicad-packages3d  

-- no debconf information