Issue information

Issue ID
#8556
Status
New
Severity
None
Started
Garr
Mar 5, 2015 21:51
Last Post
Garr
Mar 6, 2015 15:31
Confirmation
N/A

Garr - Mar 5, 2015 21:51

What the title says.[code=auto:0] #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> [/code][code=auto:514] 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; [/code]

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.

This post has been edited by Garr on Mar 5, 2015 21:54

Garr - Mar 6, 2015 11:52

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 >.<

4144 - Mar 6, 2015 12:43

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:[code=auto:0] make clean ./configure --enable-sanitize --enable-manager=no make [/code]
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.

Garr - Mar 6, 2015 15:31

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.