[RQt-devel] another crash

[Justin Talbot]

Works for me.

This change takes out the checks in marshal_QString and
marshal_QByteArray that were causing my crash. Is this safe to do now?

Index: qtbase/src/type-handlers.cpp
===================================================================
--- qtbase/src/type-handlers.cpp	(revision 200)
+++ qtbase/src/type-handlers.cpp	(working copy)
@@ -449,7 +449,7 @@
         } else {
           m->setSexp(qstring2sexp(*s));
         }
-        if(m->cleanup() || m->type().isStack() ) {
+        if(m->cleanup()) {
           delete s;
         }
       } else {
@@ -505,7 +505,7 @@
         } else {
           m->setSexp(rstringFromQByteArray(s));
         }
-        if(m->cleanup() || m->type().isStack() ) {
+        if(m->cleanup()) {
           delete s;
         }
       } else {


On Fri, Nov 20, 2009 at 7:18 AM, Michael Lawrence <lawremi at gmail.com> wrote:
> This bug should now be fixed. Let me know if it works for you, Deepayan.
>
> On Thu, Nov 19, 2009 at 10:01 AM, Michael Lawrence <lawremi at gmail.com>
> wrote:
>>
>>
>> On Thu, Nov 19, 2009 at 9:22 AM, Justin Talbot <justintalbot at gmail.com>
>> wrote:
>>>
>>> On Thu, Nov 19, 2009 at 8:54 AM, Michael Lawrence <lawremi at gmail.com>
>>> wrote:
>>> >
>>> >
>>> > On Thu, Nov 19, 2009 at 4:15 AM, Deepayan Sarkar
>>> > <deepayan.sarkar at gmail.com>
>>> > wrote:
>>> >>
>>> >> On Wed, Nov 18, 2009 at 2:49 PM, Deepayan Sarkar
>>> >> <deepayan.sarkar at gmail.com> wrote:
>>> >> > On Wed, Nov 18, 2009 at 1:46 PM, Deepayan Sarkar
>>> >> > <deepayan.sarkar at gmail.com> wrote:
>>> >> >> Any idea what's going wrong here?
>>> >> >>
>>> >> >> ### Just code:
>>> >> >>
>>> >> >> library(qtbase)
>>> >> >>
>>> >> >> gscene <- Qt$QGraphicsScene()
>>> >> >> rtxt <- gscene$addText("some text")
>>> >> >> rtxt
>>> >> >> (rtxt$toPlainText()) ## fine
>>> >> >
>>> >> > And as a confirmation that the <QList> thing is not a problem, I
>>> >> > get:
>>> >> >
>>> >> >> item0 <- gscene$itemAt(0, 0)
>>> >> >> item0
>>> >> > <environment: 0x9e21428>
>>> >> > attr(,"class")
>>> >> > [1] "QGraphicsTextItem"   "QObject"             "QGraphicsItem"
>>> >> > [4] "UserDefinedDatabase" "environment"
>>> >> >> item0$toPlainText()
>>> >> >
>>> >> >  *** caught segfault ***
>>> >>
>>> >> Other QGraphicsItem-s seem fine, so it must be the multiple
>>> >> inheritance (QObject+QGraphicsItem) problem of  QGraphicsTextItem
>>> >> again. Given that rtxt works but item0 doesn't, maybe it's a coercion
>>> >> problem somewhere in the wrapping stage?
>>> >>
>>> >
>>> > Everything method invocation fails with item0. The weird thing is that
>>> > the
>>> > environments are different. Every C++ pointer should have the same
>>> > environment, and this holds true for the other QGraphicsItem types.
>>> > This
>>> > indicates that the pointer being returned by itemAt() and items() is
>>> > incorrect.
>>> >
>>> > Just checked it, and it looks like the pointer retrieved by e.g.
>>> > itemAt()
>>> > points 8 bytes higher than the one from addText(). This happens at the
>>> > Smoke
>>> > level, but looking at their wrappers reveals nothing. Yes, they are
>>> > casting
>>> > to different types, (QGraphicsTextItem *) vs (QGraphicsItem *), but
>>> > that
>>> > shouldn't change the value of the pointer, should it? The same error
>>> > happens
>>> > for addWidget() and its QGraphicsProxyWidget return value. So yes it
>>> > seems
>>> > like a multiple inheritance issue, but I don't understand how a simple
>>> > cast
>>> > could cause this. Maybe it's just another C++ surprise?
>>> >
>>> >>
>>> >> -Deepayan
>>> >> _______________________________________________
>>> >> Qtinterfaces-devel mailing list
>>> >> Qtinterfaces-devel at lists.r-forge.r-project.org
>>> >>
>>> >>
>>> >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/qtinterfaces-devel
>>> >
>>> >
>>> > _______________________________________________
>>> > Qtinterfaces-devel mailing list
>>> > Qtinterfaces-devel at lists.r-forge.r-project.org
>>> >
>>> > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/qtinterfaces-devel
>>> >
>>> >
>>>
>>> I haven't looked at this problem, but casting can change the pointer's
>>> value in C++ when there's multiple inheritance. This is due to C++'s
>>> virtual function table mechanism for inheritance. For more info see
>>> section 4.4 of http://www-plan.cs.colorado.edu/diwan/class-papers/mi.pdf
>>>
>>
>> Alrighty then. Right now, we're using the introspection information of the
>> QGraphicsItem to resolve the class from the QGraphicsItem returned by
>> itemAt() down to QGraphicsTextItem (so that we can use methods like
>> toPlainText()).  But the pointer is still of QGraphicsItem type, so must be
>> cast appropriately via smoke->cast(). I'll fix this tonight.
>>
>>>
>>> Justin
>>
>
>