My Struggle with Qwt

[DerAlbi]

Hi,
i am happy to have found a project like CopperSpice. Really grateful. My application will heavily make use of graphing and displaying waveforms, so i need a useful plotting widget. I chose Qwt, because.. no alternative under LGPL (afaik).
If this translation works, i am willing to share the resulting Qwt here, but i am new to OpenSource in this regard and I surely cant test every aspect.. but i guess its better to start somewhere in between for anyone else rather than starting from scratch.

I am totally new to this, and i am struggling extremely. See this as a log, help if you feel you can help

• many CS_PROPERTY_READ / CS_PROPERTY_WRITE macros ended up on the same line; this somehow confused the compiler.

• qSport, qUpperBound, qLowerBound... do not exist. Ok. Using STL-Replacement as documented. But CS is C++17, so std::ranges are not available which would be the true replacement[
• WHAT IS GOING ON with overloaded slots???

  Code: Select all

  CS_SLOT_1(Public, void setText(const QString & un_named_arg1,QwtText::TextFormat textFormat = QwtText::AutoText))
  CS_SLOT_2(setText) 
  CS_SLOT_1(Public, virtual void setText(const QwtText & un_named_arg1))
  CS_SLOT_2(setText)

  no matching function for call to ‘QMetaObject_T<QwtTextLabel>::register_method(const char [8], <unresolved overloaded function type>, QMetaMethod::MethodType, const char [95], QMetaMethod::Access&)’

  Ok..? The alternative CS_SLOT_OVERLOAD does not work for more than one argument i guess?
  So I invented

  Code: Select all

  #define CS_SLOT_2x(slotName, ...) \
           const_cast<QMetaObject_T<cs_class>&>(cs_class::staticMetaObject()).register_method(  \
              #slotName #__VA_ARGS__ , static_cast<void (cs_class::*)(__VA_ARGS__)>(&cs_class::slotName), QMetaMethod::Slot, va_args, accessType); \
           \
           cs_regTrigger(cs_number<cntValue + 1>{} ); \
        }

  [should probably be renamed to CS_SLOT2overloaded() or something]
  and now I use

  Code: Select all

  CS_SLOT_1(Public, void setText(const QString & un_named_arg1,QwtText::TextFormat textFormat = QwtText::AutoText))
  CS_SLOT_2x(setText, const QString &, QwtText::TextFormat)
  
  CS_SLOT_1(Public, virtual void setText(const QwtText & un_named_arg1))
  CS_SLOT_2x(setText, const QwtText &)

  which seems to compile (?)
• Arrrrgh nooh.. same issue at CS_SIGNAL_2 ??
  Ok. Using CS_SIGNAL_OVERLOAD(..) with the argument types in round brackets
• QString.setNum().. simply not there. I am using QString{QByteArray{}.setNum( ...)}
• QString.sprintf(...) simply not there. No idea about a replacement
• The 1.7.0 Overhaul of QVariant creates a lot of work for Variants. Helper functions such as qVariantSetValue or qvariant_cast should not have been removed (imho)
  My thought is: yes, i understand there is a better way. But I also think as fork of something much bigger with much more infrastructure one should try to minimize migration hurdles. Declare them deprecated, (resulting in a warning) but a static_assert is harsh!
• "connect" cannot be called within a const-member function as it self is not const.

...and it actually compiles with a lot of work.
Unfortunately it crashes. And unfortunately i come from an embedded development background. No Idea what is going on

tcache_get 0x00007f7028b93277
__GI___libc_malloc 0x00007f7028b93277
operator new(unsigned long) 0x00007f7029548d55
QFontEngineFT::loadGlyph(QFontEngineFT::QGlyphSet*, unsigned int, QFixed, QFontEngine::GlyphFormat, bool) const 0x00007f702bb270bf
QFontEngineFT::loadGlyphFor(unsigned int, QFixed, QFontEngine::GlyphFormat, QTransform const&, bool) 0x00007f702bb2a2be
QFontEngineFT::lockedAlphaMapForGlyph(unsigned int, QFixed, QFontEngine::GlyphFormat, QTransform const&, QPoint*) 0x00007f702bb2b57b
QRasterPaintEngine::drawCachedGlyphs(int, unsigned int const*, QFixedPoint const*, QFontEngine*) 0x00007f702b9eb026
QRasterPaintEngine::drawTextItem(QPointF const&, QTextItem const&) 0x00007f702b9ede46
QPainterPrivate::drawTextItem(QPointF const&, QTextItem const&, QTextEngine*) 0x00007f702b9901f5
QTextLine::draw(QPainter*, QPointF const&, QTextLayout::FormatRange const*) const 0x00007f702bd17e71
qt_format_text(QFont const&, QRectF const&, int, QTextOption const*, QString8 const&, QRectF*, int, int*, int, QPainter*) 0x00007f702b985256
QPainter::drawText(QRectF const&, int, QString8 const&, QRectF*) 0x00007f702b98b4cd
-----------------------
QwtPainter::drawText qwt_painter.cpp:371
QwtPlainTextEngine::draw qwt_text_engine.cpp:229
QwtText::draw qwt_text.cpp:615
QwtPlotMarker::drawLabel qwt_plot_marker.cpp:335
....
QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) 0x00007f7029c7c017
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) 0x00007f7029c7c456
QCoreApplication::exec() 0x00007f7029c77176
main main.cpp:210
__libc_start_main 0x00007f7028b1db97
_start 0x0000564e59bd031a

I mean, its clear that new crashes, but i dont know why. Debugger only shows assembly beyond what i marked with "----------". Nothing noteworthy about

painter->drawText( rect, flags, text );

Code: Select all

void QwtPainter::drawText( QPainter *painter, const QRectF &rect,
        int flags, const QString &text )
{
    painter->save();
    qwtUnscaleFont( painter );
    painter->drawText( rect, flags, text );
    painter->restore();
}

with https://imgur.com/a/8oJJJP3 (sry, cant figure out the img-tag).
Yeah, somehow the whole QPainter interface is broken. When commenting out crashing code.. i ended up crahsing within "QPainter painter( this );"
I dont see how this could fail. But again, impossible to debug based on assembly beyond a certain point.
I will try to remove any unnecessary code and upload a zip. Maybe someone could have a look?

[barbara]

Thank you so much for your interest in CopperSpice. We will do our best to reply to all of your questions.

(1)

many CS_PROPERTY_READ / CS_PROPERTY_WRITE macros ended up on the same line

This appears to be an issue in PepperMill and was reported very recently. We will look at fixing this.

(2)

What is going on with overloaded slots?

This happens when there are multiple overload candidates. Please refer to our CS Overview documentation for some examples. They are located towards the bottom of the page.

https://www.copperspice.com/docs/cs_overview/m_macros_metaobj.html

Code: Select all

CS_SLOT_1(Public, void setText(const QString & un_named_arg1,QwtText::TextFormat textFormat = QwtText::AutoText))
CS_SLOT_OVERLOAD(setText, (const QString &, QwtText::TextFormat) ) 

CS_SLOT_1(Public, virtual void setText(const QwtText & un_named_arg1))
CS_SLOT_OVERLOAD(setText, (const QwtText &) )

(3)

QString.setNum().. simply not there. I am using QString{QByteArray{}.setNum( ...)}

This should be replaced with QString::number or QStringParser::number. Please have a look at our QString documentation under the heading of "Removed or Unsupported Methods".

https://www.copperspice.com/docs/cs_api/class_qstring8.html#changes-qstring

(4)

QString.sprintf(...) simply not there. No idea about a replacement

You need to use QStringParser::formatArgs()

(5) As you mentioned our changes for QVariant were substantial and worthwhile. In our Overview docs we have noted the changes, please take a look at item #6. This problem with adding deprecated methods to support legacy code raises the question about when do you then remove the deprecated methods? The CS team we will revisit this question.

https://www.copperspice.com/docs/cs_overview/cs-migration.html

(6)

"connect" cannot be called within a const-member function as it self is not const.

Can you provide the exact line of code with is failing? There are multiple ways to call connect().

(7)
In terms of QFontEngineFT and QPainter we currently have no reported issues and these classes are used very heavily in multiple CopperSpice applications. A crash which occurs in "new" usually indicates a corrupted heap resulting from undefined behavior in early code. Yes, these can be hard to track down and using Valgrind or Address Sanitizer can help out.

Please provide a small reproducible test case. Also, let us know what platform you are building on. It is possible that we can help you debug your code and determine the real issue.

Barbara

[DerAlbi]

Barbara, thank you so much for redirecting me to your documentation. Please understand that even with existing documentation, it is not always easy to find it and to recognize what applies to the problem and what is "useless" for the situation.

https://filebin.net/e4y651zvo6e2zuqc
Here is the mess aka "small reproducible test case" . It is the Qwt example "sinusplot" with Qwt-sources that i... "worked on". I think the CMakeLists.txt needs a specific definition of CopperSpice_DIR for your machine. The link expires one week from now. I am running Linux Mint.
If anyone could be so kind to have a look at it, at least confirm it crashing or anyhting - that would be great.
Again, i am confident with C++, but as I focus on embedded development, the last time i had to deal with distributed code across libraries is a few years back.. The original QT example works flawless. I dont see that I could have messed something up that badly to be honest :-/
Well, to be clear, i havent worked your documentation references in. Basically i would need to start all over again, i think.
The only unclean thing i did was to give my QString::sprintf-replacement a char-buffer of hardcoded 128bytes. I dont see this limit being reached as it was only used to to form coordinate pair strings in the form of "50.34, 233.23".

(5) I fully understand the philosophical issue. I think one can easily say "never" in certain circumstances. As long as it is a one-line wrapper and basically compatibility-helper, i think it is worth while keeping them as deprecated. When the programmer is interested in warning-free code, the compiler/linker will eventually get rid of the function for you. If the programmer is not interested in warning-free code the wrapper is likely to be of no concern anyway. The argument in my head is: it is easier to refactor compiling code than broken code. Just in terms of verification and observation of behavioural changes.

(6) Unfortunately i only navigated from error message to error message in what appears to be 100 files. I simply removed the const from the member function and then it could call conect(). Without the error message i cant find it anymore. It was something along the lines of

Code: Select all

void Class::Method() const
{
    ...
    connect(Member, SLOT(slot), SIGNAL(signal)); 
}

Tbh, I dont see this as a problem and it is an expected consequence when replacing MOC. Of course, connecting a signal changes the state of the object - even if that is debatable if you dive into it. This is only annoying when a whole call hierarchy of const-functions become forcefully un-const-ed, but in this circumstance it was corrected easily.Throwing mutable at this compatibility issue would not be pretty i guess.

[DerAlbi]

I enabled address sanitizer as suggested, however, i do not get any weird behaviour. The stranges thing that happens is that the programm actually runs differently. And i am now able to view output messages that may actually have been there before.

QObject::connect() QwtPlot::legendDataChanged(QVariant,QList<QwtLegendData>) Unable to connect to receiver in QwtPlot Signal Index: -1 Slot Index: -1

which happens here:

Code: Select all

QObject::connect(
            plot, SIGNAL(legendDataChanged(QVariant,QList<QwtLegendData>)),
            plot, SLOT(updateLegendItems(QVariant,QList<QwtLegendData>))

with legendDataChanged and updateLegendItems declared as:

Code: Select all

CS_SIGNAL_1(Public, void legendDataChanged(const QVariant & itemInfo,const QList <QwtLegendData> & data))
    CS_SIGNAL_2(legendDataChanged,itemInfo,data) 
    
    CS_SLOT_1(Private, void updateLegendItems(const QVariant & itemInfo,const QList <QwtLegendData> & legendData))
    CS_SLOT_2(updateLegendItems) 

Is it possible that the signature difference is a problem? I mean, connect knows nothing about (const-)references...

As far as i can understand, connect() works based on strings.. how perfect must the matching be? Do whitespaces between parameters and/or const specifier make a difference?

Oh and by now, i realize my source package above will not compile because i used my own Macros for slots. I thorught you couldnt have commas in preprocessor macros. I am reverting to the propper CS_SLOT_OVERLOAD equivalents... (doesnt make a difference)

EDIT: yeah the const references make a difference. Does not solve the Address-Sanitizer problem. Unfortunately, since those sanitizers are not available on embedded systems i have no experience with them on x64. All i get is an exit code 1
So yeah, there is something broken, but it is not clear what.
This is my current state: https://filebin.net/tghnwq48lele6mwy

EDIT2: Ok. ASAN ist of no use, i would need to build CopperSpice with ASAN and debug information enabled. [I just did it but i still get no source locations, for debugging - i have no idea what i am doing]
I dont say that this is copperspices fault. One could still feed a library with garbage and this problem could occur. But it hints to some incompatibility issue. Not sure how to tackle that

[DerAlbi]

Ok, i think i have narrowed it down a little bit. I have compiled different example applications of Qwt. Actually some examples work.
My observation so far is, that there is an incompatibility when text appears rotated.

Have a look: https://imgur.com/J2FwZuA
After redraw: https://imgur.com/a/gpJfhY3

I can set the label rotation of the months to 0 and delete the Y-axis label (i dont have access to its rotation) and the application is stable.
So any other orientation than 0° crashes.

Call stack looks like

__asan_on_error main.cpp:48
<unknown> 0x00007f2ed4a25863
operator delete[](void*) 0x00007f2ed4a2044d
QFontEngineFT::QGlyphSet::clear() 0x00007f2ed2a2f818
QFontEngineFT::QGlyphSet::~QGlyphSet() 0x00007f2ed2a2f8ee
std::enable_if<std::__and_<std::__not_<std::__is_tuple_like<QFontEngineFT::QGlyphSet> >, std::is_move_constructible<QFontEngineFT::QGlyphSet>, std::is_move_assignable<QFontEngineFT::QGlyphSet> >::value, void>::type std::swap<QFontEngineFT::QGlyphSet>(QFontEngineFT::QGlyphSet&, QFontEngineFT::QGlyphSet&) 0x00007f2ed2a3b0be
std::reverse_iterator<std::_Deque_iterator<QFontEngineFT::QGlyphSet, QFontEngineFT::QGlyphSet&, QFontEngineFT::QGlyphSet*> > std::_V2::__rotate<std::reverse_iterator<std::_Deque_iterator<QFontEngineFT::QGlyphSet, QFontEngineFT::QGlyphSet&, QFontEngineFT::QGlyphSet*> > >(std::reverse_iterator<std::_Deque_iterator<QFontEngineFT::QGlyphSet, QFontEngineFT::QGlyphSet&, QFontEngineFT::QGlyphSet*> >, std::reverse_iterator<std::_Deque_iterator<QFontEngineFT::QGlyphSet, QFontEngineFT::QGlyphSet&, QFontEngineFT::QGlyphSet*> >, std::reverse_iterator<std::_Deque_iterator<QFontEngineFT::QGlyphSet, QFontEngineFT::QGlyphSet&, QFontEngineFT::QGlyphSet*> >, std::random_access_iterator_tag) 0x00007f2ed2a3c238
QList<QFontEngineFT::QGlyphSet>::move(long, long) 0x00007f2ed2a3c610
QFontEngineFT::loadGlyphSet(QTransform const&) 0x00007f2ed2a31c3d
QFontEngineFT::loadGlyphFor(unsigned int, QFixed, QFontEngine::GlyphFormat, QTransform const&, bool) 0x00007f2ed2a360be
QFontEngineFT::lockedAlphaMapForGlyph(unsigned int, QFixed, QFontEngine::GlyphFormat, QTransform const&, QPoint*) 0x00007f2ed2a3757b
QRasterPaintEngine::drawCachedGlyphs(int, unsigned int const*, QFixedPoint const*, QFontEngine*) 0x00007f2ed28f7026
QRasterPaintEngine::drawTextItem(QPointF const&, QTextItem const&) 0x00007f2ed28f9e46
QPainterPrivate::drawTextItem(QPointF const&, QTextItem const&, QTextEngine*) 0x00007f2ed289c1f5
QTextLine::draw(QPainter*, QPointF const&, QTextLayout::FormatRange const*) const 0x00007f2ed2c23e71
qt_format_text(QFont const&, QRectF const&, int, QTextOption const*, QString8 const&, QRectF*, int, int*, int, QPainter*) 0x00007f2ed2891256
QPainter::drawText(QRectF const&, int, QString8 const&, QRectF*) 0x00007f2ed28974cd
QwtPainter::drawText qwt_painter.cpp:371
QwtPlainTextEngine::draw qwt_text_engine.cpp:229
QwtText::draw qwt_text.cpp:615
QwtScaleDraw::drawLabel qwt_scale_draw.cpp:664
QwtAbstractScaleDraw::draw qwt_abstract_scale_draw.cpp:190
....

Every crash* i observed ends up in QFontEngineFT somewhere (When ASAN is enabled).
Again, this by no means, means that CS is broken... just incompatible in some way.
Every project i tried where text wasnt rotated.. just ran.

*) technically hitting __asan_on_error is not a crash, just the beginning of a really bad time. On the other hand it crashes inside delete[] which still indicates that the problem is actually elsewhere. Since the error is not caught when it happens (and ASAN is enables in my code), it means the heap-destruction must be occuring in CopperSpice-codepaths. Which means it is either a bug in CopperSpice or bad parameters to the CopperSpice-API are given.
The last call in "my" code is

Code: Select all

painter->drawText( rect, flags, text );

where the parameters look completely normal.

QRectF rect{.xp=0, .yp=-2, .w=21, .h=15}
int flags = 0;
QString Text = "-20"
painter is some QPainter.

Now interesting is, that "-20" is not a string that is at an angle. It is part of the temperature-scale.

So setting a breakpoint at painter->drawText( rect, flags, text ); reveals the draw order of the texts (during redraw, the first draw seems to succeed always; y-Axis label disabled):
- "Temperature of Friedberg/Germany" [the title, 0° angle]
- "-20", "-10", "0", "10", "20", "30", 40" [the y-axis labels, °0 angle]
- "January", ..., "December" [the x-Axis labels at some weird angle]
- "2007" [the x-Axis title at 0°]
- "Average", "Range" [the legend at 0°]
- "Temperature of Friedberg/Germany" [the title, 0° angle, seems to repeat drawing]
- "-20" BOOOOOOOOOOOOOM

I also confirmed that this happens with the downloaded libraries as well as with the self-build libraries [and with the self build ones it happens regardless of Release or Debug build. Yes i tried the debug build. Even a Threadripper struggels at times

---
Ok, i found the code that is responsible for label-rotation. Hardcoding the rotation to 0.0 or simply disabling the rotation part of the transformation matrix makes the application stable.
So somehow the combination of:

Code: Select all

QTransform::rotate( angle != 0.0)
QPainter::setWorldTransform(QTransform)
QPainter::drawText()

is responsible for my problem.

I am not sure how i can do more without being able to really debug CopperSpice and enabling AdressSanitizer there. I have no idea where to start to change the scripts.

[barbara]

Glad to hear you are making progress.

Barbara, thank you so much for redirecting me to your documentation. Please understand that even with existing documentation, it is not always easy to find it and to recognize what applies to the problem and what is "useless" for the situation.

We understand finding all the relevant documentation takes time. The team has been through many iterations of the CS Overview docs and we are improving it all the time based on feedback. Feel free to ask question about where things are if you get stuck.

If anyone could be so kind to have a look at it, at least confirm it crashing or anyhting - that would be great.

You are in the queue and we will take a look at this.

The only unclean thing i did was to give my QString::sprintf-replacement a char-buffer of hardcoded 128bytes.

I would suggest changing these to use QString::formatArg()

If the issue you are seeing points to something we can improve in CopperSpice I can assure you it will happen. As you pointed out it is possible we are allowing "bad" data through. And yep, this also falls under the category of something we will resolve. We need a bit of to make sure we can repeat this and then do a bit of testing. Thanks for your patience.

Barbara

[ansel]

The connect method in Qt using the SIGNAL and SLOT macros simply ignored qualifiers like const which can hide problems. We disagree with this approach and feel it is misleading. When we designed the CopperSpice registration system and removed moc, we were careful to preserve the exact data types through the entire connection process. Our connect method requires that the signature match exactly which adheres to the philosophy of strong type checking in C++.

The preferred syntax for a connect method is to remove the SIGNAL and SLOT macros and pass method pointers instead. This provides compile-time static type checking that the signal and slot are compatible.

Rewriting your connect example would produce this code:

Code: Select all

QObject::connect(
            plot, &QwtPlot::legendDataChanged,
            plot, &QwtPlot::updateLegendItems)

As a side issue, since Mint is not a platform that we have tested on, we would be curious to see you try building our KitchenSink example program and see if you have any issues.

[DerAlbi]

KitchenSink runs like a charm! But it does not have rotated text (that i can see).
I am not sure that this is really a case of bad data input.. "My" code is clean as per AddressSanitizer and the only way i can see having a heap corruption would be

Code: Select all

free(ptr);
ExternalLibraryCall(ptr);

or something equivalent.

As for Mint being unsupported.. it is basically Ubuntu 18.04. Should not be an issue.

I try working on a minimal example without Qwt that has rotated Text. But... i newer knew what i was doing when using QT. I dont know what i am doing when using CS; [This is the thing i actually wanted to learn] So distilling it down.. well, i'll get back to you.

One thing that could help me is if you guys give me a build-script that enables AddressSanitizer in gcc in compiler and linker comand line for CS.
This has to be placed somewhere at the right spot...

Code: Select all

add_compile_options(-O0 -g3 -fno-omit-frame-pointer -fsanitize=address)
add_link_options(-fsanitize=address)

And somehow I need access to the source code location when debugging external code. That i may be able to google that myself.

Thank you for your responsiveness!

I would suggest changing these to use QString::formatArg()

I have fully cleaned up the code-changes according to your suggestions (all of the above). I am doing my best, but it still crashes.

[DerAlbi]

Ok, that was satisfying
Minimal code: 48 Lines.
This text drawing:

Code: Select all

void drawText(QPainter *qp)
{
	QTransform Rotation;
	qp->setTransform(Rotation.rotate(10.2));
	qp->drawText(50, 50, "Hello World");

	qp->setTransform(Rotation.rotate(20.2));
	qp->drawText(150, 50, "Hello World");

	qp->resetTransform();
	qp->drawText(50, 150, "Hello World");

	qp->setTransform(Rotation);
	qp->drawText(150, 150, "Hello World");
	DrawCounter = DrawCounter+1;

	qp->resetTransform();
	qp->drawText(300, 200, QString::number(DrawCounter));
}

Produces: https://imgur.com/a/rVdHsYx
Sometimes it is clean, but its random. Its broken more often than not. I fiddled around until I got a visible artefact at the first draw call. Note that i only get an artefact here, not an ASAN-failure. Only on redaw it crashes hard.

It seems to matter that the rotation changes. A static rotation seems fine. Different rotations arent.

This code

Code: Select all

void drawText(QPainter *qp)
{
	QTransform Rotation;
	qp->setTransform(Rotation.rotate(10.2));
	qp->drawText(150, 150, "Hello World");
	DrawCounter = DrawCounter+1;
	
	qp->resetTransform();
	qp->drawText(300, 200, QString::number(DrawCounter));
}

also crashes - but only on redraw. Not getting an artefact does not mean its healthy.

Here is the full source code: https://filebin.net/n5nf5zaiyp8uak3m
The link expires in one week.

If you guys think this bug is system specific, say so; we will figure something out.

--
ok, i tried looking around in the CS-code but i have no idea what i am doing. Cant do it on my own. I am really sorry, i cant help any further due to lack of debugability. Its unfortnutely hidden behind a learning curve too steep to climb for me

[ansel]

Thank you so much for doing a great deal of debugging and producing such a small test case. I have downloaded your samples and we will take a look at reproducing the issue you are seeing.

We knew Mint was similar to Ubuntu, however a year ago someone had some obscure incompatibilities but were never able to give us a detailed report of what was happening.

If you do happen to be interested in using address sanitizer, typically all that is needed is to set the CXXFLAGS before calling CMake. I use a script that looks like this:

Code: Select all

export CXXFLAGS="-fsanitize=address"

cmake -GNinja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=<target directory> <source directory>

This requires no changes to the project CMakeFiles and sets the source path correctly, so it is very convenient.

I know you reached the boundary of what you could determine. The initial debugging you have already done is helpful to narrow the search. If you want to learn more, we are glad to share information with you as we go along.