RE: thread problem

It seems like the best approach would be to setup a test to verify the issue
outside of the core. I thought that Cristy did that and dod not find any
problems.

-----Original Message-----
From: Bob Friesenhahn [mailto:[email protected]] 
Sent: Thursday, May 01, 2003 4:12 PM
To: [email protected]
Subject: Re: [GM-core] thread problem

This is good spelunking.  I suspect that the problem comes from the
fact that "DestroySemaphoreInfo" does an "UnlockSemaphoreInfo" for
before releasing its memory.  Certainly if the lock is held by another
thread, the semaphore should not be unlocked by a different thread,
and it should certainly not have its memory released if another thread
is still using it.

The code will always "unlock" the lock, even if it is not locked at
all. This may be the problem which is being flagged.  This would be
similar to a "double free" in the memory allocation sense.

The design of the semaphore code is heavily influenced by the
interface and limitations of semaphores (critical sections) under
Windows.  Apparently Windows doesn't support static locks or anonymous
locks in memory like POSIX does.

Bob

On Thu, 1 May 2003, Patrick Welche wrote:

> NetBSD now as a debugging libpthread, which shows up the following:
>
> Error detected, file "/usr/src/lib/libpthread/pthread_mutex.c", line
> 338, function "pthread_mutex_unlock": Unlocking mutex owned by
> another thread.
>
> Normally the program should then dump core like the debugging malloc(),
but
> for some reason it doesn't.. ImageMagick, does leave a core behind, which
> may give some clues? (both with display)
>
> #0  0x485e4817 in kill () from /usr/lib/libc.so.12
> #1  0x485ac149 in pthread__errorfunc () from /usr/lib/libpthread.so.0
> #2  0x485a902f in pthread_mutex_unlock () from /usr/lib/libpthread.so.0
> #3  0x480ed2e1 in UnlockSemaphoreInfo (semaphore_info=0x808be00)
>     at semaphore.c:425
> #4  0x480ed0f9 in DestroySemaphoreInfo (semaphore_info=0x809b078)
>     at semaphore.c:265
> #5  0x48087396 in DestroyCacheInfo (cache=0x809a000) at cache.c:957
> #6  0x48087602 in DestroyPixelCache (image=0x8098000) at cache.c:1073
> #7  0x4808757b in DestroyImagePixels (image=0x8098000) at cache.c:1041
> #8  0x480a2bea in DestroyImage (image=0x8098000) at image.c:1896
> #9  0x480ab08e in SetImageInfo (image_info=0x8093000, rectify=0,
>     exception=0xbfbff9a8) at image.c:5810
> #10 0x4809de61 in ReadImage (image_info=0x808d000, exception=0xbfbff9a8)
>     at constitute.c:2616
> #11 0x8049fae in main (argc=2, argv=0x805b000) at display.c:437
> #12 0x8049464 in ___start ()
>
> Looking at semaphore.c, I don't see why there is a
> static pthread_mutex_t semaphore_mutex
> and then things pass SemaphoreInfo->mutex around.
>
> So, what are these mutices used for, and would ditching the static one
> and seeing what breaks be a sensible way to find out why one thread is
> unlocking another thread's mutex?
>
> Cheers,
>
> Patrick
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Graphicsmagick-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/graphicsmagick-core
>

======================================
Bob Friesenhahn
[email protected]
http://www.simplesystems.org/users/bfriesen



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Graphicsmagick-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-core


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf