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

  • #008556

  • 0 - None Assigned

  • New

Issue Confirmations

  • Yes (0)No (0)
Photo

YAMC ( Yet Another Map Crash)

Posted by Garr on 05 March 2015 - 09:51 PM

What the title says.
#0  0x080c9f58 in clif_send (buf=0xbfabaf50, len=20, bl=0x15023fd0, type=GUILD_WOS) at clif.c:536
        i = 3
        sd = <value optimized out>
        p = <value optimized out>
        g = (struct guild *) 0xb228c65c
        bgd = <value optimized out>
        x0 = 0
        x1 = 0
        y0 = 0
        y1 = 0
        fd = -33686019
        iter = <value optimized out>
        __FUNCTION__ = "clif_send"
#1  0x080b6f85 in clif_guild_memberlogin_notice (g=0xb228c65c, idx=0, flag=1) at clif.c:7362
        buf = "Р\001\234\006l\000/2\004\000\001\000\000\000\001\000(\000\006\00058\000\000\234\006l\000ч═\r\b\234\006l\000\r\000\000\000\230╞╚©h\237\r\bxl9\025\000\000\000\000v\177\000\000\000\000\000"
        sd = (struct map_session_data *) 0x0
        __FUNCTION__ = "clif_guild_memberlogin_notice"
#2  0x080df2a7 in guild_recv_memberinfoshort (guild_id=32630, account_id=7079580, char_id=274991, online=1, lv=99,
    class_=23) at guild.c:1022
        i = <value optimized out>
        alv = <value optimized out>
        c = 13
        idx = 0
        om = <value optimized out>
        oldonline = 0
        g = (struct guild *) 0xb228c65c
#3  0x080e854e in intif_parse_GuildMemberInfoShort (fd=5) at intif.c:1222
No locals.
#4  0x080ed2e0 in intif_parse (fd=5) at intif.c:2241
        packet_len = 19
        cmd = 14389
#5  0x08092881 in chrif_parse (fd=5) at chrif.c:1368
        packet_len = 0
        cmd = 14389
        r = <value optimized out>
#6  0x0822b79f in do_sockets (next=<value optimized out>) at socket.c:868
        rfd = {fds_bits = {32, 0 <repeats 31 times>}}
        timeout = {tv_sec = 0, tv_usec = 50000}
        ret = <value optimized out>
        i = 5
#7  0x082280ef in main (argc=1, argv=0xbfabb224) at core.c:256
        next = <value optimized out>
        retval = <value optimized out>
		case GUILD_WOS:
		case GUILD_NOBG:
			if (sd && sd->status.guild_id)
				g = sd->guild;

			if (g) {
				for(i = 0; i < g->max_member; i++) {
					if( (sd = g->member[i].sd) != NULL ) {
						if( !(fd=sd->fd) )
							continue;

						if( type == GUILD_NOBG && sd->bg_id )
							continue;

						if( sd->bl.id == bl->id && (type == GUILD_WOS || type == GUILD_SAMEMAP_WOS || type == GUILD_AREA_WOS) )
							continue;

						if( type != GUILD && type != GUILD_NOBG && type != GUILD_WOS && sd->bl.m != bl->m )
							continue;

						if( (type == GUILD_AREA || type == GUILD_AREA_WOS) && (sd->bl.x < x0 || sd->bl.y < y0 || sd->bl.x > x1 || sd->bl.y > y1) )
							continue;
						WFIFOHEAD(fd,len);
						memcpy(WFIFOP(fd,0), buf, len);
						WFIFOSET(fd,len);
					}
				}
				if (!map->enable_spy) //Skip unnecessary parsing. [Skotlex]
					break;

				iter = mapit_getallusers();
				while( (tsd = (TBL_PC*)mapit->next(iter)) != NULL ) {
					if( tsd->guildspy == g->guild_id ) {
						WFIFOHEAD(tsd->fd, len);
						memcpy(WFIFOP(tsd->fd,0), buf, len);
						WFIFOSET(tsd->fd,len);
					}
				}
				mapit->free(iter);
			}
			break;

I really have no idea where that fun fd of -33686019 could jump out of...

ETA: May gdata be corrupted in this case? Earlier that day merch from that guild with @at was logged out via at_limit setting. It might not have anything to do with it, but this guess is as good as any.

More info: turns out I was right about vendor logging out. Chasing around logs I figured the name, got the IDs and all. Now to figure out why vendor that had at_limit after logging out left not-null g->member[3].sd that triggered the crash >.<

If you using linux and gcc 4.8 or gcc 4.9 or some recent clang, you can enable special configure option what can try find why error happend. Most time it show where it happend and why.
If you can reproduce issue try this:
make clean
./configure --enable-sanitize --enable-manager=no
make

And at next crush without gdb it will show where error happend and a bit why it happend.
Second flag need because buildin memory manager mess with memory allocations.

Sadly, I'm far from using gcc 4.8/4.9 on production server >.< If I'll find out how to reproduce it I'll try it on my local test server though. Thanks for suggestion.