Bug 683596

Summary: [abrt] ImageMagick-6.5.8.10-7.fc13: memcpy: Process /usr/bin/convert was killed by signal 7 (SIGBUS)
Product: [Fedora] Fedora Reporter: Joe Robinson <joe_underscore>
Component: ImageMagickAssignee: Pavel Alexeev <pahan>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 13CC: joe_underscore, nmurray, pahan
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Unspecified   
Whiteboard: abrt_hash:31da50d77164f86a7980f4caef0a96c0870f97de
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-17 13:04:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: backtrace none

Description Joe Robinson 2011-03-09 19:44:18 UTC
abrt version: 1.1.14
architecture: i686
Attached file: backtrace
cmdline: convert /home/whacker/west-side-picture.jpg -resize 1024x768 /var/www/html/webcam/view-from-1002.jpg
component: ImageMagick
crash_function: memcpy
executable: /usr/bin/convert
kernel: 2.6.34.8-68.fc13.i686.PAE
package: ImageMagick-6.5.8.10-7.fc13
rating: 3
reason: Process /usr/bin/convert was killed by signal 7 (SIGBUS)
release: Fedora release 13 (Goddard)
time: 1299699061
uid: 500

comment
-----
This setup was operating w/o errors until yesterday (08 Mar 2011) when I accepted a large system update which included some kernel PAE and other stuff (which I do not recall).
Since then there have been sporadic errors.
Speculation: could the "updated" system memory-handling now be less tolerant of 'camstreams' writing to /home/whacker/west-side-picture.jpg every 30 seconds, and 'cron' running 'convert' every 60 seconds?

How to reproduce
-----
1. "camstreams" is running, saving an image from a USB webcam to file /home/whacker/west-side-picture.jpg every 30 seconds

2. crontab line in "* * * * * /home/whacker/IP-Update/webcam-image-refresh.sh %"

3. webcam-image-refresh.sh is as follows:
=================
#!/bin/sh

cp /home/whacker/west-side-picture.* /var/www/html/Barclay/Residents/webcam/
convert /home/whacker/west-side-picture.jpg -resize 1024x768  /var/www/html/webcam/view-from-1002.jpg

exit
==================

Comment 1 Joe Robinson 2011-03-09 19:44:21 UTC
Created attachment 483291 [details]
File: backtrace

Comment 2 Pavel Alexeev 2011-03-09 20:22:39 UTC
Firstly thank you for the bugreport.

Please provide image to reproduce crash. and then please test version from rawhide.

Comment 3 Joe Robinson 2011-03-09 22:35:46 UTC
(In reply to comment #2)
> Firstly thank you for the bugreport.
> 
> Please provide image to reproduce crash. and then please test version from
> rawhide.

I'm unsure of how to comply with the request - i.e. do I attempt to provide/upload an example of the file /home/whacker/west-side-picture.jpg ? ... And I don't know what "Test version from Rawhide" means. Sorry. Not a total newbie, but "whacker" is uneducated "wildly hacking"!

Notwithstanding the above, I have modified my script to read (adding "sleep 5" between operations) ...
===============
#!/bin/sh
# camstream dumps a snapshot into /home/whacker
# this script copies the full-size image to the "residents only" area of the web-site, and then
# 'convert' is invoked to produce a smaller image for casual viewers in /var/www/html/webcam/

cp /home/whacker/west-side-picture.* /var/www/html/Barclay/Residents/webcam/
sleep 5
convert /home/whacker/west-side-picture.jpg -resize 1024x768  /var/www/html/webcam/view-from-1002.jpg

exit
===============

... in case there was now a "race" condition contributed by yesterday's massive 210MB update, and I have not seen another 'abrt' "red-light" to this moment.

HTH.

Comment 4 Pavel Alexeev 2011-03-10 06:10:35 UTC
Yes, firstly provide image on what I (and upstream developer) can see it crash, just attach it here. I hope it is not secret photo.

Secondly I speak about version of IM from rawhide. If you use it not on production server and can do some examples, do something similar:
su -c 'yum --enablerepo=rawhide update "ImageMagick*"'
Be careful - rawhide is development tree and many application, including IM may be unstable there.

Indeed only test image for reproduce is required.

Comment 5 Joe Robinson 2011-03-20 21:30:52 UTC
My apologies. Please excuse my unfamiliarity with the process, and frustration with not seeing how to send an attachment. You will have received the  two *.jpg images via the email.

========================================
Please continue answer in bugzilla instead of mail!!

And please try provide step-by-step reproduce for problem. I can't debug something until I can't see problem on my machine.

19.03.2011 17:46, Joe Robinson пишет:
> This may not be of much use to you, however this morning I noticed another "red light" announcing another crash (#76) which had occurred at 07:26:06 AM Sat 19 Mar 2011.
> To me the significant facts are
>
>    * there have been further abrts, despite the 'sleep 5' measure;
>    * the hard-drives are assumed to be OK because the raid1 status are
>      all [3/3] [UUU];
>    * the abrt count has advanced from 41 to 76 w/o any disruption to
>      other system users.
>
> Oops - there has just been another abrt (Crash Count: 77) at 09:40:06 AM.
>
> I will report any further developments, whether I understand them or not!
>
> Joe
>
> Pahan-Hubbitus wrote:
>> Hello, Joe.
>>
>> Sorry for late answer.
>>
>> If I right understand, IM is not target of main interest in this case.
>> Do toy have checked memory and hard drives? Can you reproduce error on sequent call convert manually or in small reproduce script?
>>
>> Why you answer me by mail rather than continue dialog in bugzilla?
>>
>> 10.03.2011 18:42, Joe Robinson пишет:
>>> Greetings Pavel:
>>>
>>> This is a "production machine" so I will restrict my adventures to the software provided via Fedora-13.
>>>
>>> There were 39 'abrt' occurrences for 'convert' after the Fedora-13 "update" I implemented 08 March, until I revised the bash script "webcam-image-refresh.sh" last night (adding the "sleep 5" line).
>>>
>>> There were no further 'abrt' occurrences overnight.
>>>
>>> When I commented out the "sleep 5" line this morning, there were then two (2) more 'abrt' occurrences, widely separated in time. I have re-activated the "sleep 5" line (perhaps five seconds is overkill but it works).
>>>
>>> I grabbed a copy of the full-size image and 'convert'ed file as quickly as possible (when I saw the Automatic Bug Reporting tool "red light" appear for 'abrt' #41), and they are attached. I see no imperfection in the converted image this time, only once yesterday seeing that the lower portion of the image was just a flat grey colour.
>>>
>>> In case it helps, I have also attached the 'dmesg' output for the machine.
>>>
>>> My conclusion is that ImageMagick should not be blamed for "the problem", but perhaps the new kernel's memory management (including RAID).
>>>
>>> Please advise whether I should amend my Bugzilla posting to say "solved" by my 'sleep 5' kludge.
>>>
>>> Best wishes, and thank you for your prompt attention to my Bugzilla posting.
>>>
>>> Joe
>>>
>>> On 03/10/2011 01:10 AM, bugzilla wrote:
>>>> Please do not reply directly to this email. All additional
>>>> comments should be made in the comments box of this bug.
>>>>
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=683596
>>>>
>>>> Pavel Alexeev (aka Pahan-Hubbitus)<pahan>  changed:
>>>>
>>>>             What    |Removed                     |Added
>>>> ----------------------------------------------------------------------------
>>>>               Status|NEW                         |ASSIGNED
>>>>
>>>> --- Comment #4 from Pavel Alexeev (aka Pahan-Hubbitus)<pahan>  2011-03-10 01:10:35 EST ---
>>>> Yes, firstly provide image on what I (and upstream developer) can see it crash,
>>>> just attach it here. I hope it is not secret photo.
>>>>
>>>> Secondly I speak about version of IM from rawhide. If you use it not on
>>>> production server and can do some examples, do something similar:
>>>> su -c 'yum --enablerepo=rawhide update "ImageMagick*"'
>>>> Be careful - rawhide is development tree and many application, including IM may
>>>> be unstable there.
>>>>
>>>> Indeed only test image for reproduce is required.
>>>>

=============================================
--- end of forward

Comment 6 Pavel Alexeev 2011-03-22 20:40:19 UTC
Please try this build http://koji.fedoraproject.org/koji/taskinfo?taskID=2933661

Comment 7 Joe Robinson 2011-04-08 01:07:07 UTC
Trying that build is beyond my capabilities - I'll stick with what fc13 updates offer me.

I thought that removing a failing HDD from my RAID1 array yesterday (06 April) would solve my problem but it hasn't gone away ...


Apr  7 19:58:07 fireball abrt[3253]: saved core dump of pid 3252 (/usr/bin/convert) to /var/spool/abrt/ccpp-1302220686-3252.new/coredump (16584704 bytes)
Apr  7 19:58:07 fireball abrtd: Directory 'ccpp-1302220686-3252' creation detected
Apr  7 19:58:07 fireball abrtd: Crash is in database already (dup of /var/spool/abrt/ccpp-1299683761-7151) and is reported
Apr  7 19:58:07 fireball abrtd: Deleting crash ccpp-1302220686-3252 (dup of ccpp-1299683761-7151), sending dbus signal
Apr  7 19:58:22 fireball abrtd: Getting crash infos...
Apr  7 20:09:07 fireball abrt[3759]: saved core dump of pid 3758 (/usr/bin/convert) to /var/spool/abrt/ccpp-1302221346-3758.new/coredump (16584704 bytes)
Apr  7 20:09:07 fireball abrtd: Directory 'ccpp-1302221346-3758' creation detected
Apr  7 20:09:07 fireball abrtd: Crash is in database already (dup of /var/spool/abrt/ccpp-1299683761-7151) and is reported
Apr  7 20:09:07 fireball abrtd: Deleting crash ccpp-1302221346-3758 (dup of ccpp-1299683761-7151), sending dbus signal
Apr  7 20:43:07 fireball abrt[5143]: saved core dump of pid 5142 (/usr/bin/convert) to /var/spool/abrt/ccpp-1302223386-5142.new/coredump (16584704 bytes)
Apr  7 20:43:07 fireball abrtd: Directory 'ccpp-1302223386-5142' creation detected
Apr  7 20:43:07 fireball abrtd: Crash is in database already (dup of /var/spool/abrt/ccpp-1299683761-7151) and is reported
Apr  7 20:43:07 fireball abrtd: Deleting crash ccpp-1302223386-5142 (dup of ccpp-1299683761-7151), sending dbus signal

--- end of 'tail -f /var/log/messages' extract ---

Comment 8 Pavel Alexeev 2011-04-08 10:07:13 UTC
For Fedora 13 try this scratch build - http://koji.fedoraproject.org/koji/taskinfo?taskID=2983590

Comment 9 Joe Robinson 2011-04-08 13:27:52 UTC
Apologies if I'm being a PITA. I clicked on that link but am at an impasse. I'm like the dog who chases cars, catches one, but doesn't know what to do with it.
Perhaps there's another repository I should have selected such that 'System -> Administration -> Add/Remove Software' would offer me the "scratch build" you refer to?
Confused, fearful of fscking his system, but trying to be more than an Appliance Operator ...

Comment 11 Joe Robinson 2011-04-08 17:32:05 UTC
I did ...
""
[root@fireball whacker]# rpm -Uhv http://koji.fedoraproject.org/koji/getfile?taskID=2983592&name=ImageMagick-6.6.8.4-1.fc13.i686.rpm
[1] 14361
[root@fireball whacker]# Retrieving http://koji.fedoraproject.org/koji/getfile?taskID=2983592
curl: (22) The requested URL returned error: 500
error: skipping http://koji.fedoraproject.org/koji/getfile?taskID=2983592 - transfer failed

[1]+  Exit 1                  rpm -Uhv http://koji.fedoraproject.org/koji/getfile?taskID=2983592
[root@fireball whacker]# 
""
Why did it fail? (Same result with su -c 'rpm etc)

---------------
Could this also be involved?
Bug 451610 - nspluginwrapper segfaults (in npviewer.bin) 

- from /var/log/messages

Apr  8 10:54:25 fireball kernel: npviewer.bin[8248]: segfault at 0 ip 011c58d1 sp bfd66aa0 error 4 in libflashplayer.so[dfd000+b5f000]
Apr  8 10:54:26 fireball abrt[8467]: saved core dump of pid 8248 (/usr/lib/nspluginwrapper/npviewer.bin) to /var/spool/abrt/ccpp-1302274465-8248.new/coredump (43409408 bytes)
Apr  8 10:54:26 fireball abrtd: Directory 'ccpp-1302274465-8248' creation detected
Apr  8 10:54:26 fireball abrtd: Blacklisted package 'nspluginwrapper'
Apr  8 10:54:26 fireball abrtd: Corrupted or bad crash /var/spool/abrt/ccpp-1302274465-8248 (res:2), deleting
Apr  8 10:59:12 fireball kernel: npviewer.bin[8471]: segfault at b758a0ac ip 011c58e7 sp bfdc6e90 error 4 in libflashplayer.so[dfd000+b5f000]
Apr  8 10:59:13 fireball abrt[8722]: saved core dump of pid 8471 (/usr/lib/nspluginwrapper/npviewer.bin) to /var/spool/abrt/ccpp-1302274752-8471.new/coredump (109735936 bytes)
Apr  8 10:59:13 fireball abrtd: Directory 'ccpp-1302274752-8471' creation detected
Apr  8 10:59:13 fireball abrtd: Blacklisted package 'nspluginwrapper'
Apr  8 10:59:13 fireball abrtd: Corrupted or bad crash /var/spool/abrt/ccpp-1302274752-8471 (res:2), deleting
Apr  8 11:05:27 fireball pulseaudio[7834]: ratelimit.c: 595 events suppressed
Apr  8 11:11:21 fireball pulseaudio[7834]: ratelimit.c: 596 events suppressed
Apr  8 11:12:17 fireball kernel: npviewer.bin[8728]: segfault at b55140ac ip 011c58e7 sp bfe74bc0 error 4 in libflashplayer.so[dfd000+b5f000]
Apr  8 11:12:18 fireball abrt[9466]: saved core dump of pid 8728 (/usr/lib/nspluginwrapper/npviewer.bin) to /var/spool/abrt/ccpp-1302275537-8728.new/coredump (109666304 bytes)
Apr  8 11:12:18 fireball abrtd: Directory 'ccpp-1302275537-8728' creation detected
Apr  8 11:12:18 fireball abrtd: Blacklisted package 'nspluginwrapper'
Apr  8 11:12:18 fireball abrtd: Corrupted or bad crash /var/spool/abrt/ccpp-1302275537-8728 (res:2), deleting
Apr  8 13:15:21 fireball abrtd: Getting crash infos...

Comment 12 Pavel Alexeev 2011-04-08 17:37:32 UTC
You forgot quotes.

Comment 13 Joe Robinson 2011-04-08 17:46:37 UTC
Downloaded the file (ImageMagick-6.6.8.4-1.fc13.i686.rpm) but using Package Installer I receive an error pop-up:

""
could not do simulate: zbar-0.10-2.fc13.i686 requires libMagickCore.so.2
zbar-0.10-2.fc13.i686 requires libMagickWand.so.2
""

Comment 14 Joe Robinson 2011-04-08 18:17:04 UTC
[whacker@fireball ~]$ su -c 'rpm -Uhv "http://koji.fedoraproject.org/koji/getfile?taskID=2983592&name=ImageMagick-6.6.8.4-1.fc13.i686.rpm"'
Password: 
Retrieving http://koji.fedoraproject.org/koji/getfile?taskID=2983592&name=ImageMagick-6.6.8.4-1.fc13.i686.rpm
error: Failed dependencies:
	libMagickCore.so.2 is needed by (installed) zbar-0.10-2.fc13.i686
	libMagickWand.so.2 is needed by (installed) zbar-0.10-2.fc13.i686
[whacker@fireball ~]$ 

Sorry about the quotes. Sloppy of me.
Now, those libMagick*.so.2 ?

Comment 15 Pavel Alexeev 2011-04-09 08:50:58 UTC
Do you used zbar? Can it be deleted? At least temporary for the experiment.

Comment 16 Joe Robinson 2011-04-09 11:40:35 UTC
zbar removed. Now I need a replacement for totem ...


Apr  9 07:35:28 fireball yum[25915]: Erased: totem
Apr  9 07:35:36 fireball yum[25915]: Erased: gnome-dvb-daemon
Apr  9 07:35:39 fireball yum[25915]: Erased: gstreamer-plugins-bad-free
Apr  9 07:35:42 fireball yum[25915]: Erased: zbar

To reinstall totem would reinstall zbar! WTF?

Comment 17 Pavel Alexeev 2011-04-09 12:07:19 UTC
Near Fedora 15 release. Do you plan update at least to Fedora 14?

Comment 18 Joe Robinson 2011-04-09 15:05:09 UTC
Trying su -c 'yum install totem' instead of the GUI was no help in restoring only totem:
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package totem.i686 0:2.30.2-1.fc13 set to be installed
--> Processing Dependency: gstreamer-plugins-bad-free >= 0.10.17 for package: totem-2.30.2-1.fc13.i686
--> Processing Dependency: gnome-dvb-daemon for package: totem-2.30.2-1.fc13.i686
--> Running transaction check
---> Package gnome-dvb-daemon.i686 0:0.1.19-2.fc13 set to be installed
---> Package gstreamer-plugins-bad-free.i686 0:0.10.20-1.fc13 set to be installed
--> Processing Dependency: libzbar.so.0 for package: gstreamer-plugins-bad-free-0.10.20-1.fc13.i686
--> Running transaction check
---> Package zbar.i686 0:0.10-2.fc13 set to be installed
--> Finished Dependency Resolution

OK.

My "plan" is to update at "the last minute", probably to Fedora 14. Meantime, I'll leave the zbar crowd uninstalled for a week (going out of town).
After that, if I cannot live w/o totem, I'll take my chances and reinstall it.

Thank you for your patience, and assistance with my education.

Comment 19 Pavel Alexeev 2011-04-10 08:41:27 UTC
If you try install totem instead of delete do it meant you install new ImageMagick? Does it work as expected?

Comment 20 Joe Robinson 2011-04-15 18:15:17 UTC
With totem/zbar etc uninstalled, the last 'convert' crash was on 07 April.

That was with ImageMagick-6.5.8.10-7.fc13.i686

ImageMagick-6.6.8.4-1.fc13.i686 installed today.

Cannot install 'totem' via "Add/Remove Software" or 'yum'

Also tried:  su -c 'yum install --skip-broken totem'
...
Packages skipped because of dependency problems:
    gnome-dvb-daemon-0.1.19-2.fc13.i686 from updates
    gstreamer-plugins-bad-free-0.10.18-2.fc13.i686 from fedora
    gstreamer-plugins-bad-free-0.10.20-1.fc13.i686 from updates
    totem-2.30.2-1.fc13.i686 from updates
    zbar-0.10-2.fc13.i686 from fedora

So ImageMagick-6.6.8.4-1.fc13.i686 creates dependency problems for 'totem'?
------------------------------------
Current state:

su -c 'rpm -e ImageMagick'

- ImageMagick-6.5.8.10-7.fc13.i686 installed via "Add/Remove Software"
- totem etc installed via "Add/Remove Software"
- awaiting further results

Comment 21 Pavel Alexeev 2011-04-17 13:04:56 UTC
So, by them you confirm what problem solved in new version?

Thank you for the assistance and help. Now I can close bug.

Comment 22 Joe Robinson 2011-05-19 17:39:05 UTC
It hasn't gone away but it does not appear to be serious.
The 'bug' perhaps interferes with one file-conversion/saving operation in ... over forty-thousand?
I.e. the operation is performed every minute, and this recurrence today is the first in over 30 days.
I'm still running F13, and probably will try F14 one-day-soon.

Comment 23 Pavel Alexeev 2011-05-29 16:54:01 UTC
You say problem gone in new tested version. Or I incorrectly understand you?

Comment 24 Joe Robinson 2011-05-29 18:05:16 UTC
I recently upgraded to Fedora 14, and yesterday had a spurt of crashes which I reported under https://bugzilla.redhat.com/show_bug.cgi?id=708562

I've seen no crashes today.

I'm running Linux fireball.barclay 2.6.35.13-91.fc14.i686.PAE #1 SMP Tue May 3 13:29:55 UTC 2011 i686 i686 i386 GNU/Linux on ...

[whacker@fireball ~]$ dmesg |grep Phenom
[    0.026129] CPU0: AMD Phenom(tm) II X6 1055T Processor stepping 00
[   18.215786] powernow-k8: Found 1 AMD Phenom(tm) II X6 1055T Processor (6 cpu cores) (version 2.20.00)
...
top - 13:58:47 up 20:27,  9 users,  load average: 0.84, 0.80, 0.71
Tasks: 385 total,   3 running, 382 sleeping,   0 stopped,   0 zombie
Cpu(s): 12.0%us,  3.0%sy,  0.0%ni, 85.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8002032k total,  7858980k used,   143052k free,   261300k buffers
Swap: 10474300k total,        0k used, 10474300k free,  6695792k cached

Machine appears lightly loaded, with 'camstream' taking about 60% of one CPU core

HTH;
Dave

Comment 25 Joe Robinson 2011-05-29 18:10:46 UTC
I recently upgraded to Fedora 14, and yesterday had a spurt of crashes which I reported under https://bugzilla.redhat.com/show_bug.cgi?id=708562

I've seen no crashes today.

I'm running Linux fireball.barclay 2.6.35.13-91.fc14.i686.PAE #1 SMP Tue May 3 13:29:55 UTC 2011 i686 i686 i386 GNU/Linux on ...

[whacker@fireball ~]$ dmesg |grep Phenom
[    0.026129] CPU0: AMD Phenom(tm) II X6 1055T Processor stepping 00
[   18.215786] powernow-k8: Found 1 AMD Phenom(tm) II X6 1055T Processor (6 cpu cores) (version 2.20.00)
...
top - 13:58:47 up 20:27,  9 users,  load average: 0.84, 0.80, 0.71
Tasks: 385 total,   3 running, 382 sleeping,   0 stopped,   0 zombie
Cpu(s): 12.0%us,  3.0%sy,  0.0%ni, 85.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8002032k total,  7858980k used,   143052k free,   261300k buffers
Swap: 10474300k total,        0k used, 10474300k free,  6695792k cached

Machine appears lightly loaded, with 'camstream' taking about 60% of one CPU core

HTH;
Dave

Comment 26 Pavel Alexeev 2011-06-02 19:06:22 UTC
What version now in use?