Linux Mint

Pcbnew (and X) crash during zooming

Bug #911963 reported by Argyle on 2012-01-04

This bug affects 7 people

	Status	Importance	Assigned to
KiCad	Invalid	Undecided	Unassigned
Linux Mint	Invalid	Undecided	Unassigned
X.Org X server	New	Undecided	Unassigned
xf86-video-intel	New	Undecided	Unassigned

Bug Description

I'm using Linux Mint 12 (Lisa) with Gnome 64-bit edition. This problem also occurs in an installation of Ubuntu 11.10 on the same machine. It appears that X is crashing intermittently when zooming in or out of a design in pcbnew. It seems to occur more often in complex designs. I can usually reproduce it within 30 seconds to 1 minute by rapidly zooming in and out of the design. When the crash occurs, I find myself back at the login screen. Under normal working conditions this crash occurs approx every 20 minutes to 1 hour. I reported this bug under Ubuntu as 892440 in November, but haven't heard anything yet about how to go about continuing to fix it. I have posted the Xorg log which shows a backtrace with a segmentation fault as an attachment. Please let me know if there is anything else I can do.

Thanks!

Revision history for this message

Argyle (kruegejj) wrote on 2012-01-04:

Xorg.0.log.old with offending backtrace. Edit (51.9 KiB, text/plain)

Argyle (kruegejj) on 2012-01-08

summary:

- Pcbnew crashes during zooming
+ Pcbnew (and X) crash during zooming

Revision history for this message

Dick Hollenbeck (dickelbeck) wrote on 2012-01-08:

there has been a number of reports of buggy intel video drivers recently. Perhaps offer to send Intel some vitamins for their video developers, or try a different intel video driver version. Changing versions have fixed another bug reported under KiCad.

Either path above has you going to Intel.

Revision history for this message

Argyle (kruegejj) wrote on 2012-01-12:

Xorg.0.log.old6 Edit (51.9 KiB, text/plain)

Thanks Dick, I'll look into that. If I were looking to roll back that driver I'd be looking at the xserver-xorg-video-intel package, right?

I've attached another Xorg log. The xserver-xorg-video-intel package updated today, and I also installed xserver-xorg-video-intel-dbg. The crash still occurs. It seems more likely to occur when the system is loaded. I can get it to go in a couple of seconds shortly after login before things have settled down. Otherwise it can sometimes take a while to get it to occur.

Revision history for this message

Argyle (kruegejj) wrote on 2012-01-13:

Xorg.0.log.old.4975 Edit (51.9 KiB, text/plain)

Okay, now I've got a backtrace from gdb. Does anyone know what this is saying? Is it the intel driver? Should I try to report this at freedesktop.org BugZilla? Backtrace and Xorglog attachments to follow.

Revision history for this message

Argyle (kruegejj) wrote on 2012-01-13:

Xorg.gdblog.4975 Edit (12.6 KiB, text/plain)

gdb output...

Revision history for this message

Argyle (kruegejj) wrote on 2012-01-18:

This may be related / the same as redhat bugzilla bug #694558. https://bugzilla.redhat.com/show_bug.cgi?id=694558
They seem to think the bug is in Xorg rather than the driver. Does any know how I can help determine this?
Thanks,
Josh

Revision history for this message

Argyle (kruegejj) wrote on 2012-01-25:

I'm about to launch into another heavy round of layout again. Any suggestions anyone has for me with regards to steps I might take to help further debug this crash would be greatly appreciated!

Thanks,
Joshua

Revision history for this message

Argyle (kruegejj) wrote on 2012-01-25:

Further note for activating this crash - panning with the scrollbars can trigger it too.

Revision history for this message

Argyle (kruegejj) wrote on 2012-01-26:

Xorg log using NOUVEAU Driver (No Crash) Edit (51.3 KiB, text/plain)

I've installed a GeForce 8800 GTS graphics card. I cannot reproduce the crash (thusfar) while using this card. I've attached the Xorg log using the Nouveau driver, and I'll attach the log using the proprietary driver after this.

Revision history for this message

Argyle (kruegejj) wrote on 2012-01-26:

#10

Xorg log for NVidia driver (no crash) Edit (18.4 KiB, text/plain)

Thank god I have a (maybe) stable system again! I'll post again if I witness problems with this card.

Revision history for this message

Dick Hollenbeck (dickelbeck) wrote on 2012-01-27: Re: [Bug 911963] Re: Pcbnew (and X) crash during zooming

#11

Others might benefit from a summary from you, if you can pinpoint the software component
that you suspect by name.

Revision history for this message

Argyle (kruegejj) wrote on 2012-01-27:

#12

To summarize:

Xorg intermittently (every 5 minutes to 2 hours, 5 - 20 times per day) crashes with a signal 11 (segfault) when I'm zooming or panning in pcbnew. The crash seems to occur when I'm using the onboard Intel video card and not (so far - I've only tested a small amount) when I use an Nvidia card.

The xorg logs and gdb files posted above are the only evidence I have for the crash other than having to log in again. I don't know how to interpret them or provide any more insight because I'm unfamiliar with the inner workings of pcbnew, X, and the video drivers. (I'm still not even sure which direction a backtrace goes in.) I don't know what further methods of investigation I should be pursuing or where to go to learn them. In fact you, Dick, are the only human I've been able to elicit any response from in the 6 months I've been struggling with this problem. Thank you for that!

I tagged the Xorg X Server and XF86 Intel projects, but I don't know how to get more specific about which of their components might be causing this.

Oh, I will mention that I did try both the x-swat and xorg-edgers PPAs, and was able to reproduce the crash using both of them.

Revision history for this message

Dick Hollenbeck (dickelbeck) wrote on 2012-01-27:

#13

On 01/27/2012 01:17 PM, Argyle wrote:
> To summarize:
>
> Xorg intermittently (every 5 minutes to 2 hours, 5 - 20 times per day)
> crashes with a signal 11 (segfault) when I'm zooming or panning in
> pcbnew. The crash seems to occur when I'm using the onboard Intel video
> card and not (so far - I've only tested a small amount) when I use an
> Nvidia card.
>
> The xorg logs and gdb files posted above are the only evidence I have
> for the crash other than having to log in again. I don't know how to
> interpret them or provide any more insight because I'm unfamiliar with
> the inner workings of pcbnew, X, and the video drivers. (I'm still not
> even sure which direction a backtrace goes in.) I don't know what
> further methods of investigation I should be pursuing or where to go to
> learn them. In fact you, Dick, are the only human I've been able to
> elicit any response from in the 6 months I've been struggling with this
> problem. Thank you for that!

Thanks. But most of what I did was simply say, "yes, I hear you, and those that have
raised issues like yours eventually found it to be related to bugs in the Intel video
drivers, simply because after changing that code out, the stack started working."

I'd be inclined to simply say that again, if it helps.

BTW, In six months you probably could have mowed enough lawns to pay for a $250 computer
from Wallmart or other, eh?
Sometimes we forget how cheap this hardware really has gotten. (Of course I only think in
terms of desktop machines, I've never become dependent on a laptop.)

I suggest we close this bug then.

Thanks for the summary report.

If you can ever find the name of the guy who is writing your driver, say by an embedded
email address in the code or such, you might send him a link to this thread.

Or simply send him some vitamins, as I mentioned earlier.

Dick

Revision history for this message

Argyle (kruegejj) wrote on 2012-01-27:

#14

I'd object to closing this bug as it hasn't been fixed, nor has it even been identified what the real underlying problem is. As far as I know, pcbnew could be passing something illegal to X. I really have no idea how to find the piece of code responsible for the crash.

I'm about to embark on another round of fairly intense layout with pcbnew, which will be a good test to see if this is a problem that is eliminated by using a different driver or just less intermittent. I couldn't figure out how to use a different driver without switching video cards to see if it was just the intel driver.

The computer is less than 8 months old and, as far as I know, has a fairly popular, standard, and up-to-date video device.

Advice to mow lawns or send vitamins to programmers comes off as snarky, and doesn't strike me as a very productive or respectful way to address this bug. It really only serves to increase frustration levels.

Again, thank you for your help,
Joshua

Revision history for this message

Dick Hollenbeck (dickelbeck) wrote on 2012-01-28:

#15

On 01/27/2012 05:15 PM, Argyle wrote:
> I'd object to closing this bug as it hasn't been fixed, nor has it even
> been identified what the real underlying problem is. As far as I know,
> pcbnew could be passing something illegal to X. I really have no idea
> how to find the piece of code responsible for the crash.
>
> I'm about to embark on another round of fairly intense layout with
> pcbnew, which will be a good test to see if this is a problem that is
> eliminated by using a different driver or just less intermittent. I
> couldn't figure out how to use a different driver without switching
> video cards to see if it was just the intel driver.
>
> The computer is less than 8 months old and, as far as I know, has a
> fairly popular, standard, and up-to-date video device.
>
> Advice to mow lawns or send vitamins to programmers comes off as snarky,
> and doesn't strike me as a very productive or respectful way to address
> this bug. It really only serves to increase frustration levels.
>
> Again, thank you for your help,
> Joshua

Insulting volunteers invariably means you get less from them. So no, my advice comes from
3 nodes deep into the problem solving decision tree. I think you are at the top of the
tree. Here are the assumptions I've made to get to my point of view in the decision tree:

1) the bug is in the Intel driver.

2) Intel has been a good corporate contributor to open source drivers, and there is
probably a developer or a team, from Intel, that wrote this buggy code originally, even if
it is now being supported mostly by volunteers. Intel's name has been mentioned a number
of times in various bug reports on the KiCad mailing list. At some point one has to
assume that they would like to know about problems before it starts costing them
business. I said send the vitamins to Intel, because I don't think you will have any
other way of reaching them. Phone call is not likely to not work, email may not work as
effectively. If you get a name of an *Intel* developer or a product manager with an
address, just imagine how astonished that person would be to receive a fed-exed bottle of
vitamins with a personal note from you explaining your problem along with a URL link to
this thread. Any product manager worth his salt or his commission will jump on the
problem. But no, you do not do this to volunteers, you do it to Intel, as a *favor*,
before they start losing business.

3) As soon as assumption 1) is verified, there will be no interest in this bug "as a KiCad
bug", and therefore you will not get any volunteers here to fix it. We have limits on our
sphere of concern, and it extends only to our sphere of influence. This leaves you with
precisely two options: send the vitamins, or spend another six months talking to yourself
on various mailing lists.

Insulting volunteers is basically the dumbest of the things you could do, so I am not
recommending it.

On 01/27/2012 05:15 PM, Argyle wrote:
> I'd object to closing this bug as it hasn't been fixed, nor has it even
> been identified what the real underlying problem is.  As far as I know,
> pcbnew could be passing something illegal to X.  I really have no idea
> how to find the piece of code responsible for the crash.
>
> I'm about to embark on another round of fairly intense layout with
> pcbnew, which will be a good test to see if this is a problem that is
> eliminated by using a different driver or just less intermittent.  I
> couldn't figure out how to use a different driver without switching
> video cards to see if it was just the intel driver.
>
> The computer is less than 8 months old and, as far as I know, has a
> fairly popular, standard, and up-to-date video device.
>
> Advice to mow lawns or send vitamins to programmers comes off as snarky,
> and doesn't strike me as a very productive or respectful way to address
> this bug.  It really only serves to increase frustration levels.
>
> Again, thank you for your help,
> Joshua

Insulting volunteers invariably means you get less from them.  So no, my advice comes from
3 nodes deep into the problem solving decision tree.  I think you are at the top of the
tree.  Here are the assumptions I've made to get to my point of view in the decision tree:

1) the bug is in the Intel driver.

2) Intel has been a good corporate contributor to open source drivers, and there is
probably a developer or a team, from Intel, that wrote this buggy code originally, even if
it is now being supported mostly by volunteers.  Intel's name has been mentioned a number
of times in various bug reports on the KiCad mailing list.  At some point one has to
assume that they would like to know about problems before it starts costing them
business.  I said send the vitamins to Intel, because I don't think you will have any
other way of reaching them.  Phone call is not likely to not work, email may not work as
effectively.  If you get a name of an *Intel* developer or a product manager with an
address, just imagine how astonished that person would be to receive a fed-exed bottle of
vitamins with a personal note from you explaining your problem along with a URL link to
this thread.  Any product manager worth his salt or his commission will jump on the
problem.  But no, you do not do this to volunteers, you do it to Intel, as a *favor*,
before they start losing business.

3) As soon as assumption 1) is verified, there will be no interest in this bug "as a KiCad
bug", and therefore you will not get any volunteers here to fix it.  We have limits on our
sphere of concern, and it extends only to our sphere of influence.  This leaves you with
precisely two options:  send the vitamins, or spend another six months talking to yourself
on various mailing lists.

Insulting volunteers is basically the dumbest of the things you could do, so I am not
recommending it.

Revision history for this message

Lorenzo Marcantonio (l-marcantonio) wrote on 2012-01-28:

#16

On Fri, Jan 27, 2012 at 11:15:34PM -0000, Argyle wrote:
> The computer is less than 8 months old and, as far as I know, has a
> fairly popular, standard, and up-to-date video device.

Anyway, it happened *once* to me on a machine bought in november...

We simply can't say "kicad doesn't work on intel video" even if IMHO it's only a bug in the driver...

--
Lorenzo Marcantonio
Logos Srl

Revision history for this message

Dick Hollenbeck (dickelbeck) wrote on 2012-01-28:

#17

On 01/28/2012 02:05 AM, Lorenzo Marcantonio wrote:
> On Fri, Jan 27, 2012 at 11:15:34PM -0000, Argyle wrote:
>> The computer is less than 8 months old and, as far as I know, has a
>> fairly popular, standard, and up-to-date video device.
> Anyway, it happened *once* to me on a machine bought in november...
>
> We simply can't say "kicad doesn't work on intel video" even if IMHO
> it's only a bug in the driver...

Agreed.

The folks who have reported the bugs, in some, if not all cases, mentioned which driver
and a specific version that did not work. That seems like a good idea, because drivers
can be fixed or broken at various revision levels.

Revision history for this message

Argyle (kruegejj) wrote on 2012-01-31:

#18

In a few days, when I have the time, I'll pull the nvidia out again, make sure I can reproduce the crash, and then give a full listing of all of the software versions installed on this machine.

Revision history for this message

BlackVodka (markus-burger1990) wrote on 2012-08-14:

#19

hwinfo-output.txt Edit (429.1 KiB, text/plain)

Sorry for digging out this old report, but I started to get the same bug reported by Argyle, and I'm pretty sure it's caused by the dead of my nvidia graphics card about a month ago and switching to the internal onboard gpu for now.
So, due to the above, I'm pretty sure the xorg-crash is caused by an faulty intel-driver.
Like Argyle already mentioned, neither activating the xorg-swat-update-ppa nor activating the xorg-edgers-ppa stopped the bug to appear.
It seems there wasn't any progress around this bug since january, so if you still like to get some log files or similar, just let me know what you'd need.
I'll also fill a bug report at the x-updates-channel of the Ubuntu-X-team.

System is a g31 chipset mainboard , linux mint 13 'maya' running xfce 4.10.

Revision history for this message

BlackVodka (markus-burger1990) wrote on 2012-08-14:

#20

apt-show-versions-output.txt Edit (136.9 KiB, text/plain)

package-versions

Revision history for this message

Tormod Volden (tormodvolden) wrote on 2014-03-22:

#21

There is an upstream bug report linked to Ubuntu bug #415357.

Revision history for this message

chemicalfan (mike-lumsden) wrote on 2014-03-25:

#22

These versions of Mint & Ubuntu are no longer supported - is this bug present in supported versions of these distros?

Revision history for this message

Angus Gratton (angusgr) wrote on 2014-07-21:

#23

I had this crash today in Debian Jessie (testing), same symptoms and stack trace (and I have an Intel driver.)

That's with xorg-xserver-core 2:1.15.99.904-1. Ubuntu 14.04 version is also 1.15 so I think bug probably still exists there also, but cannot confirm.

The Ubuntu bug report indicates it was a bug in xorg-xserver, but this version of xorg-xserver-core has that fix already:

(Commit here: http://cgit.freedesktop.org/xorg/xserver/commit/?id=863d528a9f76d0e8f122aebf19f8564a4c67a938 ).

In my case the bug consistently crashed xorg with every 10-15 minutes of Kicad use. Rebooting appears to have stopped it for now (I'm guessing due to random memory allocation.)

I've now installed debug symbols for xorg-xserver-core so if I get a proper stack trace (or any more information) I'll post back, and/or send it towards the Freedesktop maintainers. But I thought it would be useful to keep this bug posted too.

Revision history for this message

Angus Gratton (angusgr) wrote on 2014-11-19:

#24

I realised why my system still had the bug even though it should have been fixed in that xorg version. The current Debian package for xorg-xserver reverts the segfault fix, as it caused another regression. Have added more detail to the Debian bug here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752156#25

Until the fix comes downstream, any Debian-derived distro (Debian, Ubuntu, Mint) with Intel graphics is likely to experience this crash when running Kicad.

Revision history for this message

Wayne Stambaugh (stambaughw) wrote on 2015-07-20:

#25

This is not a KiCad bug so I'm marking it as invalid.