Menu
▾
▴
[Perfparse-users] RES: More information about Glibc error
|
From: Paulo A. G. F. <pau...@de...> - 2007-03-30 17:28:48
|
Well, my database is really HUGE these days: [root@noruega ~]# ls -lh /var/lib/mysql/perfparse/ total 111G -rw-rw---- 1 mysql mysql 8.8K Oct 21 2005 = perfdata_raw_summary_data.frm -rw-rw---- 1 mysql mysql 104M Mar 25 17:30 = perfdata_raw_summary_data.ibd -rw-rw---- 1 mysql mysql 8.7K Oct 21 2005 perfdata_service_bin.frm -rw-rw---- 1 mysql mysql 59G Mar 30 14:17 perfdata_service_bin.ibd -rw-rw---- 1 mysql mysql 8.6K Oct 21 2005 perfdata_service_raw.frm -rw-rw---- 1 mysql mysql 50G Mar 30 14:17 perfdata_service_raw.ibd Is there a way to change this routine to accommodate large tables such = as I have here?=20 Anyway, I've set the environment variable MALLOC_CHECK_ to 1 and this = seems to be a workaround to the problem. Right now I'm importing all = data since March 18 and it's going nicely to the database, until now. = It's just a painstaking slow process. :( Paulo Afonso Graner Fessel Administrador de Ambiente e Sistemas UNIX pau...@de... Fone: +55 (11) 3848-7422 (Novo n=FAmero) http://www.dedalusprime.com.br > -----Mensagem original----- > De: Yves Mettier [mailto:yme...@fr...] > Enviada em: sexta-feira, 30 de mar=E7o de 2007 14:12 > Para: Paulo Afonso Graner Fessel > Cc: per...@li... > Assunto: Re: [Perfparse-users] More information about Glibc error >=20 > Hi ! >=20 > I have no perfparse development environment so I can only read from = the > mail. >=20 > What I see is that p2 is far too big. It increments until it finds a = \0 > character. > If p2 is so big, there is a problem before in the string that p2 = iterates > on. >=20 > Enjoy :) > Yves >=20 > On Fri, 30 Mar 2007 12:49:38 -0300, "Paulo Afonso Graner Fessel" > <pau...@de...> wrote: > > I've traced the problem with greater detail and found that the = problem > is > > at perf_get_next at log_parser.c file. > > > > The problem occurs within these lines of code: > > > > if(p1[0] =3D=3D '\'') { > > p1++; > > p2 =3D p1; > > /* Check length of label */ > > while(p2[0] !=3D '\0') { > > if((p2[0] =3D=3D '\\') && (p2[1] =3D=3D = '\'')) { > > p2++; > > } else if((p2[0] =3D=3D '\\') && (p2[1] = =3D=3D '\\')) { > > p2++; > > } else if(p2[0] =3D=3D '\'') { > > break; > > } > > p2++; > > } > > if(p2[0] =3D=3D '\0') return(-2); > > if(p2[1] !=3D '=3D') return(-3); > > /* Reallocate memory for label if necessary */ > > l =3D p2-p1; > > if(l>=3D p->label_len) { > > p->label_len +=3D 20; > > perfparse stops here =3D> p->label =3D > > realloc(p->label,p->label_len*sizeof(char)); > > if(NULL =3D=3D p->label) return(-4); > > } > > > > > > And here go perfparse-log2mysql famous last words: > > > > 154 l =3D p2-p1; > > (gdb) n > > 155 if(l>=3D p->label_len) { > > (gdb) > > 157 p->label =3D > > realloc(p->label,p->label_len*sizeof(char)); > > (gdb) > > 156 p->label_len +=3D 20; > > (gdb) > > 157 p->label =3D > > realloc(p->label,p->label_len*sizeof(char)); > > (gdb) > > *** glibc detected *** realloc(): invalid next size: 0x09853f98 *** > > > > Program received signal SIGABRT, Aborted. > > 0x006327a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > > (gdb) backtrace full > > #0 0x006327a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > > No symbol table info available. > > #1 0x006727f5 in raise () from /lib/tls/libc.so.6 > > No symbol table info available. > > #2 0x00674199 in abort () from /lib/tls/libc.so.6 > > No symbol table info available. > > #3 0x006a64ea in __libc_message () from /lib/tls/libc.so.6 > > No symbol table info available. > > #4 0x006ae8c2 in _int_realloc () from /lib/tls/libc.so.6 > > No symbol table info available. > > #5 0x006af786 in realloc () from /lib/tls/libc.so.6 > > No symbol table info available. > > #6 0x002ff067 in perf_get_next (data=3D0x98408b8, p=3D0x98409e8) at > > log_parser.c:157 > > p1 =3D 0x772820 "\001" > > p2 =3D 0x9853f98 "" > > l =3D Variable "l" is not available. > > > > I've found a link > > (http://www.archivesat.com/Linux_C_programming/thread1222039.htm) = which > > tells about some kind of programming error which "blows away = bookkeeping > > of the memory allocator". In this case, is this a Perfparse bug or a > glibc > > bug? > > > > []'s and TIA > > > > Paulo Afonso Graner Fessel > > Administrador de Ambiente e Sistemas UNIX > > pau...@de... > > Fone: +55 (11) 3848-7422 (Novo n=FAmero) > > http://www.dedalusprime.com.br > > > > > > = ------------------------------------------------------------------------ > - > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to = share > > your > > opinions on IT & business topics through brief surveys-and earn cash > > > = http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > > _______________________________________________ > > Perfparse-users mailing list > > Per...@li... > > https://lists.sourceforge.net/lists/listinfo/perfparse-users > -- > - Homepage - http://ymettier.free.fr - http://www.logicacmg.com - > - GPG key - http://ymettier.free.fr/gpg.txt - > - Maitretarot - http://www.nongnu.org/maitretarot/ - > - C en action - http://www.oreilly.fr/catalogue/2841772896.html - |
