[RQt-devel] another crash

[Michael Lawrence]

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/b778f942/attachment.htm