[Kde-bindings] calling KParts::MainWindow#action_collection causes a crash with recent revision of korundum from 4.4 branch

[Arno Rehn]

On Thursday 28 January 2010 16:59:17 Richard Dale wrote:
> On Thursday 28 January 2010 03:39:18 pm Arno Rehn wrote:
> > On Wednesday 27 January 2010 23:58:14 Richard Dale wrote:
> > > On Wednesday 27 January 2010 09:44:43 pm Richard Dale wrote:
> > > > On Wednesday 27 January 2010 01:42:46 pm Stefano Crocco wrote:
> > > > > With the latest revision of smoke and korundum from the 4.4 branch,
> > > > > calling KParts::MainWindow#action_collection causes a crash (both
> > > > > with ruby 1.8 and 1.9). You can obtain it by running the following
> > > > > code
> > > > > 
> > > > > require 'korundum4'
> > > > > 
> > > > > data = KDE::AboutData.new "test", "", KDE::ki18n("Test"), "0.1",
> > > > > 
> > > > >     KDE.ki18n('A test application')
> > > > > 
> > > > > KDE::CmdLineArgs.init ARGV, data
> > > > > a = KDE::Application.new
> > > > > w = KParts::MainWindow.new nil, 0
> > > > > w.action_collection
> > > > > 
> > > > > The same code runs perfectly with an older revision of smoke and
> > > > > korundum (with smoke still generated using kalyptus). With the
> > > > > recent one,
> > > > 
> > > > > instead, I get the following backtrace:
> > > > I think this is a bug in the new Smoke library generator, rather than
> > > > 
> > > >  QtRuby. KParts::MainWindow has a complicated inheritance heirarchy,
> > > > 
> > > > and it might be to do with that rather than a problem with the
> > > > 
> > > >  KActionCollection class.
> > > 
> > > The libsmokekde library generated by kalyptus had these casts for
> > > KParts::MainWindow, including one for KXMLGUIClient with the
> > > 
> > > actionCollection() method in it:
> > >       case 266: //KParts::MainWindow
> > >       
> > >         switch(to) {
> > >         
> > >             case 413: return
> > > 
> > > (void*)(KXmlGuiWindow*)(KParts::MainWindow*)xptr; case 222: return
> > > (void*)(KMainWindow*)(KParts::MainWindow*)xptr; case 492: return
> > > (void*)(QMainWindow*)(KParts::MainWindow*)xptr; case 576: return
> > > (void*)(QWidget*)(KParts::MainWindow*)xptr; case 503: return
> > > (void*)(QObject*)(KParts::MainWindow*)xptr; case 504: return
> > > (void*)(QPaintDevice*)(KParts::MainWindow*)xptr; case 409: return
> > > (void*)(KXMLGUIBuilder*)
> > > (KParts::MainWindow*)xptr;
> > > 
> > >             case 410: return
> > > 
> > > (void*)(KXMLGUIClient*)(KParts::MainWindow*)xptr; case 271: return
> > > (void*)(KParts::PartBase*)
> > > (KParts::MainWindow*)xptr;
> > > 
> > >             case 266: return (void*)(KParts::MainWindow*)
> > > 
> > > (KParts::MainWindow*)xptr;
> > > 
> > >           default: return xptr;
> > >         
> > >         }
> > > 
> > > Whereas the new generator in the KDE 4.4 branch has these casts in the
> > > 
> > > libsmokekparts library:
> > >     case 24:   //KParts::MainWindow
> > >     
> > >       switch(to) {
> > >       
> > >         case 29: return
> > > 
> > > (void*)(KParts::PartBase*)(KParts::MainWindow*)xptr; case 24: return
> > > (void*)(KParts::MainWindow*)xptr;
> > > 
> > >         default: return xptr;
> > >       
> > >       }
> > > 
> > > It looks as though it is missing the casts for external classes.
> > 
> > Yes. If we included every possible upcast for every external class, we
> > 
> >  would end up with a huge classes table, depending on the module. The
> >  correct way to cast external classes is to look up the corresponding
> >  smoke module and do the cast there.
> 
> Oh, I just commited a change to do that. So we would need to see how much
> code got generated before and after.
> 
> But how can I cast from a KParts::MainWindow to a KXMLGUIClient - there
> isn't going to be a cast in the kdecore module to do that as it doesn't
> know about KParts.
Ah yes. I was thinking of something different. But you're right, this is (was) 
actually a bug.

I was thinking of external classes having upcasts within their module. 
KActionCollection for example is an external class in the kparts smoke module 
and doesn't have an upcast to QObject (which is correct).

-- 
Arno Rehn
arno at arnorehn.de