[RQt-devel] another crash

[Michael Lawrence]

Yes, as it says at the top of type-handlers.cpp, we have to clean up many
uses of cleanup() in the marshallers.

Thanks,
Michael

On Fri, Nov 20, 2009 at 10:21 AM, Justin Talbot <justintalbot at gmail.com>wrote:

> 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
> >>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.r-forge.r-project.org/pipermail/qtinterfaces-devel/attachments/20091120/dd086665/attachment-0001.htm