php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #58820 Segfault at end of execution when using trimImage
Submitted: 2009-08-21 01:55 UTC Modified: 2010-02-28 07:11 UTC
Votes:2
Avg. Score:4.0 ± 1.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: jmy at morgontech dot com Assigned:
Status: No Feedback Package: imagick (PECL)
PHP Version: 5.3.0 OS: CentOS 5.3 / Kernel 2.6.18-128
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: jmy at morgontech dot com
New email:
PHP Version: OS:

 

 [2009-08-21 01:55 UTC] jmy at morgontech dot com
Description:
------------
Using 5.3.0 (Release) (unable to select in dropdown), imagick 2.3.0, and ImageMagick 6.5.4-10 ..

When using Imagick, I seem to be getting a segfault on code cleanup. I've narrowed this down to trimImage() (deduced by multiple executions of the code).

The odd part is that the script -does- run, it specifically segfaults at the very end of the execution of the php process, after all code is complete. It's almost a non-issue, but a segfault's a segfault!

Reproduce code:
---------------
<?php
$im = new Imagick();
$im->readImage('test.png'); // You can use any image here.
$im->trimImage(0);
$im->clear();
$im->destroy();
?>

Expected result:
----------------
Expected result: No error messages

Actual result:
--------------
(relatively brief) strace output, starting with readImage:
read(4, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0\226\0\0\1,\10\6\0\0\0!'J"..., 4096) = 4096
_llseek(4, 0, [0], SEEK_SET)            = 0
mmap2(NULL, 26010, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fa2000
close(4)                                = 0
munmap(0xb7fa9000, 4096)                = 0
time(NULL)                              = 1250833933
mmap2(NULL, 360448, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7cec000
munmap(0xb7fa2000, 26010)               = 0
unlink("/tmp/magick-XX82NVQL")          = 0
unlink("/tmp/magick-XX82NVQL.cache")    = -1 ENOENT (No such file or directory)
unlink("/tmp/magick-XX82NVQL")          = -1 ENOENT (No such file or directory)
getcwd("/home/mgc/card/apps", 4096)     = 20
time(NULL)                              = 1250833933
close(3)                                = 0
munmap(0xb7fac000, 4096)                = 0
mmap2(NULL, 10489856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb72eb000
mprotect(0xb72eb000, 4096, PROT_NONE)   = 0
clone(child_stack=0xb7ceb4a4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb7cebbd8, {entry_number:6, base_addr:0xb7cebb90, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb7cebbd8) = 4626
futex(0x94bd3fc, FUTEX_WAKE_PRIVATE, 2147483647) = 0
times({tms_utime=3, tms_stime=2, tms_cutime=0, tms_cstime=0}) = 636543659
times({tms_utime=3, tms_stime=2, tms_cutime=0, tms_cstime=0}) = 636543659
time(NULL)                              = 1250833933
time(NULL)                              = 1250833933
futex(0x94bd3fc, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x94bdd34, FUTEX_WAKE_PRIVATE, 2147483647) = 0
munmap(0xb7cec000, 360448)              = 0
close(2)                                = 0
close(1)                                = 0
munmap(0xb7faa000, 4096)                = 0
close(0)                                = 0
munmap(0xb7fab000, 4096)                = 0
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
munmap(0xe78000, 2693436)               = 0
munmap(0x5dc000, 116688)                = 0
munmap(0x8df000, 323516)                = 0
munmap(0x338000, 1002884)               = 0
munmap(0x456000, 1596752)               = 0
munmap(0x42d000, 53896)                 = 0
+++ killed by SIGSEGV +++

gdb output:
(gdb) run test.php
Starting program: /usr/bin/php test.php
[Thread debugging using libthread_db enabled]
[New Thread 0xb7f5a6d0 (LWP 4633)]
[New Thread 0xb7c98b90 (LWP 4636)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7c98b90 (LWP 4636)]
0x0048cca2 in ?? ()
(gdb) bt
#0  0x0048cca2 in ?? ()
#1  0x01312d00 in ?? ()
#2  0x08eece74 in ?? ()
#3  0x01312d00 in ?? ()
#4  0x00000004 in ?? ()
#5  0x08eed3fc in ?? ()
#6  0x00490130 in ?? ()
#7  0x08eedd30 in ?? ()
#8  0xffffff7c in ?? ()
#9  0xb7c98378 in ?? ()
#10 0x0048ce00 in ?? ()
#11 0x08eed3f8 in ?? ()
#12 0x00000008 in ?? ()
#13 0xb7c983b8 in ?? ()
#14 0x0048b393 in ?? ()
#15 0x08eed3f8 in ?? ()
#16 0x00000001 in ?? ()
#17 0x00000005 in ?? ()
#18 0xb7c98b0c in ?? ()
#19 0x007792c6 in ?? () from /lib/libpthread.so.0
#20 0x00000000 in ?? ()

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-08-21 08:20 UTC] jmy at morgontech dot com
As an update, I have tried this with PHP 5.2.3 and imagick 2.3.0 and did not have a problem, so it's something specific in imagick's interaction with PHP 5.3
 [2009-08-24 16:08 UTC] mkoppanen@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Hello,

can you try to build a debug version of the PHP and imagick and reproduce the backtrace? The GDB trace looks like it's lacking symbols.
 [2009-08-25 13:28 UTC] jmy at morgontech dot com
Unfortunately I still cannot seem to generate a useful backtrace with symbol information. This is a clean compile of PHP with --enable-debug as outlined by the GDB page you linked. If you have any ideas on further things to try, I would be more than happy to do so.

In running this debug version of PHP, it seems it may be related to a memory leak. Details below:

---

(gdb) run blah.php
Starting program: /usr/bin/php blah.php
[Thread debugging using libthread_db enabled]
[New Thread 0xb7f546d0 (LWP 21713)]
[New Thread 0xb7c92b90 (LWP 21716)]
[Tue Aug 25 13:20:41 2009]  Script:  'blah.php'
/root/source/php-5.3.0/Zend/zend_vm_execute.h(476) :  Freeing 0x0928EFDC (20 bytes), script=blah.php
=== Total 1 memory leaks detected ===

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7c92b90 (LWP 21716)]
0x00480ca2 in ?? ()
(gdb) bt
#0  0x00480ca2 in ?? ()
#1  0x01312d00 in ?? ()
#2  0x09309ff4 in ?? ()
#3  0x01312d00 in ?? ()
#4  0x00000004 in ?? ()
#5  0x0930963c in ?? ()
#6  0x00484130 in ?? ()
#7  0x09309ff0 in ?? ()
#8  0xffffff7c in ?? ()
#9  0xb7c92378 in ?? ()
#10 0x00480e00 in ?? ()
#11 0x09309638 in ?? ()
#12 0x00000008 in ?? ()
#13 0xb7c923b8 in ?? ()
#14 0x0047f393 in ?? ()
#15 0x09309638 in ?? ()
#16 0x00000001 in ?? ()
#17 0x00000005 in ?? ()
#18 0xb7c92b0c in ?? ()
#19 0x007792c6 in ?? () from /lib/libpthread.so.0
#20 0x00000000 in ?? ()
 [2010-01-27 14:41 UTC] mkoppanen@php.net
Not much I can do without a useful backtrace. I am not able to reproduce
 [2010-02-28 07:11 UTC] mkoppanen@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Oct 06 13:01:27 2024 UTC