Description of problem:
Steps to Reproduce:
app crashes (cvSobel works so the app itself should be correct)
Could you provide an use case ?
Besides, we're working on OpenCV 2, there's a scratch build there:
Could you confirm that your application still crashes ?
I recently compiled OpenCV 2 from sthe sources and it still crashes but only on 64 bit systems.
IplImage* pImage = cvLoadImage("test.jpg", CV_LOAD_IMAGE_GRAYSCALE);
CvMemStorage* pStorage = cvCreateMemStorage(0);
CvSeq* pResults = cvHoughCircles(pImage, pStorage, CV_HOUGH_GRADIENT, 1, pImage->width/2);
for(int i = 0; i < pResults->total; i+=2)
float* p = (float*) cvGetSeqElem(pResults, i);
CvPoint pt = cvPoint(cvRound(p), cvRound(p));
cvCircle(pImage, pt, cvRound( p ), CV_RGB(0xff,0xff,0xff));
As i said, exactly the same code runs on 32 bit Fedora without problems.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
Here is the relevant ticket in the OpenCV tracker (including patch): https://code.ros.org/trac/opencv/ticket/157
It appears that this is the result of a compiler bug.
The same problem also appeared here, and I have made a few more observations in the process:
1) This bug still appears in Fedora 13.
2) The problem only occurs with the Fedora GCC, a plain vanilla GCC 4.4.3 does not show the same behavior. If I remember correctly, a quick try on my Gentoo system also ran flawlessly.
3) The problem seems to be related to the -fstrict-overflow flag. Adding -fno-strict-overflow to the compiler options resolves it. This is almost certainly a compiler bug. Dumping all intermediate tree representations one can see that in the expression "_map[j - mapstep]" the compiler converts j-mapstep to 64 bit by casting it to "unsigned long int". My guess is that the fstrict-overflow optimizations only are applied at a later stage so that the following optimization is erroneously applied:
[quote gcc info page]
This option also allows the compiler to assume strict pointer
semantics: given a pointer to an object, if adding an offset to
that pointer does not produce a pointer to the same object, the
addition is undefined. This permits the compiler to conclude that
`p + u > p' is always true for a pointer `p' and unsigned integer
`u'. This assumption is only valid because pointer wraparound is
undefined, as the expression is false if `p + u' overflows using
twos complement arithmetic.
Of course, this optimization should _not_ be applied here because the expression "j-mapstep" was originally a signed integer, so that the reasoning that there is pointer wraparound is wrong.
4) I had a quick look at the GCC srpm but all the patches seem to be unrelated. Obviously I must be wrong ;-)
Rakesh, can you update this bug to Fedora 13 as the previous comment noted?
This bug still exists in opencv-2.0.0-9.fc13.x86_64.
Why not apply the patch noted in this thread:
for the 64-bit package, as a work-around until the compiler details are sorted out?
How can we leave a major error like this in a common package for a YEAR?
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '12'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 12's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 12 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Before this bug dies too early (it is still present in F13), can anyone confirm that it is fixed in F14? It should be, given https://bugzilla.redhat.com/show_bug.cgi?id=610785 but I could not test yet.
I will test it today or tomorrow and post the results
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.