Jean-Marc Lasgouttes wrote:
> Angus> Jeremy, you're absolutely right. We're attempting to fix one
> Angus> bug by introducing another.
>
> Angus> Jean-Marc, let's go back to the old behaviour ("Mutex destroy
> Angus> failure: Device or resource busy" on exit on some machines
> but Angus> not other
Jean-Marc Lasgouttes wrote:
> Angus> Jeremy, you're absolutely right. We're attempting to fix one
> Angus> bug by introducing another.
>
> Angus> Jean-Marc, let's go back to the old behaviour ("Mutex destroy
> Angus> failure: Device or resource busy" on exit on some machines
> but Angus> not other
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jeremy, you're absolutely right. We're attempting to fix one
Angus> bug by introducing another.
Angus> Jean-Marc, let's go back to the old behaviour ("Mutex destroy
Angus> failure: Device or resource busy" on exit on some machines
On Wed, 12 Oct 2005, Jeremy C. Reed wrote:
> On Wed, 21 Sep 2005, Angus Leeming wrote:
>
>> Anyway, trying to unlock a mutex that is already unlocked will
>> result in undefined behaviour when using POSIX threads. See, for
>> example Section 3.3.2 "Locking and unlocking a mutex" of
>> "Programming
On Wed, 21 Sep 2005, Angus Leeming wrote:
Anyway, trying to unlock a mutex that is already unlocked will result in
undefined behaviour when using POSIX threads. See, for example Section 3.3.2
"Locking and unlocking a mutex" of "Programming with POSIX threads" by David
R Butenhof.
So, I'm not go
Jeremy C. Reed wrote:
>> You mean that the call to locked() resulted in a SIGSEGV? My
>> misunderstanding; I assumed that the crash was happening in unlock().
>
> No crash in locked(). And unlock() is never used. (But when I did force
> it to always unlock() it appeared to exit fine.)
>
> This i
You mean that the call to locked() resulted in a SIGSEGV? My
misunderstanding; I assumed that the crash was happening in unlock().
No crash in locked(). And unlock() is never used. (But when I did force it
to always unlock() it appeared to exit fine.)
This is what I have when I run it and imm
On Wednesday 21 September 2005 21:32, Jeremy C. Reed wrote:
> On Sep. 21, leeming wrote:
> > However, the implementation of these functions (for Qt 3.3.4) suggests
> > that we should perhaps be calling "unlock(false)". Can you see if that
> > makes any difference?
> I am not sure what you mean. It
On Sep. 21, leeming wrote:
However, the implementation of these functions (for Qt 3.3.4) suggests
that we should perhaps be calling "unlock(false)". Can you see if that
makes any difference?
I am not sure what you mean. It never got to the unlock() for me in the
first place. I had to remove
Jeremy C. Reed wrote:
>>> NetBSD 2.0.2 running lyx built with qt errored at exit with:
>>> lyx: Error detected by libpthread: Destroying locked mutex.
>>> Detected by file
>
>> I've always hated this myself, although at least on linux it
>> doesn't result in a core dump.
>>
>> Anyway, I went diggi
On Mon, 11 Jul 2005, Angus Leeming wrote:
NetBSD 2.0.2 running lyx built with qt errored at exit with:
lyx: Error detected by libpthread: Destroying locked mutex.
Detected by file
I've always hated this myself, although at least on linux it doesn't
result in a core dump.
Anyway, I went digg
Angus Leeming wrote:
> Applying the attached hack cures the problem here.
> Hrrry!
Probably safer to have:
LQApplication::~LQApplication()
-{}
+{
+#ifdef QT_THREAD_SUPPORT
+ if (locked())
+ unlock();
+#endif
+}
--
Angus
Jeremy C. Reed wrote:
> NetBSD 2.0.2 running lyx built with qt errored at exit with:
>
> lyx: Error detected by libpthread: Destroying locked mutex.
> Detected by file
>
"/home/builds/ab/netbsd-2-0-2-RELEASE/src/lib/libpthread/pthread_mutex.c",
> line 135, function "pthread_mutex_destroy".
> See
13 matches
Mail list logo
