Summary: | crash when changing destination window in datawizard | ||
---|---|---|---|
Product: | [Applications] kst | Reporter: | Matthew Truch <matt> |
Component: | general | Assignee: | kst |
Status: | RESOLVED FIXED | ||
Severity: | crash | ||
Priority: | NOR | ||
Version: | 1.x | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Matthew Truch
2005-11-29 05:31:27 UTC
I am 99.5% sure you have an unclean build. I can't reproduce it, and the backtrace and the location both indicate a stale object. On Tue, Nov 29, 2005 at 04:45:42AM -0000, George Staikos wrote:
> I am 99.5% sure you have an unclean build. I can't reproduce it, and the
> backtrace and the location both indicate a stale object.
How very interesting and annoying. Annoying because it is silly.
Interesting as this was from a machine that has only ever ran kst from
rpms, and rpms are always generated from a clean build. If I'm still in
this 99.5% regime, I either have a bug in my kst spec file, or rpm isn't
upgrading things properly.
On Tuesday 29 November 2005 00:24, Matthew Truch wrote: > On Tue, Nov 29, 2005 at 04:45:42AM -0000, George Staikos wrote: > > I am 99.5% sure you have an unclean build. I can't reproduce it, and the > > backtrace and the location both indicate a stale object. > > How very interesting and annoying. Annoying because it is silly. > Interesting as this was from a machine that has only ever ran kst from > rpms, and rpms are always generated from a clean build. If I'm still in > this 99.5% regime, I either have a bug in my kst spec file, or rpm isn't > upgrading things properly. I ran all your example paths through a memory check also and not a single issue came up. The other option is that your Qt is buggy. On Tue, Nov 29, 2005 at 01:25:52PM -0000, George Staikos wrote:
> I ran all your example paths through a memory check also and not a single
> issue came up. The other option is that your Qt is buggy.
I have removed the rpm from my system, looked in the library paths to
make sure there are no lingering files, ran /sbin/ldconfig to clear
everything (?), and installed an old rpm. Still has the same problem on
this one machine (it crashes on my fc4 machine). If I install the rpm
for fc4 on a fc3 machine, it doesn't crash. I have even tried using
rpms that were built from your pristine tarballs (like 1.1.1) and it
still crashes on fc4.
I know nothing about libraries and the such (I'm really not a
programmer). How can I check this out?
On Tuesday 29 November 2005 18:19, Matthew Truch wrote:
> I know nothing about libraries and the such (I'm really not a
> programmer). How can I check this out?
Touch to say. I'm still not sure where it might be. Which gcc version do
you have? And which Qt rpm specifically?
"tough" - even spell checking can't get that one right :) On Tue, Nov 29, 2005 at 11:22:20PM -0000, George Staikos wrote:
> Touch to say. I'm still not sure where it might be. Which gcc version do
> you have? And which Qt rpm specifically?
[matt@cherry ~]$ gcc --version
gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[matt@cherry ~]$ rpm -q qt
qt-3.3.4-15.4
On Tuesday 29 November 2005 18:48, Matthew Truch wrote: > qt-3.3.4-15.4 That should be fine. > [matt cherry ~]$ gcc --version > gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) But this is more worrisome. Trolltech even advises against gcc 4.0. On Tuesday 29 November 2005 15:52, George Staikos wrote: | SVN commit 484288 by staikos: looks like it's a Qt difference of some sort. listBox() was null. Let's just work around. BUG: 117256 M +1 -1 datawizard.ui.h --- trunk/extragear/graphics/kst/kst/datawizard.ui.h #484287:484288 @@ -391,7 +391,7 @@ _onePlot->setChecked(true); } - if (_existingPlot->isEnabled() && _existingPlotName->listBox()->findItem(psave)) { + if (_existingPlot->isEnabled() && _existingPlotName->listBox() && _existingPlotName->listBox()->findItem(psave)) { _existingPlotName->setCurrentText(psave); } updateColumns(); |