- Boost-users - lists.boost.org

Re: [Boost-users] Boost.Thread memory leak reported
by Sohail Somani 25 Aug '05

25 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Christian Henning > Sent: Thursday, August 25, 2005 10:53 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Boost.Thread memory leak reported > > > On 8/25/05, Sohail Somani <s.somani(a)fincad.com> wrote: > > Valgrind doesn't find it either. I have yet to try it with stack > > walker (was about to but xp blue screened so I took it as a sign) > > > > Isn't valgrind for linux? I think the problem might be on > Windows machines, only. > > The functions new_critical_section() and > delete_critical_section() should be called only on Windows > machines, since they are calling Win32 functions. I didn't know it was a Windows only problem until you posted the location of the leaked allocation.

2 1

Re: [Boost-users] Boost.Thread memory leak reported
by Sohail Somani 25 Aug '05

25 Aug '05

Valgrind doesn't find it either. I have yet to try it with stack walker (was about to but xp blue screened so I took it as a sign) > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Elisha Berns > Sent: Thursday, August 25, 2005 9:45 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Boost.Thread memory leak reported > > > Right, > > Those are the same project settings I'm using. The only > difference is that my code is in a non-MFC class. I tested > it with the VLD memory leak detector found on CodeProject and > it also reports zero leaks. > > Elisha > > > I got exactly the same error. Here is how I did it: > > > > I created a project of a MFC Application inside VC7.1 . The wizards > > creates the usual document/view classes. Inside the > document class I > > placed, like Elisha, a mutex. Inside the OnNewDocument() function I > > put the code from Elisha: > > > > BOOL CMFCTestDoc::OnNewDocument() > > { > > if (!CDocument::OnNewDocument()) > > return FALSE; > > > > // TODO: add reinitialization code here > > // (SDI documents will reuse this document) > > > > boost::thread indexer( > > boost::bind(&CMFCTestDoc::run, this)); > > > > boost::mutex::scoped_lock lock(m_orphan_annotation_mutex); > > > > indexer.join(); > > > > > > return TRUE; > > } > > > > I'm using MFC in a Shared DLL and Multithreaded Debug DLL runtime > libs. > > > > I can send the project files to anyone that is interessted. > > > > By the way, if I use Purify to track down the leaks, it cannot find > them. > > > > Regards, > > Christian > > > > > > > > > > On 8/25/05, Sohail Somani <s.somani(a)fincad.com> wrote: > > > > -----Original Message----- > > > > From: boost-users-bounces(a)lists.boost.org > > > > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Elisha > Berns > > > > Sent: Wednesday, August 24, 2005 8:48 PM > > > > To: Boost > > > > Subject: [Boost-users] Boost.Thread memory leak reported > > > > > > > > > > > > > > > > Detected memory leaks! > > > > Dumping objects -> > > > > {146} normal block at 0x00227008, 24 bytes long. > > > > Data: < | > 08 7C 04 00 FF FF FF FF 00 00 00 00 00 > 00 00 > > > > 00 > > > > {145} normal block at 0x00223928, 8 bytes long. > > > > Data: < p" > 08 70 22 00 01 CD CD CD > > > > Object dump complete. > > > > > > Hi Elisha, > > > > > > Could you come up with a small test case that demonstrates the > problem? > > > > > > > > > _______________________________________________ > > > Boost-users mailing list > > > Boost-users(a)lists.boost.org > > > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > > > > > > _______________________________________________ > > Boost-users mailing list > > Boost-users(a)lists.boost.org > > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

2 1

[filesystem] Mingw DLL problems
by Paul 25 Aug '05

25 Aug '05

Hi all, It seems that theres a lot of traffic in regards to using filesystem as a DLL with mingw (or other) compilers. I'd like to lay out what I know and try and figure out a solution for it. Or at least ask for a work-around to be added to the CVS, or to the documentation! Often I see complaints that it will fail to work as expected! This is because the 'native' "flag" passed to path will be virtually IGNORED when you link to it as a DLL. Why? Because native is not a flag, its a free function pointer. Inside the filesystem DLL, it compares the address of the passed checker against its version of 'native', however: the address of 'native' is DIFFERENT in the DLL compared with any other DLL or your executable! So native(you) != native(DLL), so paths will be checked the POSIX way, not the native way. I've heard suggestions that you should define BOOST_ALL_DYN_LINK, however that doesn't seem to do anything in my case. I've tested it. I am betting that most people 'solve' it by statically linking to it, but thats not an option for me. The only solution I have come up with is to add a function to get the DLL's native function address. Instead of passing 'native', I now pass get_native(). This just does return native; but it does it inside the DLL, so you get the "right" function address. Beman said that it should be fixed in the next version of filesystem, however it appears to be Not Hear Yet. So can we please please get an interim fix? Attached was my attempt from back in January, it worked for me, and I'll be applying it to my shiny new 1.33 version. Thanks Paul

1 0

Boost.Thread memory leak reported
by Elisha Berns 25 Aug '05

25 Aug '05

HI, There is a small memory leak reported by VC7.1 just by declaring a boost::mutex (presumably). Since this makes no sense at all, perhaps there is some explanation for this behavior in this compiler. The code looks like this: In the class definition: mutable boost::mutex m_orphan_annotation_mutex; (It's only declared mutable because it's used in 'const' methods also). In the .cpp file: void OrphanedAnnotationMap::IndexOrphanedAnnotations() { boost::thread indexer( boost::bind(&OrphanedAnnotationMap::Index, this)); boost::mutex::scoped_lock lock(m_orphan_annotation_mutex); indexer.join(); } The memory dump is this: Detected memory leaks! Dumping objects -> {146} normal block at 0x00227008, 24 bytes long. Data: < | > 08 7C 04 00 FF FF FF FF 00 00 00 00 00 00 00 00 {145} normal block at 0x00223928, 8 bytes long. Data: < p" > 08 70 22 00 01 CD CD CD Object dump complete. Elisha Berns e.berns(a)computer.org tel. (310) 556 - 8332 fax (310) 556 - 2839

1 0

Trouble using format.hpp on AIX
by Rich Cook 25 Aug '05

25 Aug '05

Hi, Newbie question. I have used Boost for little things and it has worked fine. Now I'd like to use the format.hpp header, but including it on AIX in my project results in the following errors. Does anyone have an idea what is happening? I googled all over the place but found no help on the subject: xlC -c -g -I/g/g0/rcook/aix_5_64_fed/include -I/g/g0/rcook/ downloads/boost_1_33_0 MirandaReader.C -o aix_5_64_fed/MirandaReader.o "/g/g0/rcook/downloads/boost_1_33_0/boost/optional/optional.hpp", line 388.66: 1540-0217 (S) "T" is not a member of "locale". "/g/g0/rcook/downloads/boost_1_33_0/boost/optional/optional.hpp", line 388.10: 1540-0700 (I) The previous message was produced while processing "boost::optional_detail::optional_base<std::locale>::destroy_impl (is_not_reference_tag)". "/g/g0/rcook/downloads/boost_1_33_0/boost/optional/optional.hpp", line 362.9: 1540-0700 (I) The previous message was produced while processing "boost::optional_detail::optional_base<std::locale>::destroy()". "/g/g0/rcook/downloads/boost_1_33_0/boost/optional/optional.hpp", line 208.24: 1540-0700 (I) The previous message was produced while processing "boost::optional_detail::optional_base<std::locale>::~optional_base()". "/g/g0/rcook/downloads/boost_1_33_0/boost/optional/optional.hpp", line 130.7: 1540-0700 (I) The previous message was produced while processing "boost::optional_detail::optional_base<std::locale>::__dftbdt()". "/g/g0/rcook/downloads/boost_1_33_0/boost/optional/optional.hpp", line 471.5: 1540-0700 (I) The previous message was produced while processing "boost::optional<std::locale>::~optional()". "/g/g0/rcook/downloads/boost_1_33_0/boost/format/internals.hpp", line 38.9: 1540-0700 (I) The previous message was produced while processing "boost::io::detail::stream_format_state<char,std::char_traits<char> >::stream_format_state(char)". "/g/g0/rcook/downloads/boost_1_33_0/boost/format/internals.hpp", line 78.53: 1540-0700 (I) The previous message was produced while processing "boost::io::detail::format_item<char,std::char_traits<char>,std::allocat or<char> >::format_item(char)". "/g/g0/rcook/downloads/boost_1_33_0/boost/format/ format_implementation.hpp", line 121.40: 1540-0700 (I) The previous message was produced while processing "boost::basic_format<char,std::char_traits<char>,std::allocator<char> >::make_or_reuse_data(size_t)". "/g/g0/rcook/downloads/boost_1_33_0/boost/format/parsing.hpp", line 415.9: 1540-0700 (I) The previous message was produced while processing "boost::basic_format<char,std::char_traits<char>,std::allocator<char> >::parse(const string_type &)". "/g/g0/rcook/downloads/boost_1_33_0/boost/format/ format_implementation.hpp", line 64.9: 1540-0700 (I) The previous message was produced while processing "boost::basic_format<char,std::char_traits<char>,std::allocator<char> >::basic_format(const string_type &)". "MirandaReader.C", line 138.6: 1540-0700 (I) The previous message was produced while processing "MirandaDataSet::GetGridOrigin(long, Point<double> &)". gmake: *** [aix_5_64_fed/MirandaReader.o] Error 1 -- Richard Cook ✇ Lawrence Livermore National Laboratory Bldg-453 Rm-4037, Mail Stop L-557 7000 East Avenue, Livermore, CA, 94550, USA ☎ (925) 423-9605  (925) 423-6961 --- Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept. (opinions expressed herein are mine and not those of LLNL)

1 0

[ptr_container]copy from one to other with iterator
by Thomas Matelich 24 Aug '05

24 Aug '05

I'm looking at ptr_vector to replace our wrapper around vector<shared_ptr>. How do I correctly write the following: ptr_vector<T> a; ptr_vector<T> b; ... b.push_back(a.begin()); I've tried plain iterators, dereferencing, *iter.base(), etc. I guess I could reinterpret_cast<T*>(*iter.base()). Is there a better way? Also, theres a typo in the docs. The examples page talks about using allocate_clone, and I'm pretty sure its supposed to be new_clone (If not, theres a typo in the tutorial). Thanks, Tom

3 8

Re: [Boost-users] [BULK] Re: [BULK] Re: [BULK] Re: [Test] Asserting a failure
by Sohail Somani 24 Aug '05

24 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Gennadiy Rozental > Sent: Wednesday, August 24, 2005 12:15 PM > To: boost-users(a)lists.boost.org > Subject: [BULK] Re: [Boost-users] [BULK] Re: [BULK] Re: > [Test] Asserting a failure > Importance: Low > > > > On second thought, why not just modify BOOST_REQUIRE? > > What do you propose to modify? > > One could use BOOST_REQUIRE *instead* of assert() or > BOOST_ASSERT. But if > they prefer keep using BOOST_ASSERT I could provide a handler. Well theres no problem using BOOST_ASSERT unless they use it in their code for different reasons. For example they might use it to log in production versions of the application... I guess its not such a big deal if boost test defines its own handler if enable assert handler is not defined. I don't even remember where this thread started :)

1 0

Re: [Boost-users] [BULK] Re: [BULK] Re: [Test] Asserting a failure
by Sohail Somani 24 Aug '05

24 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Sohail Somani > Hmm. That's an idea. I could probably do this within > > Boost.Test so users > > wouldn't need to bother: > > > > test_tools.hpp: > > > > #if !defined(BOOST_TEST_NO_ASSERT_HANDLER) > > > > namespace boost { > > inline void assertion_failed(char const * expr, char const * > > function, char > > const * file, long line) > > { > > ... > > } > > } > > > > #endif > > > > This way by default I will always supply definition for the > > function, unless > > user is willing to suply different one. > > I imagine that would work unless they already use boost > assert and define it in their own code for logging purposes. > Perhaps something along the lines of boost assert for boost test? On second thought, why not just modify BOOST_REQUIRE?

2 1

Re: [Boost-users] [BULK] Re: [BULK] Re: [Test] Asserting a failure
by Sohail Somani 24 Aug '05

24 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Gennadiy Rozental > Sent: Wednesday, August 24, 2005 11:50 AM > To: boost-users(a)lists.boost.org > Subject: [BULK] Re: [Boost-users] [BULK] Re: [Test] Asserting > a failure > Importance: Low > > > > > Try replacing your asserts with BOOST_ASSERT which can be a passive > > assert depending on how you use it. > > > > http://www.boost.org/libs/utility/assert.html > > Hmm. That's an idea. I could probably do this within > Boost.Test so users > wouldn't need to bother: > > test_tools.hpp: > > #if !defined(BOOST_TEST_NO_ASSERT_HANDLER) > > namespace boost { > inline void assertion_failed(char const * expr, char const * > function, char > const * file, long line) > { > ... > } > } > > #endif > > This way by default I will always supply definition for the > function, unless > user is willing to suply different one. I imagine that would work unless they already use boost assert and define it in their own code for logging purposes. Perhaps something along the lines of boost assert for boost test?

1 0

Re: [Boost-users] [BULK] Re: [Test] Asserting a failure
by Sohail Somani 24 Aug '05

24 Aug '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Gennadiy Rozental > Sent: Wednesday, August 24, 2005 9:51 AM > To: boost-users(a)lists.boost.org > Subject: [BULK] Re: [Boost-users] [Test] Asserting a failure > Importance: Low > > > > cannot find one. All I see are macros that assert > successes, and those > > that > > assert exceptions. But my particular function does not > throw, it simply > > "assert()"s. > > I do not know reliable/portable way to intercept an assert > invocation. So > you are on your own here. If you know any hooks to do the > job, I am open to > suggestions. Try replacing your asserts with BOOST_ASSERT which can be a passive assert depending on how you use it. http://www.boost.org/libs/utility/assert.html

2 1