<div><br></div>Hi,<div><br></div><div>Issue #3 has been caused by a Qt Widget subclass (ToolView) accidentally overriding the virtual QWdiget::setVisible() method. ToolView objects contain the list of available components, the component properties pages, and so on. Because of the unintended method overriding, the ToolViews have entered into a not-defined state of being visible and not visible in the same time: the most derived class ToolView had the information of not being visible, while the QWidget parent class had the information of being visible. Thus, strange behavior has resulted.</div><div><br></div><div>As a fix, I've renamed ToolView's setVisible() method to setVisibleToolView(), and things started to work.</div><div><br></div><div>Best regards,</div><div><br></div><div> Zoltan</div><div><br></div><div><br>Zoltan Padrah <<a href="mailto:zoltan.padrah@gmail.com">zoltan.padrah@gmail.com</a>> ezt írta (2015. május 24., vasárnap):<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Issue #1 and #2 is fixed in the latest revision of the porting branch<br>
( <a href="https://github.com/ktechlab/ktechlab-0.3/tree/port-0.3.8-kde4-v1" target="_blank">https://github.com/ktechlab/ktechlab-0.3/tree/port-0.3.8-kde4-v1</a> ).<br>
Also this latest version should work with GPSim version older than<br>
0.26.<br>
<br>
<br>
Issue #1 has been fixed by changing the Qt3 compatibility-related<br>
container Q3PtrDict to the current container QHash< KtlQCanvasItem *,<br>
bool >. Apparently the Q3PtrDict has been abused (elements of "<br>
(void*)1 " have been inserted into it), and this seems to have caused<br>
object corruption.<br>
<br>
Issue #2 has been actually unrelated to corruption: some Qt signals<br>
have been triggered when a document has been being deleted, and these<br>
signals have been connected to slots on the document being destroyed.<br>
Thus a non-complete document object has been receiving signals, and<br>
this has been detected by Qt. The fix has been to disconnect relevant<br>
signals on the document's destructor.<br>
<br>
<br>
Issue #3 is still open.<br>
<br>
Have fun,<br>
<br>
 Zoltan<br>
<br>
<br>
2015-05-16 22:32 GMT+03:00 Zoltan Padrah <<a href="javascript:;" onclick="_e(event, 'cvml', 'zoltan.padrah@gmail.com')">zoltan.padrah@gmail.com</a>>:<br>
> Hi,<br>
><br>
> I'm sending this email to possibly avoid debugging effort duplication<br>
> by others, and to document my findings about crashes.<br>
><br>
> # 1. crashes when the mouse pointer moves over an item on the circuit:<br>
><br>
> This looks like some invalid assignmenet / reinterpretation of pointer<br>
> to me. A KtlQCanvasPolygonalItem is created, but before crashing, it<br>
> presents itself (when printed with qDebug() ) as an ECNode. Their<br>
> common base class is QCanvasItem.  Maybe it is a vptr corruption. See<br>
> a debug log and stack traces below. The invalid read happens because<br>
> an ECNode is bigger than a KtlQCanvasPolygonalItem, thus it tries to<br>
> read after the allocated region.<br>
><br>
> I don't know where the invalid cast is taking place, unfortunately...<br>
><br>
><br>
> created KtlQCanvasPolygonalItem at  KtlQCanvasItem(0xb083f420)<br>
>    in canvas item:  KtlQCanvasItem(0xb083f420)<br>
>    in canvas item:  KtlQCanvasItem(0xb083f420)<br>
>    in canvas item:  KtlQCanvasItem(0xb083f420)<br>
> test collides  KtlQCanvasItem(0x92c10c50, name =<br>
> "KtlQCanvasRectangle")  with  KtlQCanvasItem(0xb083f420)<br>
>    in canvas item:  KtlQCanvasItem(0xb083f420)<br>
> test collides  KtlQCanvasItem(0x92c140d0, name =<br>
> "KtlQCanvasRectangle")  with  KtlQCanvasItem(0xb083f420)<br>
>    in canvas item:  KtlQCanvasItem(0xb083f420)<br>
> test collides  KtlQCanvasItem(0x92c17550, name =<br>
> "KtlQCanvasRectangle")  with  KtlQCanvasItem(0xb083f420)<br>
>    in canvas item:  KtlQCanvasItem(0xb083f420)<br>
> test collides  KtlQCanvasItem(0x92c1a500, name =<br>
> "KtlQCanvasRectangle")  with  KtlQCanvasItem(0xb083f420)<br>
>    in canvas item:  ECNode(0xb083f420)<br>
> test collides  KtlQCanvasItem(0x92c21180, name =<br>
> "KtlQCanvasRectangle")  with  ECNode(0xb083f420)<br>
> =================================================================<br>
> ==22136==ERROR: AddressSanitizer: heap-buffer-overflow on address<br>
> 0xb083f488 at pc 0x081ad183 bp 0xbf96e448 sp 0xbf96e43c<br>
> READ of size 4 at 0xb083f488 thread T0<br>
>     #0 0x81ad182 in KtlQCanvasPolygon::areaPoints() const<br>
> ktechlab-0.3/src/canvas.cpp:1773<br>
>     #1 0x81a5dfa in collision_double_dispatch() ktechlab-0.3/src/canvas.cpp:1284<br>
>     #2 0x819d04b in KtlQCanvasRectangle::collidesWith(KtlQCanvasItem<br>
> const*) const ktechlab-0.3/src/canvas.cpp:1305<br>
>     #3 0x81ad770 in KtlQCanvas::collisions(Q3PointArray const&,<br>
> KtlQCanvasItem const*, bool) const  ktechlab-0.3/src/canvas.c<br>
> pp:1376<br>
>     #4 0x81ad98c in KtlQCanvasItem::collisions(bool) const<br>
> ktechlab/ktechlab-0.3/src/canvas.cpp:1325<br>
>     #5 0x81ada15 in KtlQCanvas::collisions(QRect const&)<br>
> ktechlab-0.3/src/canvas.cpp:1338<br>
>     #6 0x8136d88 in ItemDocument::itemAtTop(QPoint const&) const<br>
> ktechlab-0.3/src/itemdocument.cpp:490<br>
>     #7 0x80e9736 in CMManager::mouseMoveEvent(EventInfo const&)<br>
> /ktechlab-0.3/src/canvasmanipulator.cpp:230<br>
>     #8 0x8130a11 in ItemView::contentsMouseMoveEvent(QMouseEvent*)<br>
> ktechlab-0.3/src/itemview.cpp:428<br>
>     #9 0x8131f2e in CVBEditor::event(QEvent*) ktechlab-0.3/src/itemview.cpp:754<br>
><br>
> 0xb083f488 is located 12 bytes to the right of 92-byte region<br>
> [0xb083f420,0xb083f47c)<br>
><br>
> allocated by thread T0 here:<br>
>     #0 0xb72a314e in operator new(unsigned int)<br>
> (/usr/lib/i386-linux-gnu/libasan.so.2+0x9314e)<br>
>     #1 0x808cc1d in Connector::updateDrawList()<br>
> ktechlab-0.3/src/connector.cpp:262<br>
>     #2 0x815c270 in ICNDocument::rerouteInvalidatedConnectors()<br>
> ktechlab-0.3/src/icndocument.cpp:778<br>
>     #3 0xb4def0f6 in QMetaObject::activate(QObject*, QMetaObject<br>
> const*, int, void**) (/usr/lib/i386-linux-gnu/libQtCore.so.4+0x18e0f6)<br>
>     #4 0xb4e3f434 in QTimer::timeout()<br>
> (/usr/lib/i386-linux-gnu/libQtCore.so.4+0x1de434)<br>
>     #5 0xb56d47f3 in QApplicationPrivate::notify_helper(QObject*,<br>
> QEvent*) (/usr/lib/i386-linux-gnu/libQtGui.so.4+0x1397f3)<br>
><br>
><br>
><br>
> # 2. crahes / aborts because of assertion failure inside the circuit's<br>
> moc object: probably it is the same type of problem as #1, but I have<br>
> not started debugging it. A Qt assertion fails, probably because of<br>
> corrupted pointers inside the application.<br>
><br>
><br>
> # 3. The toolbars / toolview's don't show anything, and they don't work.<br>
><br>
>  In katemdi.cpp, some (crazy?) combinations of VBox / HBox / QSlider<br>
> widgets are placed in each other, and they should show the list of<br>
> components. However, the list of components appears (as a small,<br>
> garbage-like rectangle), but it is not doing anything. A pushbotton in<br>
> the place of the component list is working properly: it appears, it<br>
> redraws and it can be clicked. If you want to debug this, then<br>
> condsier enabling DiagnosticStyle in main.cpp -- it draws a rectangle<br>
> around each widget, do it can be seen, which widget is where.<br>
> Maybe as an experiment, the component list should be instantiated<br>
> separately, to see if the component list, or the HBox,VBox, QSlider is<br>
> the source of this bug.<br>
</blockquote></div>