I have posted full details on StackOverflow.
There are a few deeply concerning things for me to sort through.
I am thinking that Visual C++ 2008 combined with the latest Boost was a bad mistake for me to have made. The debugger and linker in Visual C++ 2008 do not cope well with boost template identifier lengths, for one thing.
There appears to be some kind of an endless loop bug (not reported in the stackoverflow question) but which appears to be unique to my use of the Boost::interprocess::map code. I believe it is proximally caused by a non-terminating loop in the code, this code, which even has "yea, yea, I know it's ugly". Well now it's not only ugly, it's caused complete and total application lockups, and eventually heap corruption.
The endless loop and ugly code in question is circa line 351 in managed_open_or_create_impl.h.
Look for this comment:
//This loop is very ugly, but brute force is sometimes better
//than diplomacy. If someone knows how to open or create a
//file and know if we have really created it or just open it
//drop me a e-mail!
Would it be too much to ask that the shared memory library, when linked on Windows, use
native CreateFile apis?
Has anyone ever had this ugly loop cause heap corruption and a crash here:
create_device<FileBased>(dev,....); // <-- kaboom.
I've had a taste of how little fun Boost is in Visual C++ 2008, and while Boost is a lovely thing, it's not much fun when combined with old compilers and linkers. New wine and old wineskins, all that sort of thing. (I've had a bad day, and I'm going to go do something else.) I do appreciate Boost and everybody who contributes to it, but this was a bad hair day for me. I don't think an endless loop is a good idea in Boost. Maybe you could have the thing GIVE UP after it tries a million times? Or something?
Anyways, I don't need a solution for myself as I'm dropping Boost after today's lesson in how much fun Boost is in old C++ 2008 codebases, but I am happy to log bugs and do what I can to help the community move on the underlying ugly issue here, if I can be of help by providing a proper bug report and so on, please ask me to do so, and I will.
Boost::Interprocess is brilliant, but I'm not sure my brain is up to following along after what it's doing. Therefore the sane choice appears for me to drop it for my current projects.
Well, it seems that I can also solve my issues by switching from boost shared_memory to boost windows_shared_memory.
I hope that the link in the stackoverflow question above helps someone to fix similar issues if they ever get stuck where I was stuck.
It doesn't seem like very many people use this. Lots of dead silence on stackoverflow whenever I ask questions about boost interprocess.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.