By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 1100 - Kopete in R14 crashing before starting
Summary: Kopete in R14 crashing before starting
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: tdenetwork (show other bugs)
Version: R14.0.0 [Trinity]
Hardware: All Linux
: P5 blocker
Assignee: Timothy Pearson
URL:
Depends on:
Blocks:
 
Reported: 2012-07-12 10:33 CDT by Kris
Modified: 2012-11-10 12:04 CST (History)
4 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Kris 2012-07-12 10:33:51 CDT 
I'm running the latest nightlies as of July 12, 2012.

Every single time I try to launch Kopete, it crashes. It will not load at all.

Since the bug tracker won't let me attach the backtrace, here is a direct copy-and-paste of the backtrace:
--------------------------------------------------------------------------

[Thread debugging using libthread_db enabled]
[KCrash handler]
#5  0x00007f10290ab7e0 in TQMetaProperty::keyToValue(char const*) const ()
   from /usr/lib/libtqt-mt.so.3
#6  0x00007f1026fb1af1 in KopetePrefs::load() ()
   from /opt/trinity/lib/libkopete.so.1
#7  0x00007f1026fb3c27 in KopetePrefs::prefs() ()
   from /opt/trinity/lib/libkopete.so.1
#8  0x000000000044ca1c in ?? ()
#9  0x000000000043356b in ?? ()
#10 0x000000000044297c in ?? ()
#11 0x0000000000442e09 in ?? ()
#12 0x000000000044338b in ?? ()
#13 0x00007f102487ac8d in __libc_start_main () from /lib/libc.so.6
#14 0x0000000000430e09 in ?? ()
#15 0x00007fffc0d3cb08 in ?? ()
#16 0x000000000000001c in ?? ()
#17 0x0000000000000007 in ?? ()
#18 0x00007fffc0d3d9c0 in ?? ()
#19 0x00007fffc0d3d9c7 in ?? ()
#20 0x00007fffc0d3d9d0 in ?? ()
#21 0x00007fffc0d3d9d7 in ?? ()
#22 0x00007fffc0d3d9dd in ?? ()
#23 0x00007fffc0d3d9e4 in ?? ()
#24 0x00007fffc0d3d9ee in ?? ()
#25 0x0000000000000000 in ?? ()
Comment 1 Kris 2012-07-12 10:37:13 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.
Comment 2 Darrell 2012-10-19 15:29:37 CDT 
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
Comment 3 Darrell 2012-10-19 15:51:52 CDT 
Note, in 3.5.13 kopete does not crash upon opening. I'm tagging this bug report as a regression.
Comment 4 Darrell 2012-10-19 17:14:07 CDT 
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
Comment 5 Timothy Pearson 2012-10-19 18:12:19 CDT 
(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
Comment 6 Darrell 2012-10-19 18:51:46 CDT 
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.
Comment 7 Timothy Pearson 2012-10-19 18:55:20 CDT 
There won't be a problem in TQt.  In all likelihood Kopete is using a TQt3 meta object incorrectly, hence the crash.
Comment 8 Darrell 2012-10-19 19:03:14 CDT 
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?
Comment 9 Timothy Pearson 2012-10-19 19:32:59 CDT 
(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
Comment 10 Darrell 2012-10-20 09:56:04 CDT 
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.
Comment 11 Darrell 2012-10-20 10:19:19 CDT 
Two people confirm the problem is not in 3.5.13.1.
Comment 12 Kris 2012-10-20 17:47:57 CDT 
(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).
Comment 13 Timothy Pearson 2012-10-20 19:16:18 CDT 
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.
Comment 14 Darrell 2012-10-20 19:29:09 CDT 
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.
Comment 15 Darrell 2012-10-31 14:53:52 CDT 
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.
Comment 16 Darrell 2012-11-02 11:28:01 CDT 
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.
Comment 17 Kris 2012-11-08 09:30:10 CST 
(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.
Comment 18 Darrell 2012-11-10 12:04:54 CST 
As the problem did not affect 3.5.13, I am closing the bug report as resolved.

Thanks for helping everybody!