Bug 123048

This is the same problem experienced by debian unstable a while back.

See this thread:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329231

The bug was in kst and dealt with the following:

--- quoted from Josh Metzler -----

"Finally, I ran kst under gdb with qt-x11-free-dbg installed and set a 
breakpoint at QPixmap::init just before creating a plot.  After lots of 
continues with valid parameters (w or h is 0 and depth is 0, or depth is 
-1 or 24 on my display), I got one with depth set to 8.  This doesn't 
cause a problem here because w = h = 0, so a null pixmap of depth 8 is 
created.  When it is resized, however, it causes a problem.  With the old 
qt behavior, an invalid depth was ignored when creating a null pixmap.

So, the bug is in lines 84, 124, 389 of kst/kst/kst2dplot.cpp where it 
specifies a depth of 8 when creating the KstBackBuffer.  It should 
probably use the default of -1 and let qt create a QPixmap of the 
appropriate bit depth."

---- end quote ------

So, not sure if this is related.  For what it's worth, I'm using KDE 3.5.1 and 
Qt 3.3.4 on Kubuntu without problems.

-Ted

Doing a quick grep, I don't see any place that a QPixmap is getting 
initialized with an invalid depth...  I wonder if there is some other change 
in Qt 3.3.4 --> 3.3.5 that enforces a more strict behaviour that we are 
violating somewhere?

-Ted

On Friday 03 March 2006 16:02, Ted Kisner wrote:
| This is the same problem experienced by debian unstable a while back.
|
| See this thread:
|
| http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329231
|
| The bug was in kst and dealt with the following:
|
| --- quoted from Josh Metzler -----
|
| "Finally, I ran kst under gdb with qt-x11-free-dbg installed and set a
| breakpoint at QPixmap::init just before creating a plot.  After lots of
| continues with valid parameters (w or h is 0 and depth is 0, or depth is
| -1 or 24 on my display), I got one with depth set to 8.  This doesn't
| cause a problem here because w = h = 0, so a null pixmap of depth 8 is
| created.  When it is resized, however, it causes a problem.  With the old
| qt behavior, an invalid depth was ignored when creating a null pixmap.
|
| So, the bug is in lines 84, 124, 389 of kst/kst/kst2dplot.cpp where it
| specifies a depth of 8 when creating the KstBackBuffer.  It should
| probably use the default of -1 and let qt create a QPixmap of the
| appropriate bit depth."
|
| ---- end quote ------
|
| So, not sure if this is related.  For what it's worth, I'm using KDE 3.5.1
| and Qt 3.3.4 on Kubuntu without problems.
|
| -Ted
|
| _______________________________________________
| Kst mailing list
| Kst@kde.org
| https://mail.kde.org/mailman/listinfo/kst

SVN commit 515703 by staikos:

fix Qt 3.3.5 crash
BUG: 123048


 M  +3 -3      kst2dplot.cpp  


--- branches/kst/1.2/kst/kst/kst2dplot.cpp #515702:515703
@@ -89,7 +89,7 @@
                  KstScaleModeType xscale_in,
                  double xmin_in, double ymin_in,
                  double xmax_in, double ymax_in)
-: KstPlotBase("Kst2DPlot"), _buffer(8) {
+: KstPlotBase("Kst2DPlot") {
   // must stay here for plot loading correctness
   _pos_x = 0.0;
   _pos_y = 0.0;
@@ -140,7 +140,7 @@
 
 
 Kst2DPlot::Kst2DPlot(const QDomElement& e)
-: KstPlotBase(e), _buffer(8) {
+: KstPlotBase(e) {
   QString in_tag = "unknown";
   KstScaleModeType yscale_in = AUTOBORDER, xscale_in = AUTO;
   double xmin_in = 0, ymin_in = 0, xmax_in = 1, ymax_in = 1;
@@ -414,7 +414,7 @@
 // FIXME: broken copy constructor
 // what is broken?
 Kst2DPlot::Kst2DPlot(const Kst2DPlot& plot, const QString& name)
-: KstPlotBase(plot), _buffer(8) {
+: KstPlotBase(plot) {
   QString plotName;
 
   _type = "Plot";

*** Bug 127999 has been marked as a duplicate of this bug. ***