SEQ Hanging (kinda...)

[BlackShadow]

I just updated to 5.0.0.13, and copied a new eqstr_us.txt over, but now my SEQ hangs all the time right after it has started.

The last thing it does (in the console window) is:
Info: Loaded 9768 message strings from '/usr/local/share/showeq/EQSTR_US.TXT' max Format=45222

After that it doesnt actually hang, but checking with Top I now it hogs all cpu power it can, and it aint allowing me to do anything else. So its almost hanging.

Most times I have enough time to click something or choose something in the drop down windows, but after that it appears completely dead to the user. (Except that it is hogging all the cpu resources)

Also just some quick info:
GCC 3.0.2, glibc 2.2, QT 3.1.1, GDBN 1.8.0, Linux 2.4.2-2

Any ideas of any sort? I know I should upgrade the GCC, but since it did work before this, I havent done this before.

Also I tried alot of other things:
Compiling 5.0.0.12 again - didnt work
Making a clean 5.0.0.12 dir (have old tar archives of all releases) - didnt work
Making a clean 5.0.0.13 dir - didnt work
Cleaned out configfiles and stuff in both /root/.showeq/ and /usr/local/share/showeq/ - didnt help

Any ideas at all?

Thanks in advance...

[BlackShadow]

Here is a list from the console output:


ShowEQ 5.0.0.13, released under the GPL.
SINS 0.5, released under the GPL.
All ShowEQ source code is Copyright (C) 2000-2004 by the respective ShowEQ Developers
ShowEQ comes with NO WARRANTY.

You may redistribute copies of ShowEQ under the terms of
The GNU General Public License.
See: http://www.gnu.org/copyleft/gpl.html for more details...

For updates and information, please visit http://seq.sourceforge.net/
ShowEQ 5.0.0.13, Built from 'main.cpp' on Sep 12 2004 at 00:02:58
CVS: @(#) $Id: main.cpp,v 1.33.6.3 2004/01/16 20:22:10 dohpaz Exp $ $Name: pre_5_0_beta $
Using GCC version: 3.0.2
Using glibc version: 2.2
Using Qt version: 3.1.1
Using headers from linux version: 2.4.7-10
Using EQItemDB: @(#) $Id: itemdb.cpp,v 1.10.6.1 2003/12/07 06:30:43 dohpaz Exp $ $Name: pre_5_0_beta $
Using GDBM: This is GDBM version 1.8.0, as of May 19, 1999.
Running on Linux release 2.4.2-2 for processor i686

Using config file '/root/.showeq/showeq.xml'
Loaded preferences file: /usr/local/share/showeq/seqdef.xml!
Unable to open file: /root/.showeq/showeq.xml!
Info: Listening for first client seen.
Info: Initializing Packet Capture Thread:
Info: Filtering packets on device eth0, searching for EQ client...
Warning: Spells: Failed to open: '/usr/local/share/showeq/spells_us.txt'
Info: GuildMgr: Guildsfile loaded
Debug: ItemDB: Disabled
Info: Loading Filters from '/usr/local/bin'
Info: Loading Zone Filter File: /usr/local/bin
Info: Loading Zone Filter File: /usr/local/bin
Info: Categories Reloaded
Info: No Map found for zone 'unknown'!
Info: Checked for all variants of 'unknown.map', 'unknown.txt', and 'unknown_1.txt'
Info: in directories '/root/.showeq/maps' and '/usr/local/share/showeq/maps'!Info: Loaded 9768 message strings from '/usr/local/share/showeq/EQSTR_US.TXT' maxFormat=45222

[BlueAdept]

first copy the EQSTR_US.TXT from your everquest directory to '/usr/local/share/showeq/ it might be hanging because it is an old version.

If it is still hanging start seq with the --itemdb-disable. That will probably fix the problem your having.

[BlackShadow]

first copy the EQSTR_US.TXT from your everquest directory to '/usr/local/share/showeq/ it might be hanging because it is an old version.

If it is still hanging start seq with the --itemdb-disable. That will probably fix the problem your having.
I have the latest EQSTR_US.TXT in the right place, copied it over as I compiled the new SEQ.

I tried --itemdb-disable, but it didn't help.. it still "hangs" after a few seconds, still hogging all cpu resources, but the "UI" on the window is hung, so if I move another window over this one etc, it doesnt update the SEQ window when I move it off again.

[purple]

Warning: Spells: Failed to open: '/usr/local/share/showeq/spells_us.txt'

That, to me, means you don't have the latest spells_us.txt in the right place though. Maybe put that there too. Probably doesn't make a difference, but my spells_us.txt and eqstr_us.txt are both lowercase.

[BlackShadow]

That, to me, means you don't have the latest spells_us.txt in the right place though. Maybe put that there too. Probably doesn't make a difference, but my spells_us.txt and eqstr_us.txt are both lowercase.
Fixed spells_us.txt , so got rid of that message, but it still "hangs" a few seconds after the SEQ window pops up.

[BlueAdept]

Try getting rid of the strings file. See if that has any improvements. It will give you a warning but might fix your hanging. If that is the case, maybe something got corrupt in the transfer of the file from your windows pc to the linux box.

[BlackShadow]

Try getting rid of the strings file. See if that has any improvements. It will give you a warning but might fix your hanging. If that is the case, maybe something got corrupt in the transfer of the file from your windows pc to the linux box.
I did try without spells_us.txt and eqstr_us.txt , but didn't help.

I don't think this is a SEQ bug really, rather that either some new functions are being used that I dont have (to old QT, gcc or something) , it my linux machine is just suddenly messed up, even thou everything else on it works just fine still.

Any ideas are welcome ofcourse, however wierd they might seem.

[massive-newb]

I'm seeing the same issue. Redhat 9.0. After a few minutes, CPU utilization pegs. Changing the zoom on the map (takes a minute or two for the UI to process the mouse click) acts like a reset and CPU utilization drops but after a few minutes pegs again.

Is there any debugging I can turn on to help you guys figure this one out?

[BlackShadow]

I'm seeing the same issue. Redhat 9.0. After a few minutes, CPU utilization pegs. Changing the zoom on the map (takes a minute or two for the UI to process the mouse click) acts like a reset and CPU utilization drops but after a few minutes pegs again.

Is there any debugging I can turn on to help you guys figure this one out?
Lol, tried the zoom thingy, and it works... It also prevents it from "hanging" if I manage to change the zoom before it hangs.

Not gonna ask how you found that one out, hehe..

Hopefully someone will figure out the bug, thou...

[massive-newb]

Any new ideas on this? While there is a work around, it's still annoying. I'll be glad to post any data that the guru's need to work this one out. Just need to know how to get the data requested.


Thanks.

[purple]

Maybe compile with debug enabled and connect a debugger to it so you can figure out what the heck it is doing to take up so much CPU? Maybe save off an strace of it and see if it is slamming file system calls looking for something it can't find? But really, who knows.

If it's that important, upgrade gdbm, gcc, qt, and glibc maybe? I'm on old stuff, but still newer than what you have. I'm on gdbm 1.8.3, gcc 3.2.1, qt 3.3.1, and glibc 2.3. I got no problems. I'd probably do gdbm and qt first.

[massive-newb]

Ok... Installed QT 3.3.1. However, ./configure on SEQ is showing it pointing to the /lib for qt-3.1. If I do a cd $LD_LIBRARY_PATH it points to the /lib directory of qt-3.3. What have I screwed up?

[purple]

./configure --with-qt-dir=....

[massive-newb]

Didn't work. Checked config.log and it's looking at the /usr/lib/qt-3.3/lib directory and passing it by. Yes, I made the libraries. There are files there not just the README. I'm falling back to QT 3.1 for the time being. I'll just deal with CPU usage issue until I have more time to figure out how to properly upgrade to qt-3.3.3.

[massive-newb]

I'm tired of dealing with it now.

Ok.... Everything I've seen on the forums indicates that SEQ should function flawlessly with a complete install of Redhat 9.0. I.E. No other updates should be necessary. SEQ currently requires qt 3.0.5 or higher. RH 9.0 includes the qt 3.1.1 package, so no issues there. See post by Zaphod below:

http://www.showeq.net/forums/showpost.php?p=36847&postcount=8

Now, the issue as noted above has appeared before and other users have experienced it. As noted here, the first occurence was supposed to be fixed by requiring qt 3.0.5.

http://www.showeq.net/forums/faq.php?faq=seqfaq_help#faq_seqfaq_help_highcpuusa ge

It showed up again here: http://www.showeq.net/forums/showthread.php?t=4159 and really resulted in no definite resolution to the issue. (I am not using a screensaver period, and do not have standby enabled)

Now, you have 2 more users, me and BlackShadow (and I find it hard to belive that we're the only 2) that are using out of the box complete installs of Redhat 9.0 with qt 3.1.1 (which exceeds the basic requirements for SEQ) and has been noted as containing everything needed to run the program that are experiencing the SEQ Freezing issue.

I'll do whatever is necessary to help diagnose this issue, however, please note that "massive-newb" is NOT an understatement. I know just enough to be extremely dangerous to myself and others around me. Telling me to
"Maybe compile with debug enabled and connect a debugger to it so you can figure out what the heck it is doing to take up so much CPU? Maybe save off an strace of it and see if it is slamming file system calls looking for something it can't find?" is like me telling my grandma "Yeah, just put the car up on jack stands, take off the crossmember, unbolt the flywheel from the Torque converter, disconnect the tranny cooler lines and then just drop the tranny." I'm not saying she couldn't do, she just needs some detailed instructions.

[Zaphod]

A few points.

First and most importantly, not all causes of hanging/freezing are the same. qt-3.0.5 fixed A cause of slowdowns/hanges that was due to a design flaw in Qt 3.0 through 3.0.4. There were and still are issues with 3d screen savers and certain video cards (I'm not saying that it is your problem, but A problem). There also are some other potential slowdowns related to the idiocy of certain ATI Rage/Radeon driver authors staticly allocating over half of your video cards memory for 3D, even if you never use it that when combined with Xft (X font anti-aliasing) support compiled into Qt can cause severe performance issues if you exceed a certain number of maps or they exceed a certain size. And there is always the potential for actual bugs in ShowEQ itself...

Try the following:
In a console window (konsole, xterm, or what have you) run the command 'top'. This will tell you which applications are using the most CPU. Let us know what the top 3 or 4 are.
Paste us the output of 'showeq --version'.
Give us some details about your video card.
You might try compiling Qt from source with '-no-xft' and when you build ShowEQ make sure to set the QTDIR environment variable to point to it (typically 'export QTDIR=/wheverethehelliinstalledqt/' before running configure and make.


Enjoy,
Zaphod (dohpaZ)

[massive-newb]

TOP results:

18:30:53 up 17 min, 4 users, load average: 0.96, 0.50, 0.25
72 processes: 67 sleeping, 4 running, 0 zombie, 1 stopped
CPU states: 99.0% user 0.9% system 0.0% nice 0.0% iowait 0.0% idle
Mem: 255248k av, 251828k used, 3420k free, 0k shrd, 5576k buff
163056k actv, 17632k in_d, 4964k in_c
Swap: 521600k av, 6100k used, 515500k free 130968k cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
1934 root 25 0 41728 14M 844 R 97.3 5.8 3:17 0 X
2167 root 15 0 36696 12M 5308 R 0.7 5.1 0:03 0 showeq
2087 root 15 0 34724 11M 7220 S 0.5 4.4 0:01 0 kdeinit
2170 root 15 0 35744 12M 8512 R 0.5 4.8 0:01 0 konsole
2070 root 18446744073709551565 0 5204 5204 3904 S 0.3 2.0 0:00
2198 root 15 0 1084 1084 872 R 0.1 0.4 0:00 0 top
1 root 15 0 476 444 424 S 0.0 0.1 0:04 0 init
2 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 keventd
3 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kapmd
4 root 34 19 0 0 0 SWN 0.0 0.0 0:00 0 ksoftirqd_CPU
9 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 bdflush
5 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kswapd
6 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kscand/DMA
7 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kscand/Normal
8 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kscand/HighMe
10 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kupdated
11 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 mdrecoveryd
15 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kjournald
73 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 khubd
1179 root 20 0 0 0 0 SW 0.0 0.0 0:00 0 kjournald
1479 root 15 0 848 648 572 S 0.0 0.2 0:00 0 dhclient
1530 root 15 0 556 500 476 S 0.0 0.1 0:00 0 syslogd
1534 root 15 0 428 376 372 S 0.0 0.1 0:00 0 klogd
1552 rpc 19 0 520 448 444 S 0.0 0.1 0:00 0 portmap
1571 rpcuser 25 0 652 580 576 S 0.0 0.2 0:00 0 rpc.statd
1626 root 25 0 612 464 460 S 0.0 0.1 0:00 0 cardmgr
1650 root 24 0 476 428 424 S 0.0 0.1 0:00 0 apmd
1687 root 25 0 764 524 520 S 0.0 0.2 0:00 0 sshd
1701 root 24 0 728 580 576 S 0.0 0.2 0:00 0 xinetd
1718 ntp 15 0 2404 2404 2160 S 0.0 0.9 0:00 0 ntpd
1745 root 15 0 872 644 224 S 0.0 0.2 0:00 0 sendmail
1754 smmsp 25 0 532 524 0 S 0.0 0.2 0:00 0 sendmail
1764 root 15 0 92 92 40 S 0.0 0.0 0:00 0 gpm
1774 bin 15 0 444 444 12 S 0.0 0.1 0:00 0 cannaserver
1785 root 15 0 136 136 68 S 0.0 0.0 0:00 0 crond
1796 root 15 0 732 732 248 S 0.0 0.2 0:00 0 cupsd
1850 xfs 15 0 2804 2804 348 S 0.0 1.0 0:01 0 xfs
1859 root 39 19 88 88 8 S N 0.0 0.0 0:00 0 anacron
1868 daemon 15 0 228 228 168 S 0.0 0.0 0:00 0 atd
1878 root 25 0 420 420 368 S 0.0 0.1 0:00 0 rhnsd
1884 root 23 0 56 56 0 S 0.0 0.0 0:00 0 mingetty
1885 root 23 0 56 56 0 S 0.0 0.0 0:00 0 mingetty
1886 root 23 0 56 56 0 S 0.0 0.0 0:00 0 mingetty
1887 root 23 0 56 56 0 S 0.0 0.0 0:00 0 mingetty
1888 root 23 0 56 56 0 S 0.0 0.0 0:00 0 mingetty
1889 root 23 0 56 56 0 S 0.0 0.0 0:00 0 mingetty
1890 root 15 0 640 640 0 S 0.0 0.2 0:00 0 gdm-binary
1949 root 16 0 140 140 0 S 0.0 0.0 0:00 0 startkde
2007 root 15 0 236 236 40 S 0.0 0.0 0:00 0 ssh-agent
2050 root 15 0 4208 4184 3244 S 0.0 1.6 0:00 0 kdeinit

Closing Showeq results in the following:

18:32:50 up 19 min, 4 users, load average: 0.73, 0.62, 0.32
72 processes: 69 sleeping, 1 running, 1 zombie, 1 stopped
CPU states: 27.8% user 1.5% system 0.0% nice 0.0% iowait 70.5% idle
Mem: 255248k av, 239756k used, 15492k free, 0k shrd, 4624k buff
157028k actv, 4588k in_d, 3672k in_c
Swap: 521600k av, 8364k used, 513236k free 129284k cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
2201 root 19 0 1060 1060 856 R 0.9 0.4 0:00 0 top
1 root 15 0 476 448 424 S 0.0 0.1 0:04 0 init
2 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 keventd
3 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kapmd
4 root 34 19 0 0 0 SWN 0.0 0.0 0:00 0 ksoftirqd_CPU
9 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 bdflush
5 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kswapd
6 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kscand/DMA
7 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kscand/Normal
8 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kscand/HighMe
10 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 kupdated
11 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 mdrecoveryd

Results of showeq --version:

[root@localhost bin]# ./showeq --version
ShowEQ 5.0.0.15, released under the GPL.
SINS 0.5, released under the GPL.
All ShowEQ source code is Copyright (C) 2000-2004 by the respective ShowEQ Developers
ShowEQ comes with NO WARRANTY.

You may redistribute copies of ShowEQ under the terms of
The GNU General Public License.
See: http://www.gnu.org/copyleft/gpl.html for more details...

For updates and information, please visit http://seq.sourceforge.net/
ShowEQ 5.0.0.15, Built from 'main.cpp' on Sep 26 2004 at 16:37:14
CVS: @(#) $Id: main.cpp,v 1.33.6.5 2004/09/24 04:25:53 dohpaz Exp $ $Name: pre_5_0_beta $
Using GCC version: 3.2.2
Using glibc version: 2.3
Using Qt version: 3.1.1
Using headers from linux version: 2.4.20
Using EQItemDB: @(#) $Id: itemdb.cpp,v 1.10.6.3 2004/09/24 04:25:53 dohpaz Exp $ $Name: pre_5_0_beta $
Using GDBM: This is GDBM version 1.8.0, as of May 19, 1999.
Running on Linux release 2.4.20-31.9 for processor i686

Using config file '/root/.showeq/showeq.xml'
Loaded preferences file: /usr/local/share/showeq/seqdef.xml!
Loaded preferences file: /root/.showeq/showeq.xml!

Video Card:

Damn! Dreaded ATI:

ATI Rage 128 M
Driver is listed as r128.

[purple]

Weird. Can you post up your X config also? Either /etc/X11/xorg.conf or /etc/X11/XF86Config-4 probably. Curious if you have DRI turned on.

[Zaphod]

1934 root 25 0 41728 14M 844 R 97.3 5.8 3:17 0 X

combined with:

ATI Rage 128 M


yields, my thinking you probably have the dreated X Font Anti-Aliasing combined with bad video card driver juju problem....

meaning:

try compiling Qt from source with '-no-xft' and when you build ShowEQ make sure to set the QTDIR environment variable to point to it (typically 'export QTDIR=/wheverethehelliinstalledqt/' before running configure and make.


Should theoretically due the trick.

Enjoy,
Zaphod (dohpaZ)

[Zaphod]

The other thing you can try is disabling DRI/DRM in the kernel which will force it to use the non-DRI X driver version which at least in the past was more balanced towards 2d. Alas, I'm blanking on the details of how to disable it without recompiling your kernel.

Enjoy,
Zaphod (dohpaZ)

[purple]

In your xorg.conf if you are using X.org, you'll see something like:


Section "Module"
Load "extmod"
Load "glx"
Load "dri"
Load "dbe"
Load "record"
Load "xtrap"
Load "speedo"
Load "type1"
Load "freetype"
EndSection


Take out the Load "dri" and it shouldn't use DRI I'd think.