Jump to content

  •  

Bug Tracker Migration

June 3rd
Good news everyone! The staff has decided that it is time to slowly kill off this Bug Tracker. We will begin the process of slowly migrating from this Bug Tracker over to our Github Issues which can be found here: https://github.com/HerculesWS/Hercules/issues

Over the next couple of days, I will be closing off any opportunity to create new reports. However, I still will keep the opportunity to reply to existing Bug Reports. Doing this will allow us to slowly fix any bug reports we have listed here so that we can easily migrate over to our Issue Tracker.

Update - June 7th 2015: Creating new bug posts has been disabled. Please use our https://github.com/HerculesWS/Hercules/issues tracker to post bugs. Users are still able to reply to existing bug posts.

- Administration

Issue Information

  • #007157

  • 0 - None Assigned

  • Needs More Info

Issue Confirmations

  • Yes (0)No (0)
Photo

Crash in map.c map_removemobs_sub

Posted by Ryuuzaki on 11 April 2013 - 08:14 PM

Program terminated with signal 11, Segmentation fault.
#0  0x000000000042ae8f in map_removemobs_sub (bl=0x7f148f7b67ac, ap=<value optimized out>) at map.c:2308
2308            if( md->db->mexp > 0 )
(gdb) bt full
#0  0x000000000042ae8f in map_removemobs_sub (bl=0x7f148f7b67ac, ap=<value optimized out>) at map.c:2308
        md = 0x7f148f7b67ac
        __FUNCTION__ = "map_removemobs_sub"
#1  0x000000000043252f in map_foreachinmap (func=0x42ae30 <map_removemobs_sub>, m=<value optimized out>, type=<value optimized out>) at map.c:1223
        b = <value optimized out>
        bsize = <value optimized out>
        returnCount = <value optimized out>
        bl = <value optimized out>
        blockcount = 0
        i = 2
        ap = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7fff7f0588c0, reg_save_area = 0x7fff7f0587e0}}
#2  0x00000000004326ab in map_removemobs_timer (tid=<value optimized out>, tick=<value optimized out>, id=<value optimized out>, data=<value optimized out>) at map.c:2335
        count = <value optimized out>
        m = <value optimized out>
#3  0x000000000059b64f in do_timer (tick=3302495670) at timer.c:370
        tid = 105
        diff = -16
        __FUNCTION__ = "do_timer"
#4  0x00000000005988ac in main (argc=1, argv=0x7fff7f058a28) at core.c:333
        next = <value optimized out>
Have only slight modifications in map.c nothing anywhere related to that function. Changed from RA to herc today after 3 days of code implementation.
Any idea what could be wrong here? It didn't crash on windows test machine for 3 days of testing, live server is centos 6.

Why would it crash on the mexp call? Only had one player online at this point, he ran around in payon cave 3 (pay_dun02) (bongun munak etc.) was playing Monk class, was using that KI explosion skill a lot.
Server setting pre-re.


If you need more info let me know, thanks!

well by the crash i can say the mob_data in question is most likely either with no md->db pointer or with a broken md->db pointer, if you're still on gdb, would it be possible to do the following?
up 0
p md->db
it will tell us whether there is no address (0x0) or any address (0xsomething), that will let we know whether the db link is missing or corrupt.

also a
p md->class_
will let we know whats the mob id of the entry

$1 = (struct mob_db *) 0x0

Nullpointer? But why isn't there a check like

if(!md)
return 0;

at the top of the function?

Ind 
changed status to: Needs More Info

1369 -> Grand Peco, how is that even remotely possible? No one killed that mob, maybe someone damaged it and it got "corrupted" or something?

BTW thanks for pointing that out, that it's possible to get access to transmitted values, didn't know that this is possible, you learned stop to learn i guess :P

Edited by Ryuuzaki, 11 April 2013 - 09:05 PM.


but there is o-o its weird
int map_removemobs_sub(struct block_list *bl, va_list ap) {
	struct mob_data *md = (struct mob_data *)bl;
	nullpo_ret(md);
it shouldn't have gotten there if the unit was null

also it wasn't null at the time of the crash o-o (i failed to notice that on my first reply)
#0  0x000000000042ae8f in map_removemobs_sub (bl=0x7f148f7b67ac, ap=<value optimized out>) at map.c:2308
        md = 0x7f148f7b67ac


Yeah very very weird, so it magically lost it's data during the function.

no not really its more like the 0x0 you printed wasnt from that case, from the begin of that function until the part it crashed there is no place it changes the data

When i typed



(gdb) p md


It returned


$6 = (struct mob_data *) 0x7f148f7b67ac
Does that help you in any way?

did you move to the segment that crashed prior to typing that ( you use 'up <number>' and 'down <number>' )?

btw what about 'p md->db'?

Didn't change anything, it was still at "up 0"

(gdb) p md->db
$9 = (struct mob_db *) 0x0

ooh o.o i'm sorry you've been doing it correctly and i've read it wrong XD T_T

I can't find in the code anything that removes a md->db link, do you have anything custom that spawns monsters?

btw something occured to me, let me know what a
p bl->type
displays

p bl->type
$10 = BL_MOB

You mean a function or something like a questmob which triggers a label?

I have a function which checks for a specific monster on the map, will then return its coordinates and display a "viewpoint" on the map for every player currently on the map.
Running through a script (npc file) based while loop with a 5 seconds delay, then refresh the "viewpoint" again.

That's the only thing i could remotely think of.

Edited by Ryuuzaki, 11 April 2013 - 09:51 PM.


I personally don't see how this crash happens only here tho, md->db is used on a number of places without checks too. anyhow try to change that line from
	if( md->db->mexp > 0 )
		return 0;
to
	if( md->db && md->db->mexp > 0 )
		return 0;
if its really a md->db problem it will crash elsewhere and give us a another clue

Gonna put the md->db check in really quick, let's see if the server crashes again.

On a quite unrelated note, when i was coding this viewpoint for all players given map, i wanted to use the getmapxy function to search for the mob name.
When reading the code i noticed following in the header:

* type - type of object * 0 - Character coord * 1 - NPC coord * 2 - Pet coord * 3 - Mob coord (not released) .... BUILDIN_FUNC(getmapxy)
Searching for monsters was not "released", so i couldn't get the coords from that particular quest monster.

I made it possible by modifying the function and adding a new _sub specific for monsters, does hercules have any interest in that feature? If yes i can release it.
Let me know if you want an insight on it.

Edited by Ryuuzaki, 11 April 2013 - 10:00 PM.


Searching for monsters was not "released", so i couldn't get the coords from that particular quest monster.

I made it possible by modifying the function and adding a new _sub specific for monsters, does hercules have any interest in that feature? If yes i can release it.
Let me know if you want an insight on it.

I dunno about whether hercules would use it (i don't decide stuff alone) but if you dont mind displaying it to others send me it through a pm and i can take a look to see if anything on that is conflicting