Run time heap corruption when running on windows

149 views
Skip to first unread message

Shmuel Fine

unread,
Jul 3, 2016, 12:13:55 PM7/3/16
to Ceres Solver
Hello All

I'm running into this problem with ceres regardless of how I use it.
It can be dynamically or statically linked, using glog or minilog, it happens anyway.
I'm using Visual studio
All projects are compiled as MT / MTd 64bit .

When a std::string object used by ceres gets out of scope and its destructor is called, it throws
Several examples:
When using ceres as DLL:
/* Next line throws at _ASSERTE(_pFirstBlock == pHead); 
since the outputted string its allocated in ceres and freed in my code. Don't have a clue what's wrong with it, it's the same compiler : */
  std::cout << summary.FullReport() << "\n";   
(Removing this line actually runs fine)

When using ceres as LIB:
When ceres::Solver::Options object goes out of scope (after solve finished) and its dtor is called, a different heap-corruption error is thrown, at "_Orphan_all" function (std).

The odd thing is, that it doesn't happen at the first time its called, and that summary.FullReport() doesn't thorw when running ceres as lib but Solver::Options dtor does (options has "temp library" member which is  a string)

Any ideas ?
Thanks in advance.

Keir Mierle

unread,
Jul 3, 2016, 8:29:29 PM7/3/16
to ceres-...@googlegroups.com
Hi Shmuel,

tl;dr - Do not use Ceres as a DLL.

The behavior you are seeing can happen when different allocators are used for memory allocated by Ceres and by the calling application. Are you by chance using an alternative allocator? However, there are many caveats to using Ceres as a DLL. Ceres as a DLL works for some people (and we have some patches for it) but in general we do not recommend or support it. Please statically link. The reason is that you can't allocate memory on one side of a DLL and guarantee you can free it on the other, among other issues.

For more information, see this writeup on Stack Overflow.

Thanks,
Keir

--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/4fd63b91-1a72-4a1e-9d6b-6044f0af54e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Keir Mierle

unread,
Jul 3, 2016, 8:33:11 PM7/3/16
to ceres-...@googlegroups.com
Hi Shmuel,

I read your email too quickly :) I see you have tried statically linking as well with the same result. Can you create a minimal reproduction? Unfortunately, the core Ceres developers do not use Windows; we did the initial port ages ago, but since then the community has provided Windows support.

By chance have you overloaded operator new anywhere in your code?

Thanks,
Keir

Björn Piltz

unread,
Jul 4, 2016, 8:51:07 AM7/4/16
to ceres-...@googlegroups.com
You also have to use the same version of Visual Studio to compile Ceres as your application. Check dependency viewer if Ceres.dll links to the same version of the runtime (msvcXXX.dll or as of MSVC 2015 vcruntimeXXX.dll) as the application.

Björn

Shmuel Fine

unread,
Jul 4, 2016, 11:40:50 AM7/4/16
to Ceres Solver
Thank you all for your advises.
I've downloaded latest ceres (1.11) and copied all files to my static lib . after few minor adjustments (especially at collections_port.cc there are missing namespace specifications, and mix should be ceres::internal::hash_mix... don't know how did it compile without it)
it ran . So it's in my home field now. 
Nevertheless, 
on debug, when trying to free solver::options::trust_region_problem_dump_directory (which is std::string) , then Orphan_All throws. 
seems like ceres treats its strings differently than other code...
Which is odd since the lib is the same one for all... 
Is there any flag or something that can trigger it ?

Thanks

בתאריך יום שני, 4 ביולי 2016 בשעה 15:51:07 UTC+3, מאת Björn Piltz:

Shmuel Fine

unread,
Jul 5, 2016, 6:24:05 AM7/5/16
to ceres-...@googlegroups.com
Problem was solved, though I don't understand how does the solution related to the phenomena... 
I've simplified the data structure of the parameter blocks:
it was quite cumbersome map of 3dPoint -> {vector of cameras that see this point}
and I guess the way I was iterating over the map was doing something wrong with the pointers
As I said, don't know why does the memory corruption happened elsewhere.

Cheers
Shmuel


--
You received this message because you are subscribed to a topic in the Google Groups "Ceres Solver" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ceres-solver/7Couksfbyn0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/68721394-8b04-471e-9222-feb9435b90c4%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages