Bug 571380 - [abrt] crash in opencv-2.0.0-7.fc13: Process /usr/bin/opencv_haartraining was killed by signal 11 (SIGSEGV)
Summary: [abrt] crash in opencv-2.0.0-7.fc13: Process /usr/bin/opencv_haartraining was...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: opencv   
(Show other bugs)
Version: 13
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Rakesh Pandit
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:6dde2efa4652f3814d3a5c9c760...
Keywords:
: 552469 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-08 11:35 UTC by Trever Adams
Modified: 2010-12-23 13:37 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-23 13:37:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (32.92 KB, text/plain)
2010-03-08 11:35 UTC, Trever Adams
no flags Details

Description Trever Adams 2010-03-08 11:35:12 UTC
abrt 1.0.8 detected a crash.

architecture: x86_64
Attached file: backtrace
cmdline: opencv_haartraining -data trainout -vec Male.Genitals.Nude.vec -bg Male.Genitals.Nude.neg -nstages 20 -nsplits 5 -maxtreesplits 8 -minhitrate 0.50 -maxfalsealarm 0.5 -npos 182 -nneg 4644 -w 26 -h 26 -mem 1024 -mode ALL -minpos 11.375 -nonsym
comment: I am trying to rerun data to train a haarcascade. This data worked perfectly in FC12. It causes crashes in FC13. Using the cascades previously trained doesn't seem to cause a problem. It appears to only be training. (I also notice that this version is multithreaded, while the previous version was compiled with that turned off.)
component: opencv
executable: /usr/bin/opencv_haartraining
kernel: 2.6.33-1.fc13.x86_64
package: opencv-2.0.0-7.fc13
rating: 4
reason: Process /usr/bin/opencv_haartraining was killed by signal 11 (SIGSEGV)
release: Fedora release 13 (Rawhide)

Comment 1 Trever Adams 2010-03-08 11:35:14 UTC
Created attachment 398507 [details]
File: backtrace

Comment 2 Trever Adams 2010-03-08 11:41:44 UTC
For those wondering, I am using this along with some text stuff to make an internet content classifier (mixed with a proxy that will do acls on X-headers returned by icap modules, it can be used to make filters).

The code will be open sourced (previews of the text and image code have been released elsewhere). The data, I am not sure yet.

Comment 3 Trever Adams 2010-03-08 11:43:02 UTC
*** Bug 552469 has been marked as a duplicate of this bug. ***

Comment 4 Haïkel Guémar 2010-03-08 20:42:36 UTC
I've made a build with OpenMP disabled, tell me if it solves your issue.
http://koji.fedoraproject.org/koji/taskinfo?taskID=2039699

It was supposed to be fixed, though:
https://code.ros.org/trac/opencv/changeset/2195

Comment 5 Trever Adams 2010-03-08 22:19:24 UTC
OpenCV Error: Assertion failed (tlsRNGKey != 0) in theRNG, file /builddir/build/BUILD/OpenCV-2.0.0/src/cxcore/cxrand.cpp, line 606
terminate called after throwing an instance of 'cv::Exception'

This is now what I get.

Comment 6 Haïkel Guémar 2010-03-08 23:04:16 UTC
braindead assertion:
pthread_key_create(&tlsRNGKey, deleteRNG);
CV_Assert(tlsRNGKey != 0);  // stupid, it will always be == 0 upon creation !

At least, they already fixed it in CVS

I got you a new build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2039927

Comment 7 Trever Adams 2010-03-08 23:28:34 UTC
These say FC12, will they work fine on FC13?

Comment 8 Haïkel Guémar 2010-03-09 06:09:53 UTC
The src.rpm was built on a F-12 but it was compiled against F-13
http://koji.fedoraproject.org/koji/taskinfo?taskID=2039928

Comment 9 Trever Adams 2010-03-09 18:40:23 UTC
This appears to fix it (still waiting for them to finish). Do you have OpenMP enabled on -9 build? I am assuming the commit message I saw means that the problem I am seeing is fixed. I also see that gomp has been updated... Is this reason to hope?

I am seeing one strange thing. There are not multiple paths in the cascade. There should be. (I will retest with more negative/false positive samples as soon as this runs and see if it is just that those I moved out of the way for the tests are what cause the forks. BTW, I moved them out of the way before I filed this bug and still had the bug.)

Comment 10 Haïkel Guémar 2010-03-10 07:16:24 UTC
OpenMP is still enabled in latest builds, Karel's patch fixes a buffer overflow which should happen whether openMP is enabled or not.
It may fix your issue, but i think they're unrelated.

i'll push the assertion patch, for openMP, it might be disabled it before beta if it brings more issues.

Comment 11 Trever Adams 2010-03-11 22:33:08 UTC
Ok -8 did fix the crash. It also is indeed doing the forking (non-straight-line cascade). I haven't tried -9 as I didn't see a koji link here nor has it showed up in updates. Was OpenMP enabled in -8?

Comment 12 Haïkel Guémar 2010-03-12 06:12:25 UTC
Builds i provided here had openMP disabled, the -8 in CVS still has openMP enabled.

Comment 13 Trever Adams 2010-03-12 13:38:46 UTC
I would be interested in trying the openMP builds to see if the patches you have added do or don't fix the problem.

Comment 14 Trever Adams 2010-05-03 18:44:32 UTC
Changing to F13 as that is what I am using. This is "FIXED" but doesn't have OpenMP support. Is it possible, or will it happen, that there is a real complete fix?

Comment 15 Nicolas Chauvet (kwizart) 2010-12-23 13:37:18 UTC
Marking as fixed,
For openMP, since OpenCV can end in various case (specially with -sse2 less system) I more expect it to be a build option.


Note You need to log in before you can comment on or make changes to this bug.