On Wed, 14 Sep 2016, László Böszörményi wrote:
As Perl debug and libc6 debug symbols installed, I don't know which
library / executable may contain points #0 and #1. Maybe log.c itself?
At least the mentioned line in #2 is:
LockSemaphoreInfo(log_semaphore);
There were no functions added or removed between 1.3.24 and 1.3.25 and not
interfaces were changed. If 1.3.24 still builds on the build machine, then
it is possible to test by replacing individual source files in 1.3.25 with
files from 1.3.24 and seeing when the problem goes away. Since all tests
are failing, the problematic code would need to be used in initialization,
or somehow always encountered. Perhaps magick/utility.c would be a good
starting point.
Yes, 1.3.24 builds fine in the same environment. As previously noted
the broken change happened before 08th of August and it's not the
MAGICK_CACHE_LINE_SIZE value.
It seems that "semaphores" (pthread mutex locks or OpenMP locks
depending on configuration, but should be pthread mutex locks in this
configuration) are not working in the context of Perl/PerlMagick.
The crash occurs very early in initialization. The crash is under the
initial InitializeMagick() and when the first "semaphore" is locked.
The log.c file was changed prior to the 1.3.24 release and semaphore.c
has not changed since 2014.
I don't see any GraphicsMagick source code which has changed up to the
point of the crash. The only thing which changed in PerlMagick itself
was the version string.
There is something suspect about the stack:
Thread 1 (Thread 0x3fffb7ff65b0 (LWP 3923)):
#0 0x00000000000bffc8 in ?? ()
#1 0x00000000000bffcb in ?? ()
#2 0x00003fffb796b320 in InitializeLogInfo () at magick/log.c:301
#3 0x00003fffb796c62c in InitializeMagick (path=0x3fffb7bf0708
"Graphics::Magick") at magick/magick.c:1117
#4 0x00003fffb7bf0074 in boot_Graphics__Magick (my_perl=0x10210010,
cv=<optimized out>) at Magick.xs:2064
What seems suspect is that I would expect that #1 would be a decoded
LockSemaphoreInfo() call and #0 would be a pthread_mutex_lock() call.
These are in the same library so they should be decoded by the
debugger equally well. Probably pthread_mutex_lock() is also a
function so there should be at least one more level of function calls
on the stack. It is as if the call went to a different library.
It may be necessary to prove where the problem is occuring by manually
overwriting updated files in the magick directory with those from the
previous working version until the problem goes away (assuming that it
does).
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
