The new rkward package crashes on both Feodora 9 and 10. How to reproduce: 1 Start rkward 2 Choose «Start with an empty workspace» 3 Press «Script File» 4 Start typing Within the first 10 or 15 characters the application crashes, both under Gnome and KDE. Output: bash-3.2$ rkward R version 2.8.1 (2008-12-22) Copyright (C) 2008 The R Foundation for Statistical Computing ISBN 3-900051-07-0 R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. Natural language support but running in an English locale R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. Calling appendChild() on a null node does nothing. Calling appendChild() on a null node does nothing. Calling appendChild() on a null node does nothing. rkward(4184)/Kate KateLayoutCache::relayoutLines: start 2147483647 before end 0 Calling appendChild() on a null node does nothing. rkward(4184)/kparts KParts::PartManager::addPart: Part ' "" ' has a widget "" with a focus policy of NoFocus. It should have at least a ClickFocus policy, for part activation to work well. QThreadStorage: Thread 0x87d3d10 exited after QThreadStorage 2147483641 destroyed QThreadStorage: Thread 0x87d3d10 exited after QThreadStorage 2147483643 destroyed I downloaded the source from sourceforge and built locally on Fedora 10, the result runs perfectly. Evidently something is wrong with the Fedora package.
Hi, Thanks for the report. I have been trying to reproduce the bug, I open rkward, press <Script File> and typed: > tr<-matrix(nrow = 5, ncol = 6) > ttr <- t(tr) > ttr2 <- ttr^2 > print('I did not crashed yet') > cat('Another way to print something') It did not crash. However I do have a quite verbose output. Tested under Gnome. While you built it from sourceforge, did you create your own spec file ? If not, did you change anything on the spec file ?
@Karl, I saw you have added yourself as CC, do you face the same problem ?
Yes, I have the same problem (but I’m using a computer on the same computer system as the reporter). I have also tried deleting the ~/.kde/share/config/rkwardrc file, but that didn’t help. Also, when Rkward crashes, this is the last line shown (not mentioned in the above report): rkward: symbol lookup error: rkward: undefined symbol: _ZNK7QString11lastIndexOfER7QRegExpi
Looks like other people are having problems with Rkward on Fedora 10 too: http://sourceforge.net/mailarchive/forum.php?thread_name=34f2770f0904100411u34bef5dfg83e941f848e3584%40mail.gmail.com&forum_name=rkward-users
When building from source I simply performed the three steps in the INSTALL file in the tarball from sourceforge; cmake, make, sudo make install. As said, it crashed during typing the first line - though I'm no statistician so I was just typing random characters. -BT
ok I managed to reproduce the bug so well that I now have it crashing for any key I press ^_^ I opened rkward, press lot of *random* keys until it crashes and I reproduced it a number of time, it might have a link with the "Alt Gr" and the key on its right. I will try to find and correct the bug now :) @Bjorn, so you actually built it from source, you did not recreate a RPM did you ?
(In reply to comment #6) > ok I managed to reproduce the bug so well that I now have it crashing for any > key I press ^_^ I'm so happy for you. :) > I opened rkward, press lot of *random* keys until it crashes and I reproduced > it a number of time, it might have a link with the "Alt Gr" and the key on its > right. Umm. I'll check whether that makes any difference when I get to work tomorrow, I normally run with deadkeys enabled but I've spent quite a bit of time today in the loving embrace of Matlab which doesn't work properly with deadkeys enabled... > I will try to find and correct the bug now :) Brilliant, thank you! > @Bjorn, so you actually built it from source, you did not recreate a RPM did > you ? That's correct. On a 32bit Fedora 10 patched 100% up Tuesday around noon. -BT
Enabling or disabling deadkeys make no difference. -BT
Are you guys i386 or x86_64 ?
I have testet both, no difference. -BT
I am wondering if it is not linked to something else: https://bugzilla.redhat.com/show_bug.cgi?id=496050
But Rkward doesn’t depend on Python, does it? The symbol lookup error _ZNK7QString11lastIndexOfER7QRegExpi rather seems to be suggest some problems related to regexp in Qt. (A Google search of this string returns a commit log for Qt on Debian, BTW.)
If this problem is linked to something else, why does a clean build from source work perfectly? -BT
I am in contact with upstream to try to fix this. On his question I found some weird things: > 1b. Running > strings /path/to/rkward.bin | grep "lastIndexOf" > should contain that precise string as well. > @pingouRed ~]$ strings /usr/bin/rkward.bin | grep "lastIndexOf" _ZNK7QString11lastIndexOfE5QChariN2Qt15CaseSensitivityE _ZNK7QString11lastIndexOfERKS_iN2Qt15CaseSensitivityE _ZNK7QString11lastIndexOfER7QRegExpi ----- From the computer on which rkward crashes @pingouLab ~]$ strings /usr/bin/rkward.bin | grep "lastIndexOf" _ZNK7QString11lastIndexOfE5QChariN2Qt15CaseSensitivityE _ZNK7QString11lastIndexOfERKS_iN2Qt15CaseSensitivityE _ZNK7QString11lastIndexOfERK7QRegExpi ----- From the computer on which rkward does *not* crash (As you can see the last string is different) Could you try ? I wonder if I don't miss a BuildRequires on the spec...
Here (where Rkward crashes) I get $ strings /usr/bin/rkward.bin | grep "lastIndexOf" _ZNK7QString11lastIndexOfE5QChariN2Qt15CaseSensitivityE _ZNK7QString11lastIndexOfERKS_iN2Qt15CaseSensitivityE _ZNK7QString11lastIndexOfER7QRegExpi
FWIW, you can run these strings through "c++filt" (from binutils) to demangle them back to C++ identifiers. So, re comment #14: $ c++filt _ZNK7QString11lastIndexOfE5QChariN2Qt15CaseSensitivityE _ZNK7QString11lastIndexOfERKS_iN2Qt15CaseSensitivityE _ZNK7QString11lastIndexOfER7QRegExpi QString::lastIndexOf(QChar, int, Qt::CaseSensitivity) const QString::lastIndexOf(QString const&, int, Qt::CaseSensitivity) const QString::lastIndexOf(QRegExp&, int) const _ZNK7QString11lastIndexOfE5QChariN2Qt15CaseSensitivityE _ZNK7QString11lastIndexOfERKS_iN2Qt15CaseSensitivityE _ZNK7QString11lastIndexOfERK7QRegExpi QString::lastIndexOf(QChar, int, Qt::CaseSensitivity) const QString::lastIndexOf(QString const&, int, Qt::CaseSensitivity) const QString::lastIndexOf(QRegExp const&, int) const Note that the 3rd one changes its 1st param from "QRegExp&" to "QRegExp const&". Hope this is helpful.
rkward-0.5.0c-1 was built against Qt 4.5. It got pushed to stable on April 7, which was completely broken because Qt 4.5 was still in testing until yesterday. The Qt 4.5 announcement clearly stated that Qt-using packages MUST NOT be pushed to stable before Qt 4.5, unless they were specifically built against Qt 4.4 with rel-eng cooperation! In any case, Qt 4.5 is stable now, so this should be fixed, make sure you update your qt package.
It works for me with qt-4.5 indeed btw I just did a rebuild for the new R, currently rkward should not work with R-2.9.0, feel free to push it in bodhi. Thanks Kevin (I'll wait for more feed back before closing this bug)
Well, you submitted the update for the new R, so you'll have to queue it for stable yourself if you want it to go directly to stable. From my side as Qt comaintainer, there are no objections, Qt 4.5 is stable now (and the existing stable update was already built against 4.5 anyway).
The new rkward is on stable, it has been built against the correction version of Qt, so every thing should work fine. I therefore close this bug as CURRENTRELEASE, feel free to reopen it and to open another one if you face any problem :) Thanks for the report