Rick,
these code excerpts may explain the problem:
/***********************************************************************
Returns the local storage struct for a thread. */
static
thr_local_t*
thr_local_get(
/*==========*/
/* out: local storage */
os_thread_id_t id) /* in: thread id of the thread */
{
thr_local_t* local;
try_again:
ut_ad(thr_local_hash);
ut_ad(mutex_own(&thr_local_mutex));
/* Look for the local struct in the hash table */
local = NULL;
HASH_SEARCH(hash, thr_local_hash, os_thread_conv_id_to_ulint(id),
local, local->id == id);
if (local == NULL) {
mutex_exit(&thr_local_mutex);
thr_local_create();
mutex_enter(&thr_local_mutex);
goto try_again;
}
ut_ad(local->magic_n == THR_LOCAL_MAGIC_N);
return(local);
}
/***********************************************************************
Creates a local storage struct for the calling new thread. */
void
thr_local_create(void)
/*==================*/
{
thr_local_t* local;
if (thr_local_hash == NULL) {
thr_local_init();
}
local = mem_alloc(sizeof(thr_local_t));
local->id = os_thread_get_curr_id();
local->handle = os_thread_get_curr();
local->magic_n = THR_LOCAL_MAGIC_N;
local->in_ibuf = FALSE;
mutex_enter(&thr_local_mutex);
HASH_INSERT(thr_local_t, hash, thr_local_hash,
os_thread_conv_id_to_ulint(os_thread_get_curr_id()),
local);
mutex_exit(&thr_local_mutex);
}
/*********************************************************************
Returns the thread identifier of current thread. */
os_thread_id_t
os_thread_get_curr_id(void)
/*=======================*/
{
#ifdef __WIN__
return(GetCurrentThreadId());
#else
pthread_t pthr;
pthr = pthread_self();
/* TODO: in the future we have to change os_thread_id
to pthread_t; the following cast may work in a wrong way on some
systems if pthread_t is a struct; this is just a quick fix
for HP-UX to eliminate a compiler warning */
return(*(os_thread_id_t*)((void*) (&pthr)));
#endif
}
If pthread_t is a struct where the first field does NOT determine the thread
uniquely, then our hash table will be confused. The above definition code
assumes pthread_t is either a pointer, or a struct where the first field
determines the thread uniquely.
Fix: os_thread_id_t is now an unsigned long int. Change it to a struct.
Compare these structs with the comparison functions provided in the pthreads
standard Posix functions, I think there are appropriate functions in it to
determine if two variables of type pthread_t represent the same thread.
Check also that the unsigned long int representation is not used anywhere to
determine the identity of pthread_t.
For example, in the code:
HASH_SEARCH(hash, thr_local_hash, os_thread_conv_id_to_ulint(id),
local, local->id == id);
the comparison local->id == id should be replaced with someting like
pthreads_are_identical(local->id, id).
This has to be changed in the InnoDB code some time. I cannot promise a date
yet. Thank you for bringing this up!
Best regards,
Heikki Tuuri
Innobase Oy
---
Order technical MySQL/InnoDB support at https://order.mysql.com/
See http://www.innodb.com for the online manual and latest news on InnoDB
----- Original Message -----
From: "Rick Flower" <[EMAIL PROTECTED]>
To: "MySQL Mailing List" <[EMAIL PROTECTED]>
Cc: "Heikki Tuuri" <[EMAIL PROTECTED]>
Sent: Friday, July 19, 2002 12:58 AM
Subject: Re: Innodb startup hangs on AIX 4.3.3 when built with IBM's
VisualAge C/C++ compiler 5.0.x
> [ MySQL ]
>
> Here's some additional data now that I've rebuilt using "--enable-debug"
or
> whatever the configure option is.
>
> Here's what GDB is claiming is happening after it ran for about 2 minutes
> (after initial startup when NO files needed to be created)
>
> (gdb) where
> #0 thr_local_get (id=60) at thr0loc.c:75
> #1 0x1022f98c in thr_local_get_in_ibuf_field () at thr0loc.c:145
> #2 0x101c1b74 in ibuf_inside () at ibuf0ibuf.c:223
> #3 0x101bc59c in fil_io (type=537082596, sync=271108496,
> space_id=804396760, block_offset=804396764, byte_offset=804396784,
> len=804396776, buf=0x2ff21ed4,
> message=0xdeadbeef) at fil0fil.c:1105
> #4 0x1020609c in trx_sys_doublewrite_restore_corrupt_pages () at
> trx0sys.c:281
> #5 0x10189180 in innobase_start_or_create_for_mysql () at
srv0start.c:1093
> #6 0x10181e4c in innobase_init () at ha_innobase.cc:463
> #7 0x1001350c in ha_init () at handler.cc:161
> #8 0x10051120 in main (argc=21, argv=0x20052a70) at mysqld.cc:1899
> #9 0x10000204 in __start ()
> (gdb)
>
>
> It appears to be running in a loop as can be seen below.. I found a
comment
> indicating something about it possibly running out of file handles, and
> have included a LSOF output for this process as well :
>
> % lsof -p22014
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
> mysqld 22014 mysql cwd VDIR 43,4 512 262153 /test2
> (/dev/test2lv)
> mysqld 22014 mysql 0u VCHR 38,7 0t2353 168294 /dev/pts/7
> mysqld 22014 mysql 1w VREG 43,4 792 262156 /test2
> (/dev/test2lv)
> mysqld 22014 mysql 2w VREG 43,4 792 262156 /test2
> (/dev/test2lv)
> mysqld 22014 mysql 3u IPv4 0x7028e2dc 0t0 TCP *:3306 (LISTEN)
> mysqld 22014 mysql 4u unix 10,7 0t0 70 /tmp/mysql.sock
>
>
> 75 in thr0loc.c
> (gdb)
> 77 in thr0loc.c
> (gdb)
> 79 in thr0loc.c
> (gdb)
> 72 in thr0loc.c
> (gdb)
> 81 in thr0loc.c
> (gdb)
> 74 in thr0loc.c
> (gdb)
> 75 in thr0loc.c
> (gdb)
> 77 in thr0loc.c
> (gdb)
> 79 in thr0loc.c
> (gdb)
> 72 in thr0loc.c
> (gdb)
> 81 in thr0loc.c
> (gdb)
> 74 in thr0loc.c
> (gdb)
> 75 in thr0loc.c
> (gdb)
> 77 in thr0loc.c
> (gdb)
> 79 in thr0loc.c
> (gdb)
> 72 in thr0loc.c
> (gdb)
> 81 in thr0loc.c
> (gdb)
> 74 in thr0loc.c
> (gdb)
> 75 in thr0loc.c
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
