Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización: 31 de Enero de 2.000 - Lunes
Bajo UltraSparc y el nuevo compilador GCC 2.95.2 (fruto de la fusión de GCC y EGCS), la versión 3.0.55 de la popularísima librería DB muere con un "core dump".
Tras investigar el problema y observar incluso las salidas en ensamblador del compilador de C (nada como conocer el funcionamiento de un ordenador a bajo nivel), informé de un "bug" y de su posible solución tanto a la gente de la librería DB como a la lista de correo del GCC/EGCS.
Subject: DB 3.0.55, memset() and overoptimizacion Date: Wed, 01 Dec 1999 05:06:09 +0100 From: Jesus Cea Avion <jcea@argo.es> Organization: Argo Redes y Servicios Telematicos, S.A. - http://www.argo.es/ To: db@sleepycat.com, gcc@gcc.gnu.org
I was just trying to use the new DB 3.0.55, but my source core dumps consistently. I found the bug inside DB library, in "memset()" usage.
The problem seems to be a over-optimization in the new GCC 2.95.2 (not checked using other compilers), UltraSparc (Sun Microsystems). When the pointer in "memset" points to a struct and the counter is a compiler time constant, GCC assumes 64bits alignment and emits "std" (store double: 64 bits) assembler instructions. But, at least in UltraSparc I, "std" needs to be aligned in 64 bit boundaries or you are dead.
DB 3.0.55 only garantees a sizeof(size_t) (tipically 32 bits) alignment.
Two posible patches:
Here you have a fast&dirty patch (works for me) using the first approach:
>>>>>
diff -c -r1.1.1.1 -r1.2
*** env/db_salloc.c 1999/10/19 21:22:12 1.1.1.1
--- env/db_salloc.c 1999/12/01 03:40:49 1.2
***************
*** 94,101 ****
*/
++len;
#endif
! align = align <= sizeof(size_t) ?
! sizeof(size_t) : ALIGN(align, sizeof(size_t));
/* Walk the list, looking for a slot. */
for (elp = SH_LIST_FIRST((struct __head *)p, __data);
--- 94,101 ----
*/
++len;
#endif
! align = align <= (2*sizeof(size_t)) ?
! (2*sizeof(size_t)) : ALIGN(align, (2*sizeof(size_t)));
/* Walk the list, looking for a slot. */
for (elp = SH_LIST_FIRST((struct __head *)p, __data);
<<<<<
God, 5:10 AM!. Time to rest...
Subject: Re: DB 3.0.55, memset() and overoptimizacion [#1395] Date: Tue, 30 Nov 1999 23:41:12 -0500 (EST) From: Sleepycat Software <db@abyssinian.sleepycat.com> To: jcea@argo.es CC: gcc@gcc.gnu.org
Thank you for your email.
> I was just trying to use the new DB 3.0.55, but my source core dumps
> consistently. I found the bug inside DB library, in "memset()" usage.
I'm sorry to hear this.
> The problem seems to be a over-optimization in the new GCC 2.95.2 (not
> checked using other compilers), UltraSparc (Sun Microsystems). When the
> pointer in "memset" points to a struct and the counter is a compiler
> time constant, GCC assumes 64bits alignment and emits "std" (store
> double: 64 bits) assembler instructions. But, at least in UltraSparc I,
> "std" needs to be aligned in 64 bit boundaries or you are dead.
We found (and fixed) several of these bugs when we did our last release, but it looks like there are still more. (We only found problems with memcpy, not memset.)
The compiler has no justification, of which I'm aware, for doing this. The only solution I can think of is to replace all of the calls to memmove, memcpy and memset with our own versions of those functions so the compiler can't do this. I don't see any other way to ensure this problem doesn't continue to occur.
As a workaround, you should use the Solaris compiler for Berkeley DB on the Ultrasparc.
Do you know of any way to submit bug reports to the gcc development group?
Can we find out if they have some justification for this?
Regards,
Amy Adams
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Amy Adams Berkeley DB Product Manager Sleepycat Software Inc. db@sleepycat.com 394 E. Riding Dr. http://www.sleepycat.com Carlisle, MA 01741-1601
