Bug 247746 - kpat does not start when kdebase not installed
kpat does not start when kdebase not installed
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kdegames (Show other bugs)
7
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Rex Dieter
desktop-bugs@redhat.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-11 04:29 EDT by Piergiorgio Sartor
Modified: 2007-11-30 17:12 EST (History)
3 users (show)

See Also:
Fixed In Version: 3.5.8-4.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-20 12:52:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace of kpat (15.76 KB, application/octet-stream)
2007-07-30 15:41 EDT, Piergiorgio Sartor
no flags Details
patch candidate 1 (892 bytes, patch)
2007-11-19 09:33 EST, Rex Dieter
no flags Details | Diff

  None (edit)
Description Piergiorgio Sartor 2007-07-11 04:29:10 EDT
Description of problem:
The "kpat" (patience) game of kdegames package does not start in the x86_64
version. Neither from menu nor from command line.
It works fine (on different, i386 only, PC) in i386 version.

Version-Release number of selected component (if applicable):
kdegames-3.5.7-1.fc7

How reproducible:
Always

Steps to Reproduce:
1.
From a terminal type "kpat"
  
Actual results:
It ouputs:
...
ASSERT: "i <= nodes" in /usr/lib64/qt-3.3/include/qvaluelist.h (373)

and it stays there, i.e. no real "crash", just waiting.

Expected results:
The game should start.

Additional info:
It seems somehow locked somewhere with no CPU load at all.
It might be a qt problem, even if only this software seems affected.
Comment 1 Hans de Goede 2007-07-16 09:36:22 EDT
Works fine for me on a fully up2date rawhide system

Comment 2 Piergiorgio Sartor 2007-07-27 14:54:50 EDT
Actually, checking again, kpat does not start and the CPU goes to 100%, so it
seems it is looping or something.
Since this behavior I noticed after some KDE updates, namely kdelibs, it could
be that there was a change due to this, but I'm not sure.
Any idea on if or when the rawhide kdegames (or whatever is related to this
package) will go to F7?

Thanks.
Comment 3 Hans de Goede 2007-07-28 02:15:24 EDT
IT would be good to first find out what exactly is causing the problem. Can you
try upgrading qt to the qt rpm found in rawhide, and then try again. Next update
kdelibs to the rpm found in rawhide and try again and last kdegames?

Thanks!

Comment 4 Piergiorgio Sartor 2007-07-28 15:57:45 EDT
I have a couple of questions:

1) Is there a simpler solution than upgrading to rawhide?
2) Am I the only one having this issue on a x86_64 machine or it is reproducible?

Because I would like to avoid to have to upgrade a bunch of dependencies to
check something that might be solved with, for example, gdb...

Any second option?

Thanks again!

Comment 5 Hans de Goede 2007-07-28 16:32:27 EDT
(In reply to comment #4)
> I have a couple of questions:
> 
> 1) Is there a simpler solution than upgrading to rawhide?
To find what package is causing the problem, no not really

> 2) Am I the only one having this issue on a x86_64 machine or it is reproducible?
> 

As said I tried to reproduce this and I failed, but thats with rawhide (although
at that time a pretty old rawhide which was still close to F-7).

> Because I would like to avoid to have to upgrade a bunch of dependencies to
> check something that might be solved with, for example, gdb...
> 

Have you tried? I would for example expect rawhide's QT to drop into F-7 without
any troubles. If it turns out to indeed by a dependency mess, then you can
always still decide not to do it.

> Any second option?
You could strace the process when it hangs, maybe that will help.
Comment 6 Piergiorgio Sartor 2007-07-30 04:13:57 EDT
Actually I checked.
The qt library of "development" is qt-3.3.8-4.fc7, so it is exactly the same as
F7. The games is kdegames-3.5.7-1.fc8, which, apart fc8, has the same version
and update number as per F7. The libs is kdelibs-3.5.7-13.fc8, in F7 it is
kdelibs-3.5.7-9.fc7.
So, it seems to me that only the kdelibs might have some change.
What about the other? Is there any difference between kdegames fc8 and fc7?
Can't you try to reproduce this with a clean f7 install? I'm quite puzzled on
how can be F7 supported using rawhide.

I quickly tried strace, I does not seem to me to give more info, eventually I'll
re-try and post here an attachment.

Thanks.

Comment 7 Piergiorgio Sartor 2007-07-30 15:38:06 EDT
OK, I updated kdelibs (including kde-filesystem, which is required) and
kdegames,  both from "development", qt is the same and it did not upgraded.
The problem is still there, kpat hangs with the assert using 100% of the CPU.
I'll attach the strace of it.
Comment 8 Piergiorgio Sartor 2007-07-30 15:41:18 EDT
Created attachment 160268 [details]
strace of kpat

Output of strace -x kpat 2>kpat.log, compressed with gzip.
This was done after the upgrade of kdelibs and kdegames.
Comment 9 Hans de Goede 2007-08-02 18:37:10 EDT
(In reply to comment #6)
> Can't you try to reproduce this with a clean f7 install? I'm quite puzzled on
> how can be F7 supported using rawhide.
> 

I'm sure that Ngo, if he ever finds the time will try to reproduce this on F-7,
notice however that I'm not the maintainer of this package, I'm merely a Fedora
contributer who is trying to help. And I happen to only have rawhide on my system.

Can you try installing kdegames-debuginfo and kdelibs-debuginfo from rawhide,
(with versions matching your installed versions). and then from a terminal run
gdb `which kpat`
and then inside gdb type:
run
Hopefully gdb will catch the qt abort (which should stop the program, not cause
it to hang) , when this happens type:
bt

And then I would like to know the output.

Thanks!

> I quickly tried strace, I does not seem to me to give more info, eventually I'll
> re-try and post here an attachment.
> 
> Thanks.
> 
> 

Comment 10 Piergiorgio Sartor 2007-08-03 15:53:48 EDT
(In reply to comment #9)
> I'm sure that Ngo, if he ever finds the time will try to reproduce this on F-7,
> notice however that I'm not the maintainer of this package, I'm merely a Fedora
> contributer who is trying to help. And I happen to only have rawhide on my system.

Sorry, I understood you were somehow "officially" involved in the support.

> Can you try installing kdegames-debuginfo and kdelibs-debuginfo from rawhide,
> (with versions matching your installed versions). and then from a terminal run
> gdb `which kpat`
> and then inside gdb type:
> run
> Hopefully gdb will catch the qt abort (which should stop the program, not cause
> it to hang) , when this happens type:
> bt
> 
> And then I would like to know the output.

OK, I installed the debuginfo packages, also for qt (after a first test).

gdb does not really seems to be more verbose, it hangs as well.
The following is the output:

Using host libthread_db library "/lib64/libthread_db.so.1".
(gdb) run
Starting program: /usr/bin/kpat 
[Thread debugging using libthread_db enabled]
[New Thread 46912496285968 (LWP 4436)]
[Detaching after fork from child process 4439. (Try `set detach-on-fork off'.)]
kbuildsycoca running...
DCOP Cleaning up dead connections.
ASSERT: "i <= nodes" in /usr/lib64/qt-3.3/include/qvaluelist.h (373)

at this point the CPU goes 100% and the input is not active, so I typed ctrl-c,
to break, and I got the gdb prompt after the following:

Program received signal SIGINT, Interrupt.
[Switching to Thread 46912496285968 (LWP 4436)]
QValueListPrivate<QString>::at (this=0x872f00, i=18446744073709551615)
    at /usr/lib64/qt-3.3/include/qvaluelist.h:375
375     /usr/lib64/qt-3.3/include/qvaluelist.h: No such file or directory.
        in /usr/lib64/qt-3.3/include/qvaluelist.h

note the "No such file or directory.", which seems to indicate something is
missing. Then I back traced:

(gdb) bt
#0  QValueListPrivate<QString>::at (this=0x872f00, i=18446744073709551615)
    at /usr/lib64/qt-3.3/include/qvaluelist.h:375
#1  0x000000000041ef31 in pWidget::changeWallpaper (this=0x80b650)
    at /usr/lib64/qt-3.3/include/qvaluelist.h:536
#2  0x0000000000422536 in pWidget (this=0x80b650) at pwidget.cpp:130
#3  0x0000000000411ebb in main (argc=<value optimized out>, 
    argv=<value optimized out>) at main.cpp:66
#4  0x0000003e7541dab4 in __libc_start_main () from /lib64/libc.so.6
#5  0x0000000000411b29 in _start ()
(gdb) 

I tried also with "set detach-on-fork off" before "run", but this was not going
anywhere.

Installing qt-devel (due to the error about the missing file), I got, after the
ctrl-c:

Program received signal SIGINT, Interrupt.
[Switching to Thread 46912496285968 (LWP 4629)]
QValueListPrivate<QString>::at (this=0x872770, i=18446744073709551615)
    at /usr/lib64/qt-3.3/include/qvaluelist.h:375
375         for( size_type x = 0; x < i; ++x )

the bt is then the same.

The above loop seems to belong to:

template <class T>
Q_INLINE_TEMPLATES Q_TYPENAME QValueListPrivate<T>::NodePtr
QValueListPrivate<T>::at( size_type i ) const
{
    Q_ASSERT( i <= nodes );
    NodePtr p = node->next;
    for( size_type x = 0; x < i; ++x )
        p = p->next;
    return p;
}

The assert seems to be this one.
Any clue on what this means?

Thanks again.

Comment 11 Piergiorgio Sartor 2007-08-03 16:06:43 EDT
Actually, I forgot to mention that, in gdb, "print i" returns the funny value
(as per gdb printout) 18446744073709551615, while "print nodes" returns 10.
The loop seems to run, since stepping does work (after the ctrl-c) and "x" is
incremented... Eventually 18446744073709551615 times...
The impression is that "i" is not properly initialized, but I do not know where
this comes from.
Comment 12 Hans de Goede 2007-08-05 16:43:35 EDT
Okay,

I know whats going on now, the problem is that kpat by default wants to use
/usr/share/wallpapers/No-Ones-Laughing-3.jpg as background, but that is in
kdebase, so installing kdebase should fix this for you.

That is just a workaround though, and not a proper fix IMHO. The problem is
caused by line 128 of kpat/pwidget.cpp:
wallpapers->setCurrentItem(list2.findIndex("No-Ones-Laughing-3"));

Since there is no No-Ones-Laughing-3 wallpaper when kdebase isn't installed,
this call causes the currentItem of wallpapers to be set to -1, when this later
gets used in setWallPaper, it triggers the assert (which strange enough doesn;t
raise abort) and then it causes the endless loop you see.

A proper fix for this would be to replace line 128 of kpat/pwidget.cpp with:
int i = list2.findIndex("No-Ones-Laughing-3");
if (i == -1)
    i = list2.findIndex("green");
wallpapers->setCurrentItem(i);

The second findIndex should always succeed as the green wallpaper is part of
kpat itself.


Than,

I'm not sure what todo about this for F-7 (don't know if its worth an update),
but this is something that should be checked for F-8, the kpat from kdegames4
might still have the same issue.
Comment 13 Piergiorgio Sartor 2007-08-06 16:47:32 EDT
Now it is clear.
In FC6 kdebase was required by kdegames. The i386 machine I had was upgraded
from FC6 to F7 thus bringing kdebase together in the process.
The x86_64 machine is a clean install of F7 and not having kdegames anymore the
required kdebase, kpat was not working, while it was in the i386 one.
I think the main problem here was the obfuscated result of the missing file,
since something like:

File not found: /usr/share/wallpapers/No-Ones-Laughing-3.jpg

would have clarified the problem much earlier.

I see the following possible solutions, to the original bug:

1) add kdebase as required in the spec file of kdegames
2) apply your patch
3) add /usr/share/wallpapers/No-Ones-Laughing-3.jpg to kdegames

Maybe the most sensible is the 2), since it will avoid the useless installation
of kdebase and will avoid rpm problems with duplicated files.

What about the error message? Why the assert was not aborting?
Comment 14 Rex Dieter 2007-11-19 09:00:16 EST
Eww, I'll incorporate the patch.  Thanks for the insightful detective-work.
Comment 15 Rex Dieter 2007-11-19 09:33:11 EST
Created attachment 263501 [details]
patch candidate 1

Use green.png as default background instead of No-Ones-Laughing-3.jpg, which
may or may not be present.
Comment 17 Fedora Update System 2007-11-20 12:52:24 EST
kdegames-3.5.8-4.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Fedora Update System 2007-11-20 13:02:07 EST
kdegames-3.5.8-4.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.