New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Surface Matching and x64 : heap corruption #170
Comments
do you have a patch for this? |
Those 2 methods are intentional. If they are mixed up, with one alternative the precision of the surface matching drops dramatically, with the other it takes a lot of time. |
@rbregier , please reopen this issue if you have reproducing example. |
Well, the example program crashes with the example dataset during training: In debug mode, Visual Studio throws an exception : And my investigations lead me to the conclusion of my first message. When asking to Tolga Birdal (the named author in the source code) about it in February, he answered me the following : My system settings : So, yes I can provide the fix proposed in my first message, but the resulting performances were not awesome if I remember correctly and according to @bmagyar this fix is suboptimal. |
At the time of Tolga's GSoC project, I tested this on all platforms I had available: Ubuntu 32bit, Ubuntu 64bit, OSX 64bit. He was using Windows so it is strange that this didn't come up as well as that no warning about this is reported by buildbot (!). Frankly, I didn't like that macro magic there in the first place, but at the time that was the best shot. This could be solved by using a hashing library that does the 32/64 switching internally, but I'm also curious to see what Tolga is coming up with. |
@tolgabirdal Do you have any thoughts on this? |
This might be due to modification made later. Let us define KeyType as follows: #if (defined x86_64 || defined _M_X64) I will be submitting a pull request with that. |
I can confirm that with this definition it runs : #if (defined x86_64 || defined _M_X64) However, I get some warnings regarding casts from KeyType to int, unsigned int and size_t. I don't know the effects of those on the algorithm. |
How about using |
I think it would require a more consequent code refactoring as a default hash function using "unsigned int" (called hash) is used in several place in the code such as for ICP to build hashtables and it is unclear what should be the key type for thoses, but I don't have time to dive into the code and try to figure out how it works in detail. I guess Tolga could fix this easily in his pull request. |
In this question same problem exist in opencv-3.2-dev. I replace code as suggested by @tolgabirdal and it works. May be a PR is necessary. |
I do have it: |
@tolgabirdal I have got VS 2013. there is no definition for uint64_t in VS2013 (that's OK in vs2015) #else you will have some warnings : |
I am using VS 2013 (64 bit)I tried this:
Unfortunately this could not my problem (My problem : Stack around the variable 'hashKey' was corrupted.) |
@apassenger Did you solve the problem? I have encountered the same problem? still not solved. |
I am using VS 2015 (64 bit) on a Windows 10 machine with OpenCv 3.2.0 . |
Any updates on this? I am using the 3.2 version and get this error with VS2013 x64 aswell |
I have added that but the still same problem. openCV 4.0.0, VS -2015 |
@opencvbel , @apassenger Did you solve that problem? |
this problem happend at debug model |
is there any progress on this issue? i meet it using VS2017 and openCV 4.0.0 too. |
@JoyMazumder No couldnt find any solution, sorry |
Guys,
I have a PR under:
#811
This doesn't pass all the tests yet and I do not have the time right now to
update. However, that could hopefully solve this issue.
Cheers,
…On Thu, Feb 14, 2019 at 12:18 PM pclbel ***@***.***> wrote:
@JoyMazumder <https://github.com/JoyMazumder> No couldnt find any
solution, sorry
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#170 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGqlvfGAPoB0rSDWn9ZufM7528zDAWNEks5vNUYigaJpZM4Dfe5J>
.
--
/tolga
|
It works!However,the performance of the algrithm (after using the changes above)now is quite poor. We cannot even match the samples given in the opencv well. |
It works!However,the performance of the algrithm (after using the changes above)now is quite poor. |
It works!However,the performance of the algrithm (after using the changes above)now is quite poor. do you have ideas |
any one solve this problem? static KeyType hashPPF(const Vec4d& f, const double AngleStep, const double DistanceStep) murmurHash(key.val, 4*sizeof(int), 42, &hashKey); |
@luck-boy1994 You using outdated version. Issue is fixed here: #2347 |
thank you |
Excuseme ,opencv with new version doesn't have this problem,right?
for example ,opencv 4.0 doesn't have this problem
…------------------ 原始邮件 ------------------
发件人: "luck-boy1994"<notifications@github.com>;
发送时间: 2020年4月19日(星期天) 晚上9:22
收件人: "opencv/opencv_contrib"<opencv_contrib@noreply.github.com>;
抄送: "823473780"<823473780@qq.com>;"Comment"<comment@noreply.github.com>;
主题: Re: [opencv/opencv_contrib] Surface Matching and x64 : heap corruption (#170)
@ luck-boy1994您使用的是过时的版本。
问题已在此处修复:#2347
thank you
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Hi,
In surface_matching\src\ppf_match_3d.cpp a function "murmurHash" is used like the following :
KeyType hashKey=0;
murmurHash(key, 4*sizeof(int), 42, &hashKey);
In case of a 64bit system, "murmurHash" is defined via a macro as "hashMurmurx64" in surface_matching\src\hash_murmur.hpp
However this function takes a void* as a parameter which should at least of length (2*sizeof(unsigned int)). Here &hashKey is given, and hashKey is an unsigned int, thus there is a heap corruption.
A workaround consists in forcing "murmurHash" to be defined as hashMurmurx86 even on 32 bit system, but in this case I don't understand the purpose of specific code for x64 systems.
Regards,
Romain
The text was updated successfully, but these errors were encountered: