Bug #3961 | "make test" hangs on SCO | ||
---|---|---|---|
Submitted: | 2 Jun 2004 8:44 | Modified: | 23 Sep 2004 9:21 |
Reporter: | Patrick Galbraith | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | MySQL Server: Compiling | Severity: | S2 (Serious) |
Version: | 4.1.2 | OS: | Other (SCO_SV osr507 3.2 5.0.7 i386 unk) |
Assigned to: | Marko Mäkelä | CPU Architecture: | Any |
[2 Jun 2004 8:44]
Patrick Galbraith
[8 Jun 2004 14:52]
Sergei Golubchik
mysqld hangs in innobase_init(), in srv_init()
[8 Jun 2004 15:16]
Marko Mäkelä
I can't see anything that has changed in srv_init() for a long time. Where exactly does it hang? Do we have access to a SCO system?
[8 Jun 2004 16:26]
Heikki Tuuri
Hi! Can you please compile with the debug info and post (gdb) bt full from where it hangs or gets into an infinite loop? Maybe the mutex or os_event_t implementation in InnoDB is somehow broken on SCO. Regards, Heikki
[11 Jun 2004 16:28]
Marko Mäkelä
The function pthread_mutex_trylock() seems to always return -1 on SCO, causing mutex_enter_func() to enter an infinite loop in mutex_spin_wait(). Where can I find the documentation of the SCO pthread library?
[11 Jun 2004 17:20]
Heikki Tuuri
Hi! 'Someone' should add to /mysql/configure.in a test if we are compiling on that particular SCO version, and remap in my_pthread.* pthread_mutex_trylock() so that it would behave like the modern Posix standards specify. That is, return 0 on success. Regards, Heikki The relevant code: os0sync.ic: /* NOTE that the MySQL my_pthread.h redefines pthread_mutex_trylock so that it returns 0 on success. In the operating system libraries, HP-UX-10.20 follows the old Posix 1003.4a Draft 4 and returns 1 on success (but MySQL remaps that to 0), while Linux, FreeBSD, Solaris, AIX, Tru64 Unix, HP-UX-11.0 return 0 on success. */ return((ulint) pthread_mutex_trylock(fast_mutex)); /include/my_pthread.h: if defined(HAVE_POSIX1003_4a_MUTEX) && !defined(DONT_REMAP_PTHREAD_FUNCTIONS) #undef pthread_mutex_trylock #define pthread_mutex_trylock(a) my_pthread_mutex_trylock((a)) int my_pthread_mutex_trylock(pthread_mutex_t *mutex); #endif /mysys/my_pthread.c: #ifdef HAVE_POSIX1003_4a_MUTEX /* In HP-UX-10.20 and other old Posix 1003.4a Draft 4 implementations pthread_mutex_trylock returns 1 on success, not 0 like pthread_mutex_lock From the HP-UX-10.20 man page: RETURN VALUES If the function fails, errno may be set to one of the following values: Return | Error | Description _______|__________|_________________________________________ 1 | | Successful completion. 0 | | The mutex is locked; therefore, it was | | not acquired. -1 | [EINVAL] | The value specified by mutex is invalid. */ /* Convert pthread_mutex_trylock to return values according to latest POSIX RETURN VALUES 0 If we are able successfully lock the mutex. EBUSY Mutex was locked by another thread # Other error number returned by pthread_mutex_trylock() (Not likely) */ int my_pthread_mutex_trylock(pthread_mutex_t *mutex) { int error= pthread_mutex_trylock(mutex); if (error == 1) return 0; /* Got lock on mutex */ if (error == 0) /* Someon else is locking mutex */ return EBUSY; if (error == -1) /* Safety if the lib is fixed */ error= errno; /* Probably invalid parameter */ return error; } #endif /* HAVE_POSIX1003_4a_MUTEX */
[23 Sep 2004 9:21]
Marko Mäkelä
Currently, "make test" of mysql-4.1.5 starts properly on osr507.zenez.com. As there should not have been any changes in MySQL/InnoDB code related to this problem, it looks like a bug in the operating system kernel or libraries. Maybe a system upgrade or reboot has made the problem go away?