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.