abrt 1.0.8 detected a crash.
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.)
reason: Process /usr/bin/opencv_haartraining was killed by signal 11 (SIGSEGV)
release: Fedora release 13 (Rawhide)
Created attachment 398507 [details]
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.
*** Bug 552469 has been marked as a duplicate of this bug. ***
I've made a build with OpenMP disabled, tell me if it solves your issue.
It was supposed to be fixed, though:
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.
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:
These say FC12, will they work fine on FC13?
The src.rpm was built on a F-12 but it was compiled against F-13
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.)
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.
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?
Builds i provided here had openMP disabled, the -8 in CVS still has openMP enabled.
I would be interested in trying the openMP builds to see if the patches you have added do or don't fix the problem.
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?
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.