| Summary: | Kopete in R14 crashing before starting | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Kris <krisgamrat> |
| Component: | tdenetwork | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | bugwatch, darrella, kb9vqf, krisgamrat |
| Priority: | P5 | ||
| Version: | R14.0.0 [Trinity] | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
|
Description
Kris
2012-07-12 10:33:51 CDT
Note: I am running on Debian Squeeze. Unfortunately, I am unable to test on another distro due to lack of storage, so someone may need to test this on another distro. Confirmed Oct. 19 on Slackware 13.1 32-bit. My package includes all patches from bug report 1040. Backtrace:
[Thread debugging using libthread_db enabled]
[KCrash handler]
#5 TQMetaProperty::keyToValue (this=0x0, key=0x82081b8 "Default")
at kernel/qmetaobject.cpp:908
#6 0xb76a95bf in KopetePrefs::load (this=0x8207ae0)
at /dev/shm/tdenetwork/kopete/libkopete/kopeteprefs.cpp:133
#7 0xb76a9dca in KopetePrefs (this=0x8207ae0)
at /dev/shm/tdenetwork/kopete/libkopete/kopeteprefs.cpp:43
#8 0xb76a9fa1 in KopetePrefs::prefs ()
at /dev/shm/tdenetwork/kopete/libkopete/kopeteprefs.cpp:36
#9 0x080aa2b1 in KopeteContactListView (this=0x8202048, parent=0x81eca00,
name=0x0)
at /dev/shm/tdenetwork/kopete/kopete/contactlist/kopetecontactlistview.cpp:399
#10 0x080971a1 in KopeteWindow::initView (this=0x81eca00)
at /dev/shm/tdenetwork/kopete/kopete/kopetewindow.cpp:201
#11 0x0809c0cb in KopeteWindow (this=0x81eca00, parent=0x0,
name=0x80fdb54 "mainWindow", __in_chrg=<value optimized out>,
__vtt_parm=<value optimized out>)
at /dev/shm/tdenetwork/kopete/kopete/kopetewindow.cpp:153
#12 0x0808b184 in KopeteApplication (this=0xbfe95ba8)
at /dev/shm/tdenetwork/kopete/kopete/kopeteapplication.cpp:58
#13 0x0808ab36 in main (argc=7, argv=0xbfe95dd4)
at /dev/shm/tdenetwork/kopete/kopete/main.cpp:103
Note, in 3.5.13 kopete does not crash upon opening. I'm tagging this bug report as a regression. Tim, I'm not sure, but I think (at least part of) the problem is TQMetaEnum is not translated in tqtinterface. Is something like this needed? diff -urN tqtinterface/qtinterface/tqt.h.cmake tqtinterface.new/qtinterface/tqt.h.cmake --- tqtinterface/qtinterface/tqt.h.cmake 2012-10-12 11:40:24.000000000 -0500 +++ tqtinterface.new/qtinterface/tqt.h.cmake 2012-10-19 16:45:37.000000000 -0500 @@ -789,6 +789,7 @@ #define TQMenuData QMenuData #define TQMessageBox QMessageBox #define TQMetaData QMetaData +#define TQMetaEnum QMetaEnum #define TQMetaProperty QMetaProperty #define TQMetaObject QMetaObject #define TQMetaObjectCleanUp QMetaObjectCleanUp (In reply to comment #4) > Tim, > > I'm not sure, but I think (at least part of) the problem is TQMetaEnum is not > translated in tqtinterface. Is something like this needed? > > diff -urN tqtinterface/qtinterface/tqt.h.cmake > tqtinterface.new/qtinterface/tqt.h.cmake > --- tqtinterface/qtinterface/tqt.h.cmake 2012-10-12 11:40:24.000000000 -0500 > +++ tqtinterface.new/qtinterface/tqt.h.cmake 2012-10-19 16:45:37.000000000 > -0500 > @@ -789,6 +789,7 @@ > #define TQMenuData QMenuData > #define TQMessageBox QMessageBox > #define TQMetaData QMetaData > +#define TQMetaEnum QMetaEnum > #define TQMetaProperty QMetaProperty > #define TQMetaObject QMetaObject > #define TQMetaObjectCleanUp QMetaObjectCleanUp Possibly. What source file is using TQMetaEnum in kopete? Tim There is no usage of TQMetaEnum in kopete. I'm trying to follow my backtrace (Comment 2). The occurrence of TQMetaEnum occurs in tqt3/src/kernel/qmetaobject.cpp:908. I can't find any mention of TQMetaEnum in tqt.h, hence my idea of the patch. I'm guessing that patch is still needed, but after rebuilding tqtinterface and tdenetwork with the patch, kopete still crashes immediately upon opening. I did not rebuild tqt3. There won't be a problem in TQt. In all likelihood Kopete is using a TQt3 meta object incorrectly, hence the crash. Okay, but the bug does not exist in 3.5.13. Does that make sense? And is the tqt.h patch still needed to provide the TQMetaEnum->QMetaEnum translation? (In reply to comment #8) > Okay, but the bug does not exist in 3.5.13. Does that make sense? Possibly; I am just saying that the issue will likely be in kopete itself, not the translation layer or TQt3. ;-) > And is the tqt.h patch still needed to provide the TQMetaEnum->QMetaEnum > translation? While it is a good idea, it is not mandatory. Failing to provide that #define would simply result in a compilation error, not a runtime crash. Tim I installed an R14 package set from about March 20-25. kopete failed to start. Although inconclusive, that kopete starts in 3.5.13 provides a four month window when the bug likely was introduced. Ignoring kde*->tde* renaming, the code in tdenetwork/kopete is practically identical to 3.5.13. That seems to lean toward something fundamental as the cause. Perhaps somebody with 3.5.13.1 installed will run some quick tests. If kopete fails in 3.5.13.1 then we narrow the problem to one of the backported patches, which hopefully is derived from that four month window. Two people confirm the problem is not in 3.5.13.1. (In reply to comment #11) > Two people confirm the problem is not in 3.5.13.1. Make that three people. I can confirm that Kopete was working in both 3.5.13 and 3.5.13.1. I was using the latter just before upgrading to the nightlies for R14, and I did not see any crashes before R14 (except when maxing out my CPU, but that affected everything, not just TDE apps). I have isolated this to a problem in TQt3; specifically the TQ_PROPERTY macro in header files is not being recognised by moc. I am working on a fix now. Before I retired last night I had a hunch this was starting to smell similar to the kio_iso problem, which was caused by renaming moc to tqmoc. So today I grabbed a list of the commits between 3.5.13 and March 25, eliminated the 3.5.13.1 patches and the baloney commits like branding. All that remained in the list was a bunch of tq related patches. I did not get far after that, but I'm curious to know the original cause. I pushed the patch discussed below in the comments in commit 1730af22. As mentioned in comments 8 and 9, although not mandatory, the patch is not harmful and could be helpful. Using GIT sources from 2012-10-30, kopete now starts without incident on my systems, Slackware 13.1 32-bit and Slackware 14.0 64-bit. I will close this bug report as soon as one additional person confirms. Thank you everybody for helping. (In reply to comment #16) > Using GIT sources from 2012-10-30, kopete now starts without incident on my > systems, Slackware 13.1 32-bit and Slackware 14.0 64-bit. I will close this bug > report as soon as one additional person confirms. > > Thank you everybody for helping. Confirmed fixed on Debian Squeeze 32bit. No 64bit system to test on, but I doubt that'll make much difference. As the problem did not affect 3.5.13, I am closing the bug report as resolved. Thanks for helping everybody! |