hi,

i've compiled ktorrent with --prefix=$HOME/apps/ktorrent --without-arts --enable-strict
and put

Code: Select all

KDEDIRS=$HOME/apps/ktorrent:$KDEDIRS
export KDEDIRS


into my ~/.profile

ktorrent segfaults when i open it through the menu or kde's "run command" dialog, but runs fine if i first open a xterm and run ktorrent from within. any idea what could cause such an behaviour?

EDIT: PATH = $HOME/bin:$PATH ;
bin/ktorrent: symbolic link to `../apps/ktorrent/bin/ktorrent'

Can you give us a backtrace ?

This is certainly strange.

i'm recompiling it just now with

Code: Select all

./configure --prefix=$HOME/apps/ktorrent --without-arts --enable-strict --enable-debug=full  --enable-profile

i just got a thougt and ran '~/bin/ktorrent' instead of just 'ktorrent': works fine. do you know, whether kde executes .profile on login? (apparently PATH is not set )

i have also another ktorrent package installed under /opt/kde, maybe they are interfering with each other?

EDIT: now it's really ... interesting. 'ktorrent --debug' runs fine!

hmm, can't make any sense out of this. actually specifying any(!) command-line option helps to bring up the program normally.
so attaching a debugger is of no use, since the --nofork option actually is a fix.
I can't seem to get a backtrace either.

This backtrace appears to be of no use.
This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash.

Using host libthread_db library "/lib/tls/libthread_db.so.1".
0xb67ffefb in ?? ()
#0 0xb67ffefb in ?? ()
#1 0xb67ffd1d in ?? ()
#2 0xbf82d134 in ?? ()
#3 0xbf82d134 in ?? ()
#4 0x00000000 in ?? ()

Maybe compiler bugs? gcc -v

Configured with: ../gcc-3.4.6/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose --target=i486-slackware-linux --host=i486-slackware-linux
Thread model: posix
gcc version 3.4.6

Can you check the desktop file of the K-Menu entry. Not quite sure where they are stored, but probably under ~/.kde

This is very strange.

The backtrace just indicates that it crashes somewhere in non-KT code (KDE code maybe). However I would at least expect the main function to show up in the backtrace.

[Desktop Entry]
Encoding=UTF-8
Name=KTorrent
GenericName=BitTorrent Client
Exec=ktorrent %i %m -caption "%c" %u
Icon=ktorrent
Type=Application
DocPath=ktorrent/index.html
MimeType=application/x-bittorrent;application/x-torrent
X-DCOP-ServiceType=Unique
Comment=A BitTorrent program for KDE
Terminal=false
Categories=Qt;KDE;Network;FileTransfer;

however, i normally use the 'run command' dialog.

i also noticed that it start ups happily, if it's minimized to the tray
(and crashes when restoring the window)


i'm using qt3.3.7 here. were there relevant changes?
http://www.trolltech.com/developer/notes/changes/changes-3.3.8

I'm on Qt 3.3.6, though I never use the KDE menu to start ktorrent.

Does the same problem happen when you start other applications using the run command dialog ?

no

So we can rule out the run command dialog crashing.

yes, it has to be (?) code that is called when restoring/painting the window..

and that is circumvented/executed in another context when ktorrent gets called with options.

It's gotta to be a Qt bug.

I'm still on KDE 3.5.5, gonna update to 3.5.6 soon, a new version of Qt will probably be included with the update. Hopefully I can then reproduce the bug.