Kristof Bastiaensen <kristof@vleeuwen.org> writes:
> At Thu, 29 Dec 2005 07:55:44 +0100,
> Michael Sperber wrote:
>>
>>
>> Kristof Bastiaensen <kristof@vleeuwen.org> writes:
>>
>> > #0 0x41527124 in __pthread_sigsuspend () from /lib/libpthread.so.0
>> > #1 0x41525f29 in __pthread_wait_for_restart_signal () from
>> > /lib/libpthread.so.0
>> > #2 0x41526c89 in pthread_create@@GLIBC_2.1 () from /lib/libpthread.so.0
>> > #3 0x414f207c in sqlite3OsTempFileName () from /usr/lib/libsqlite3.so.0
>>
>> So it *is* stuck somewhere deep in the bowels of sqlite. Can you
>> reproduce the problem with an sqlite compiled with -g and get the line
>> number where it's stuck in sqlite3OsTempFileName? I'm a bit mystified
>> that it should be domething with threads---the definition I see in
>> sqlite 3.2.8 doesn't seem to do that directly.
>>
>
> So am I. I found that configuring sqlite3 with --disable-threadsafe
> will make the problem disappear. I don't understand however why it
> works with scheme48 but not with scsh, since both don't use threads.
> Perhaps this is a bug in sqlite3?
I'd rather suspect something in the OS thread system itself---the
place where it's stuck in sqlite3 looks rather innocuous, but seems to
exercise a feature of POSIX threads I've rarely seen used.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
|