- Boost - lists.boost.org

[Boost-bugs] [ boost-Support Requests-1634278 ] memory pattern question
by SourceForge.net 12 Jan '07

12 Jan '07

Support Requests item #1634278, was opened at 2007-01-12 10:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1634278&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: memory pattern question Initial Comment: Hi, My team developed an application in C++. The application's working set increases steadily. All leaks we could track we corrected. The last remaining leak is a difficult one. The reason I post this message here is to see if someone has an idea of what this data structure could be or a pointer to where I could look. We use template stuff in the code (trees, sets, etc etc). We look at the memory by hexanalyzing a forced core. (this is a linux app). The pattern is inside blocks of malloce'd space and these blocks appear larger and larger with similar content. The patter is as follows: int char [4] void *; void * Exactly 16 bytes, the int is 1 or 2 for the most part but I have seen 0xFFFFFFFF at times. The char at times has character but never no more than 3 followed by \0. The last two seem to be real pointers and at time 0x20 and 0x40 from each other. At first glance it looks like a tree entry but not sure. Any ideas ? Thanks David De La Rosa delarosa(a)ilstechnology.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1634278&group_… ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] [Threads] uncoditional scoped lock?
by Sohail Somani 12 Jan '07

12 Jan '07

I should have mentioned that one can't use wait(mtx,pred) because this needs to be used in the signalling thread. It might be better to have this as a scoped_lock constructor? Anyway... > -----Original Message----- > From: Sohail Somani > Sent: Friday, January 12, 2007 10:39 AM > To: 'boost(a)lists.boost.org' > Subject: [Threads] uncoditional scoped lock? > > Hi, > > Somewhat longer-than-normal-noise follows :) > > Consider the following pseudo-code which has a race condition: > > condition g_some_cond; > mutex g_condition_mtx; > > void thread_fn() > { > { > ... // get lock > g_some_cond.wait(condition_lock); > } > // do work > } > > void main_thread() > { > thread_group grp; > // Start all threads and have them wait on the condition > for(i in [0,N)) grp.create_thread(&thread_fn); > > { > ... // get lock > g_some_cond.notify_all(); // let threads continue > } > } > > The race condition is of course that it is possible that not > all threads actually start waiting on the condition before > notify_all() is called. In this case, it is possible to solve > the race condition in two ways: > > 1) Have the last thread that reaches the condition wait, > signal to the main thread > 2) Have the main thread checking the condition before notify_all() > > I don't really like the first case because it requires > bi-directional signalling between the threads. Though in my > ignorance, I really do consider it the correct solution. The > second solution would look something like this: > > while(true) > { > scoped_lock cond_lock(g_condition_mtx); > // .num_waiting_threads() is made up > if(N_EXPECTED_THREADS==g_some_cond.num_waiting_threads()){break;} > // release lock > } > > Should the second pattern be encapsulated in the condition > object somehow? It is almost like timed_wait(mtx,xt,pred) but > there is no timeout. So maybe untimed_wait()? Is there > another way to do this? > > Thanks for your eyes! > > Sohail

2 1

[iterator] Proposal for inclusion of a csv_ostream_iterator class.
by Emre Turkay 12 Jan '07

12 Jan '07

Hi folks, Attached is the csv_ostream_iterator class, I frequently use. I think it could be incorporated into the boost.iterator library (if there is no such thing somewhere in the standart or in some boost library so far.) What it does is very similar to the std::ostream_iterator, the only difference is that it does not put a delimiter after the last element inserted. Such as when we write an integer container to a stream with a comma delimiter, we get something like this: { 1, 7, 12, 5, 8, } however by using this class the last delimiter is gone { 1, 7, 12, 5, 8 } which is mostly the intended behavior. It can be used for textual data generation (for correct CSVs and good looking XMLs) including code generation. Note: Works with gcc-4.x, may needs to be modified to be portable. Thanks, Emre Turkay

2 1

Re: [boost] Regressions in your Boost libraries as of 2007-01-12 [RC_1_34_0]
by Jeremy Siek 12 Jan '07

12 Jan '07

Hi Doug, Are there any OSL machines with the below compilers installed that I could use to resolve these issues? Best regards, Jeremy On Jan 12, 2007, at 10:00 AM, Douglas Gregor wrote: > You are receiving this report because one or more of the libraries you > maintain has regression test failures that are not accounted for. > A full version of the report is sent to the Boost developer's mailing > list. > > Detailed report: > http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/ > developer/issues.html > > There are failures in these libraries you maintain: > concept_check (15) > > |concept_check| > class_concept_fail_expected: borland-5.6.4 borland-5.8.2 > borland-5.8.2 msvc-6.5 msvc-6.5 msvc-7.0 > stl_concept_covering: borland-5.8.2 borland-5.8.2 gcc-3.3.6 > gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux > gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc ______________________________________ Jeremy Siek <jeremy.siek(a)colorado.edu> http://www.cs.colorado.edu/~siek/ Visiting Assistant Professor Department of Computer Science University of Colorado at Boulder

1 0

[Report] 20 regressions on RC_1_34_0
by Douglas Gregor 12 Jan '07

12 Jan '07

Boost Regression test failures Report time: 2007-01-12T11:01:01Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 20 failures in 5 libraries concept_check (15) date_time (1) regex (1) test (2) utility (1) |concept_check| class_concept_fail_expected: borland-5.6.4 borland-5.8.2 borland-5.8.2 msvc-6.5 msvc-6.5 msvc-7.0 stl_concept_covering: borland-5.8.2 borland-5.8.2 gcc-3.3.6 gcc-3.4.5_linux gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc |date_time| testgenerators: qcc-3.3.5_gpp |regex| regex_regress_threaded: msvc-6.5 |test| prg_exec_fail2: darwin-4.0.1 prg_exec_fail3: cw-9.4 |utility| operators_test: gcc-3.4.5_linux_x86_64

1 0

Boost.Build does not recognize .v2 less Jamfile s
by Roland Schwarz 12 Jan '07

12 Jan '07

I might have missed something in the Discussion, but isn't the v2 expected to work on Jamfile _and_ Jamfile.v2 ? If I actually rename the file Jamfile.v2 to Jamfile the build from boost root does not work anymore. Maybe a hint: the library does not show up in bjam --show-libraries. Thank you for attention, Roland

2 4

[DateTime] New US DST Rules & Timezones In General
by Caleb Epstein 12 Jan '07

12 Jan '07

I'm in the process of testing/fixing applications in light of the new DST rules that begin this year in the US (see http://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005#Change_to_daylight_s…) In the process of doing this, I found a hard-coded posix_time_zone specification in one of my libraries that I've had to correct for these new rules. As a result of this exercise, I'm once again struck by what seems to me like an overly rigid treatment of timezones in Boost.DateTime. The deficiencies I see in the out-of-the-box implementation are as follows: * No built-in support for multiple DST rules within a single zone. Ideally one should be able to calculate the localtime equivalent of any datetime in history with the appropriate rules that were in effect *at that time*. I've updated my version of the Eastern Standard/Daylight Time for the new 2007 rules, but if I use this new set of rules for historic datetimes, I will get incorrect results when converting to/from UTC. * Does not make use of system time facilities for localtime conversions. I'm not sure how Windows deals with timezone concepts, but most C libraries on UNIX make use of "tzfile(5)" data files (See http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=tzfile) to drive the "gmtime" and "localtime" functions. Oversimplifying, these files store a series of time_t values with associated UTC offsets. If you inspect one, you'll see all of the past and projected future daylight savings switch-overs recorded. When DST rules change, it is a relatively simple matter to update these data files, and no application code needs to change. * Current DST traits classes (us_dst_trait) and examples are incorrect for new 2007 DST rules. But fixing these for 2007 makes them wrong for historic dates. Catch-22-y. I realize it is possible to implement a custom time_zone that uses the system library facilities, but I'd really like to see something like this available out-of-the-box. Unfortunately, I don't think the time_zone_base interface meshes very well with the C library localtime/gmtime facilities. For example implementing "dst_local_start_time(year)" and "dst_local_end_time(year)" might require some care given the C library interfaces. Without implementing a custom time_zone, users are left with one and only one rule they can use, and this means that fixing their timezone specifications for 2007 breaks them for historic dates. I'm not sure if this is concerning for others, but I find it extremely troublesome. -- Caleb Epstein

3 3

[range] as_array broken
by Eric Niebler 12 Jan '07

12 Jan '07

Consider the output of the following program: #include <iostream> #include <algorithm> #include <boost/range.hpp> #include <boost/range/as_array.hpp> #include <boost/range/as_literal.hpp> void print_char(char ch) { std::cout << ch << '\t' << (int)ch << '\n'; } template<typename Range> void print_range(Range const &rng) { std::for_each(boost::begin(rng), boost::end(rng), print_char); } int main() { print_range(boost::as_literal("hello")); std::cout << '\n'; print_range(boost::as_array("hello")); std::cout << '\n'; return 0; } It prints the following: h 104 e 101 l 108 l 108 o 111 h 104 e 101 l 108 l 108 o 111 There is no difference between treating a string literal as an array or as a null-terminated string. There should be. When treated as an array, the null-terminator should be treated as any other element in the array. The problem comes from range/detail/implementation_help.hpp: template< class T, std::size_t sz > inline T* array_end( T BOOST_RANGE_ARRAY_REF()[sz], char_or_wchar_t_array_tag ) { return boost_range_array + sz - 1; } It seems Boost.Range is still treating arrays of char and wchar_t specially. IIRC, we decided long ago that it shouldn't. This is on HEAD, BTW. -- Eric Niebler Boost Consulting www.boost-consulting.com

3 7

[python] patch for python.jam for HP-UX (setting proper file suffix)
by Boris Gubenko 12 Jan '07

12 Jan '07

On HP-UX, different versions of Python interpreter expect shared libraries to have different suffix: for example, Python 2.4.3 expects .sl suffix while Python 2.5 expects .so suffix. Attached patch makes sure that on HP-UX, boost python library tests create python extension files with the suffix appropriate for the version of Python interpreter used by the test system. I tested it on HP-UX with Python 2.4.3 and with Python 2.5. I also tested it on Tru64 to make sure that it does not affect other platforms. Please, apply it to CVS HEAD and the RC branch. Thanks, Boris

2 3

[typeof] please make "*_native" tests expected failures on HP-UX
by Boris Gubenko 12 Jan '07

12 Jan '07

Like many other compilers, aCC6 on HP-UX does not support typeof extension (to be precise, it supports it in GNU C++ dialect compatibility mode -- -Ag++ -- but not in the default mode). In explicit-failures-markup.xml, there is a group of toolsets making "*_native" typeof library tests expected failures, with the remark: "Native mode is not supported for this compiler.". Please, add "acc" toolset to this group, in both HEAD and the RC branch. I don't think that a patch is needed for such a simple change, but if you need/want a patch, I can provide one. Thanks, Boris

1 0