Tcl Source Code

tclThreadAlloc.c
..\generic\tclThreadAlloc.c(974) : error C2220: warning
treated as error - no object file generated
..\generic\tclThreadAlloc.c(974) : warning C4013:
'TclpFreeAllocMutex' undefined; assuming extern
returning int
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.

The problem has to do with the re-organization of the
threaded memory allocator related defines a while back.

When compiling with debugging, the TclpFreeAllocMutex
does not get declared in tclInt.h (and some other
functions as well).

Logged In: YES 
user_id=72656

I am closing this as a dup to 1079199.  The statement about
behavior of the configure is correct, except that it does
build a "correct" build, as can be seen with this Linux
build test:

commodore [~/build/tcl84std] 201 > make shell
% info patch
8.4.9
% head config.status
#! /bin/sh
# Generated automatically by configure.
# Run this file to recreate the current configuration.
# This directory was configured as follows,
# on host commodore:
#
# /home/jeffh/cvs/tcl/tcl8.4/unix/configure 
--prefix=/home/jeffh/install
--exec-prefix=/home/jeffh/install/linux-x86_64
--disable-shared --enable-threads --enable-symbols=mem
#
# Compiler output produced by configure, useful for debugging
# configure, is in ./config.log if it exists.
% set tcl_platform(threaded)
1
%

Logged In: YES 
user_id=21885

I just filed [RFE #1079199] for the non-zippy configuration:

[ 1079199 ] Build a threaded Tcl without the "zippy" allocator.

Logged In: YES 
user_id=21885

Jeff, I disagree.  The patch that was applied /introduces/ a
bug, which breaks a previously valid configuration
(TCL_MEM_DEBUG + USE_THREAD_ALLOC).  Therefore, it must be
backed out.

Looking at things, once this change is backed out, I think
Joe's original reason for opening this bug will go away: a
memory-debug threaded Tcl build on Win32 should work, just
as it will on Solaris and Linux.

The "feature request" part here is to be able to build an
--enable-threads Tcl *without* USE_THREAD_ALLOC defined. 
Fine -- I'll file that as a separate RFE.  However, the
applied patch needs to be backed out to fix the
--enable-threads --enable-symbols=mem build, which now
currently does NOT do the right thing as it defines
USE_THREAD_ALLOC (therefore generic/tclAlloc.c won't be
used) and defines TCL_MEM_DEBUG (therefore
generic/tclThreadAlloc.c won't be used).  Since those are
the only two places where TclpAlloc() and TclpFree() are
defined ... this breaks the build!

I still say this is a bug, that was solely introduced by the
application of the patch attached to this bug tracker item.

Logged In: YES 
user_id=21885

To clarify:

--disable-threads: use generic/tclAlloc.c

--disable-threads, --enable-symbols=mem: use
generic/tclCkalloc.c AND generic/tclAlloc.c

--enable-threads: use generic/tclThreadAlloc.c

--enable-threads, --enable-symbols=mem: use
generic/tclCkalloc.c AND generic/tclThreadAlloc.c

I can see where the "confusion" comes from because of the
way the #ifdef's are laid out in generic/tclInt.h, with
"#ifdef TCL_MEM_DEBUG ... #elif defined(TCL_THREADS) &&
defined(USE_THREAD_ALLOC)" but there was a distinct
difference in Tcl's behavior if built USE_THREAD_ALLOC with
and without TCL_MEM_DEBUG ... until the patch applied to
this bug was applied.

The one configuration that's not possible using Tcl's
"configure" script currently is the threaded-no-zippy Tcl
build which we still build at AOL (for debugging purposes).
 Basically, it defines TCL_THREADS but not USE_THREAD_ALLOC
-- you get a threaded Tcl build, but use the allocator from
generic/tclAlloc.c instead of generic/tclThreadAlloc.c.  I
can file this as a RFE/FRQ if necessary, but our internal
builds at AOL can happily continue to use the "sed tricks"
to produce this build if the Tcl core doesn't want to
support it as a valid configuration.

An interesting question for non-threaded Tcl builds would be
to support USE_THREAD_ALLOC as a valid option -- for
platforms running Tcl with plenty of memory, it should speed
up Tcl_DString performance or other places where chunks of
small memory are allocated and grown frequently.  Basically,
TCL_THREAD is undefined but USE_THREAD_ALLOC is defined. 
Not sure if Tcl would even build this way, but if it does,
I'd be curious to see what the Tcl benchmarks have to say.

Again, the correct thing to do is back out the change
associated with the "fix" to this bug.

To answer Joe's question, you debug the threaded (zippy)
memory allocator with --enable-threads --enable-symbols=mem,
and if that doesn't build on Win32 then we need to talk
about why it doesn't build (what symbols are missing and
then implement those as appropriate for Win32, etc.).

data_type - 360894

Logged In: YES 
user_id=72656

This will not be fixed prior to either of those releases. 
This is an enhancement to the build configuration, not a
real bug in Tcl per se.

Logged In: YES 
user_id=113501

I have to agree with Dossy here.  

The TCL_MEM_DEBUG flag should NOT be mutually exclusive 
of the TCL_THREADS/USE_THREAD_ALLOC flags.  The fundamental
question becomes "Then how do you debug the threaded memory
allocator?"  This issue needs to be fixed some other way
that doesn't break things.

Also, this should be fixed prior to 8.4.9 and 8.5a2.

Logged In: YES 
user_id=21885

I agree with you, Jeff, since the special AOLserver builds
actually use sed scripts to change Tcl after Tcl's
"configure" script has been run.

The error in the AOLserver build that I get now when in the
--enable-symbols=mem Tcl configuration is:

nsthreadtest.o: In function `DumperThread':
/cm/build/public/aolserver_v40_r9_test/aolserver/aolserver/nsthread/nsthreadtes
t.c:336: undefined reference to `Tcl_GetMemoryInfo'

The addition of "!defined(TCL_MEM_DEBUG)" to the top of
generic/tclThreadAlloc.c in the fix to bug 1030548 means
that Tcl_GetMemoryInfo() which is defined in the file won't
get compiled.

Since it seems that defining TCL_THREADS and
USE_THREAD_ALLOC is mutually exclusive to TCL_MEM_DEBUG,
then perhaps the fix to this bug is correct, and AOLserver
needs to be modified.  However, the change introduced by
this fix does break backward compatibility at least for one
application (grin) -- perhaps a Tcl_GetMemoryInfo() can be
defined in the "#else" section at the end of
generic/tclThreadAlloc.c the same way
TclFinalizeThreadAlloc() was done?

The reason why I think this is wrong is really because I
think the notion of TCL_MEM_DEBUG being mutually exclusive
to TCL_THREADS/USE_THREAD_ALLOC is a mistake or
misunderstanding when it was integrated into the Tcl core.  

TCL_MEM_DEBUG was really meant to select behavior for
Tcl_Alloc/Tcl_Free and friends, in generic/tclCkalloc.c if
TCL_MEM_DEBUG is on, they use the debug allocator
Tcl_DbCkalloc which wraps TclpAlloc else Tcl_Alloc uses
TclpAlloc unwrapped and Tcl_Free uses TclpFree unwrapped, etc.

USE_THREAD_ALLOC is the selector for the "zippy" allocator
(generic/tclThreadAlloc.c) vs. using the normal Tcl
allocator (generic/tclAlloc.c) allocator, implementing their
own versions of TclpAlloc and TclpFree, etc.

So, TCL_MEM_DEBUG is a wrapping around the Tclp{Alloc,Free}
that's provided by EITHER tclThreadAlloc.c OR tclAlloc.c. 
It's not INSTEAD of.

Does this help make things clear why I think the
configurations that we are building at AOL are legitimate
configurations that, correctly, Tcl cannot validly produce
(but were SUPPOSED to!)?

-- Dossy

Logged In: YES 
user_id=72656

I believe this issue is correctly fixed, and the Dossy's
configuration was never a valid product of the Tcl
'configure' script.

Logged In: YES 
user_id=79902

What is the aspect of aolserver that fails to build when
threads+TCL_MEM_DEBUG are enabled? I can *almost* but not
quite grasp what's going on... ;^)

Logged In: YES 
user_id=21885

This "fix" that went into 8.4.8 breaks a portion of our
Tcl/AOLserver  build at AOL.

I think this change needs to be backed out, and the build
for Win32  needs to be corrected.

At AOL, we have four different builds: (1) a threaded build
with the zippy allocator; (2) a threaded build without the
zippy allocator; (3) a threaded build with the zippy
allocator and TCL_MEM_DEBUG on; and (4) a threaded build
without the zippy allocator but with TCL_MEM_DEBUG on.

We build these four configurations on Linux and Solaris but
not Win32.

I suspect that the change in ifdef's has probably broken our
builds in other configurations, but configs #3 and #4 above
completely fail to build now.  (Tcl builds, but AOLserver
doesn't.)

Can we revisit this change and discuss backing out the
change and correcting the Win32 build so that it's in line
with the other platform builds?

Logged In: YES 
user_id=75003

Got ok by Don. Committed to 8.4 head.

File Added - 106579: diff

Logged In: YES 
user_id=75003

Kevin created a patch for this, and I fixed the patch. Here
is the combined diff.