Confirmed repeatable Seg Fault

[TriggerHappy]

As posted by SeqUser in the "Seg Fault since latest VI Patch" I get a reproducible Segmentation fault when looting a mob with no loot.

I can sit on the downed mob for several seconds and stand up-- boom seg fault. I can loot quickly-- at stand up get Seg Fault. I can wait until corpse poofs-- Seg Fault. However, no seg faults in same zone on mobs with loot.

I am on a PII600 with Mandrake 8.1 and all the standard libes. It does this with or without my modifications for output discussed on other threads. Later tonite when I get back from a dinner I will recompile with the new LibEQ and see if that is the problem. Though I think it was Fee who thought there was an issue in SpawnShell or Spawn.cpp, I can't remember as I read it this morning, that he thought his debug showed there was blowing up of an array. Whatever it is it one version of the SEG fault can be reproducibly demonstrated.

Since there are likely patches to the code coming that will make some rewrite of code necessary this might be something worth looking into-- likely it is the reason why some zones with lots of people in it and random no-loot mob looting/poofing is causing some people to have lots of SEG faults while other people who happen not to spend time in such zones to have no problems?

Tomorrow's patch will make this a bigger or lesser issue depending on what VI has in store for us...

TH

[fee]

You seem to have an interesting situation here. I for one am not able to reproduce this bug at all.

If you don't mind, could you run thru gdb and get a stacktrace at the time of the segfault?

'gdb showeq'
when it segfaults
'bt'
collect the output that follows. This will atleast give me an idea of who what when where.

Thanks
fee

[TriggerHappy]

Tried that. Ran the gdp program right after seg fault. Says

"No stack"

when I ran the bt command.

I tried running the gdb program and then opening showeq from another terminal window... got the seg fault and then ran the backtrace command-- same result "No Stack".

Perhaps I just don't understand how to get the gdb program to capture correctly?

Happy to run it again tomorrow if you can tell me what I am doing wrong here...

[TriggerHappy]

Was reading some of the help files in gdb. When I run info files it does show me as being in the showeq directory and lists a bunch of addresses beginning with .interp and going on for about 23 lines or so.

When I do info frames it says "No stack" also.

It does say when it seqfaults that "core dumped". Does this mean the stack was wiped and that's why bt does not work?

I will look more into the docs to see if I can figure out how the debugger works and if cannot figure out will look back here tomorrow for your reply.

To reiterate the steps I took:

To start showeq I type: ./showeq -i eth0 XXX.XXX.XXX.XXX

At seg fault I type:

gdb showeq

blurbs from gdb then at prompt I type

bt

get-- "no stack"

[UnGod]

to run showeq for the first time run:

gdb ./showeq
when gdb prompt appears type:
run -i eth0 XXX.XXX.XXX.XXX
when it segfaults type:
bt

post that info here i thinks

[fee]

What he said ^

You run showeq inside of gdb. so your command line looks like what he said ^.


It does sound like showeq generated a core file. Good news! Look for a file called 'core' in the directory you ran showeq. Type 'file core' and it should tell you that the core was generated by showeq.

Next step, run gdb like this 'gdb showeq core'. At the gdb prompt do a 'bt' to get the stack trace.

fee

[TriggerHappy]

I figured it was something like this. Will run it tonite after the VI patch and when I get home from work.

TH

[TriggerHappy]

After this patch, and using the new LibEQ and the updated ShowEQ, the problem of looting empty mobs causing Seg Faults has disappeared for now.

Go figure.

If it reappears in any obvious form I will repost.

TH