Segfault shortly after SEQ opens

[lars8279]

Greets

First off, let me preface this by saying I know my way around a computer, and I do a fair amount of development. :) Linux is not yet my strong suit, but I feel relatively comfortable with it. OK, so here's what's happening...

For awhile there, everything was hunky dory - I was running 5.0.0.13 (on Fedora Core 2) and had installed the numerous patches to get everything up and going. I started up yesterday, and about 3 seconds after the program started it segfaulted. No error message (other than a warning a few lines earlier about not finding map "unknown") or other indications as to the nature of the problem. To my knowledge, nothing had changed since the last time I ran the program. Odd.

I proceeded to load 5.0.0.14 from CVS, and same problem. I then blew away as much of my old remnants as possible (/usr/local/share, /root/.showeq, the build directory) and start over with CVS. STILL the same problem.

One interesting thing I noted - if I start SEQ and zone quickly, the map and skittles come up briefly like everything is working, then bam, right back to the terminal window.

Are there some sort of debug options I can pass to the command line to get more information on what's going on? I didn't see any with --help that would be particularly useful for this. Any direction on how to track down this mystery would be appreciated. I'm hoping it's something stupid and not some weird library incompatiblity. :)

Also, if there's any other pertinent information I can attach to the post, let me know. I didn't want to post a bunch of irrelevant crap that won't help matters.

Thanks!

Lars

[tanner]

Make sure seq is compile with debug on and installed without stripping it.

# yum install gdb
# gdb -d /path/to/showeq/src /path/to/showeq

When it cores, gdb will tell you exactly where, if you want to be more helpful, you can do a 'bt' for backtrace and see the call stack.

For more info on gdb look here:
http://www.gnu.org/software/gdb/gdb.html

Don't like CLI debuggers, look at ddd frontend.

[lars8279]

Awesome, this is an excellent starting point!

It wouldn't be complete, however, without me showing at least a bit of ignorance on my part. What do I need to do to ensure SEQ is compiled with debug info as well as installed properly? I know how to do it on a Windows C++ compiler, but someone told me this isn't Windows! ;)

[Alethal]

I have had the same problem but figured it occured when I had too much non-EQ traffic going on. I traced it down and it seems to segfault in a function doing a CRC32 check.

I did not try to dig into it further since I didn't have the time to get into it and that the problem could be avoided. Anyway, I don't have a linux box at the moment but I will check it when I do and let you know if I find anything.

[lars8279]

I changed this post about 50 times now. :)

Among the data returned in the debugger was some warning information indicating the IP addresses of the source and destination,along with ports. Just for fun, I decided to do an nslookup on the source IP address, and discovered to my surprise that it was our corporate VPN. Sure enough, I had a VPN connection established on a different machine (but same network segment), which SEQ mistook for an EQ client apparently. As soon as it tried to decode those packets, boom, crash time.

Thanks so much for the advice on using gdb, it helped a ton. The problem is solved.

[Cryonic]

SEQ looks at all UDP based traffic when sniffing for EQ sessions...

Solution, turn on Session Tracking

[Zaphod]

This crash should be fixed in the latest release.

Enjoy,
Zahod (dohpaZ)