David,
Matthias likely is able to help you (on To:).
Regards
Kay
David Tardon wrote:
Hi,
can someone explain to me (and anyone else interested) reason for
OSL_ASSERT's in sal/rtl/source/alloc_cache.c at lines 925 and 926
(DEV300_m31)? Their presence disables OOo to compile with
--enable-dbgutil on x86_64.
The problem is that on x86_64 during initialization of gp_cache_arena in
rtl_cache_once_init(), rtl_arena_activate() calls rtl_cache_create(), which
calls rtl_cache_activate(). Now, at line 924, cache->m_slab_size is
calculated to be 8192 on x86_64, so it takes the 'if' branch (on i386 it
takes the 'else' branch, where there is no OSL_ASSERT present; so no
problem) and ends here, because gp_cache_slab_cache and
gp_cache_bufctl_cache haven't been initialized yet. As gp_cache_arena
is used during _their_ initialization, it's not possible to simply move
initialization blocks in rtl_cache_once_init().
David
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Sun Microsystems GmbH Kay Ramme
Sachsenfeld 4 Senior Technical Architect
20097 Hamburg Phone: (+49 40) 23646 982
Germany Fax: (+49 40) 23646 550
http://www.sun.com/staroffice mailto:[EMAIL PROTECTED]
http://www.sun.com/openoffice
http://udk.openoffice.org
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
