Re: dbx [was: Re: STDCXX-1056 [was: Re: STDCXX forks]]
On Fri, Sep 7, 2012 at 12:23 PM, Liviu Nicoara wrote: > I get this when launching the debugger: > > $ dbx -xexec32 t > For information about new features see `help changes' > To remove this message, put `dbxenv suppress_startup_message 7.9' in your > .dbxrc > Reading t > Reading ld-linux.so.2 > dbx: fetch at 0xf400 failed -- Input/output error > dbx: warning: could not put in breakpoint There is fix for this, but for Studio 12.2: http://wesunsolve.net/bugid/id/6545393 It had priority 5 (very low) so that leads me to assume that it hasn't been fixed yet in 12.3. But I will ask at work about 12.3/Linux. Strangely enough, I don't get the error on Fedora 17 with 12.3. --Stefan -- Stefan Teleman KDE e.V. stefan.tele...@gmail.com
dbx [was: Re: STDCXX-1056 [was: Re: STDCXX forks]]
On 09/07/12 11:58, Stefan Teleman wrote: On Fri, Sep 7, 2012 at 8:52 AM, Liviu Nicoara wrote: On 09/06/12 19:54, Martin Sebor wrote: Also, does the 27.objects test pass with this patch? No, it does not. It hangs at the first insertion, line 227. Unfortunately, I cannot debug it because dbx does not work properly in my installation. What are the symptoms with dbx mishbehaving? (maybe I can help). Thanks! I get this when launching the debugger: $ dbx -xexec32 t For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.9' in your .dbxrc Reading t Reading ld-linux.so.2 dbx: fetch at 0xf400 failed -- Input/output error dbx: warning: could not put in breakpoint dbx: warning: internal handler (-80) made defunct -- could not enable event BPT dbx: warning: internal handler (-86) made defunct -- could not enable event BPT ... Then the program just runs from the get go. If I set breakpoints and rerun, it ignores them. Also, long running programs cannot be broken into with C-c: ^Cdbx: warning: Interrupt ignored but forwarded to child. signal INT in (unknown) at 0xf77cf6c4 0xf77cf6c4: movl %edx,%eax dbx: warning: 'stop' ignored -- while doing rtld handshake terminating signal 2 SIGINT dbx: warning: 'stop' ignored -- while doing rtld handshake (dbx) where dbx: program is not active (dbx) Liviu
Re: STDCXX-1056 [was: Re: STDCXX forks]
On Fri, Sep 7, 2012 at 8:52 AM, Liviu Nicoara wrote: > On 09/06/12 19:54, Martin Sebor wrote: >> >> >> Also, does the 27.objects test pass with this patch? > > > No, it does not. It hangs at the first insertion, line 227. Unfortunately, I > cannot debug it because dbx does not work properly in my installation. What are the symptoms with dbx mishbehaving? (maybe I can help). FWIIW, 27.objects passes with the Intel compiler and your patches: # INFO (S1) (10 lines): # TEXT: # COMPILER: Intel C++, __INTEL_COMPILER = 1210, __INTEL_COMPILER_BUILD_DATE = 20111011, __EDG_VERSION__ = 403 # ENVIRONMENT: pentiumpro running linux-elf (Fedora release 17 (Beefy Miracle) (3.5.0-2.fc17.x86_64)) with glibc 2.15 # FILE: 27.objects.cpp # COMPILED: Sep 6 2012, 20:50:13 # COMMENT: # CLAUSE: lib.iostream.objects [ ... ] # +---+--+--+--+ # | DIAGNOSTIC| ACTIVE | TOTAL | INACTIVE | # +---+--+--+--+ # | (S1) INFO |6 |6 | 0% | # | (S5) WARNING |1 |1 | 0% | # | (S7) ASSERTION|0 | 22 | 100% | # +---+--+--+--+ --Stefan -- Stefan Teleman KDE e.V. stefan.tele...@gmail.com
Re: A question (or two) of procedure, etc.
On 09/07/12 10:54, Martin Sebor wrote: We should remember that there are a number of Jira issues that we fixed on 4.2.x but haven't merged out to 4.3.x or trunk. The idea behind the current process (4.2.x -> 4.3.x -> trunk) was to be able to simply merge the branches in bulk, as opposed to an fix at a time. Unfortunately, we ran into some Subversion issues that made it a huge pain. IIRC, Travis did it at least once so he might still remember the details. That would be very helpful to know. Going forward, to avoid this mess, I would suggest we make an effort to commit fixes wherever necessary at the same time instead of delaying it until some time in the future. Got it. Liviu
Re: A question (or two) of procedure, etc.
We should remember that there are a number of Jira issues that we fixed on 4.2.x but haven't merged out to 4.3.x or trunk. The idea behind the current process (4.2.x -> 4.3.x -> trunk) was to be able to simply merge the branches in bulk, as opposed to an fix at a time. Unfortunately, we ran into some Subversion issues that made it a huge pain. IIRC, Travis did it at least once so he might still remember the details. Before we change the process, it might be a good idea to go through the Jira issues (I think they are resolved but not Closed), commit the 4.2.x fixes to 4.3.x and trunk, and close them. That way we won't have to wonder what fixes are where. Going forward, to avoid this mess, I would suggest we make an effort to commit fixes wherever necessary at the same time instead of delaying it until some time in the future. Martin On 09/07/2012 05:40 AM, Liviu Nicoara wrote: On 09/06/12 23:00, Martin Sebor wrote: Every project has certain branch strategy, I'm not sure about this so maybe Martin can advice. I prefer to develop on trunk and cherry pick to the other branches avoiding bulk merges (and that's in both directions). We've done most work on 4.2.x for historical reasons. I think a better strategy is to develop, as you suggest, on trunk which has the least restrictive commit policy, and merge changes out to the more restrictive branches as appropriate. If open to voting, I am for trunk first, branches later. Liviu
Re: STDCXX-1056 [was: Re: STDCXX forks]
On 09/06/12 19:54, Martin Sebor wrote: Also, does the 27.objects test pass with this patch? No, it does not. It hangs at the first insertion, line 227. Unfortunately, I cannot debug it because dbx does not work properly in my installation. Liviu
Re: A question (or two) of procedure, etc.
Many projects have CTR on trunk and RTC (based on trunk revisions) to branch. This works well. On Sep 7, 2012, at 7:40 AM, Liviu Nicoara wrote: > On 09/06/12 23:00, Martin Sebor wrote: >>> Every project has certain branch strategy, I'm not sure about this so >>> maybe Martin can advice. I prefer to develop on trunk and cherry pick >>> to the other branches avoiding bulk merges (and that's in both >>> directions). >> >> We've done most work on 4.2.x for historical reasons. I think >> a better strategy is to develop, as you suggest, on trunk which >> has the least restrictive commit policy, and merge changes out >> to the more restrictive branches as appropriate. > > If open to voting, I am for trunk first, branches later. > > Liviu >
Re: STDCXX-1056 [was: Re: STDCXX forks]
On 09/06/12 22:58, Stefan Teleman wrote: On Thu, Sep 6, 2012 at 7:31 PM, Liviu Nicoara wrote: There would be a performance degradation. IMHO, it would be minor and would simplify the code considerably. After finally being able to reproduce the defect with SunPro 12.3 on x86_64 I tried to remove the lazy initialization and a (smaller) test case now passes. I am attaching the program and the numpunct patch. With your patches, the performance is much much better: I didn't think about timing it, thanks! The result is somewhat expected without the synchronization. However, the full construction-time initialization is inappropriate if you take in consideration the delegation from the public API to the protected virtual API of the facet class, and the possibility of overrides in subclasses. Also, lazy initialization follows the principle of economy of effort, and caching increases efficiency. If possible in a robust way, I would rather have those two. :-) Liviu # INFO (S1) (10 lines): # TEXT: # COMPILER: Intel C++, __INTEL_COMPILER = 1210, __INTEL_COMPILER_BUILD_DATE = 20111011, __EDG_VERSION__ = 403 # ENVIRONMENT: pentiumpro running linux-elf (Fedora release 17 (Beefy Miracle) (3.5.0-2.fc17.x86_64)) with glibc 2.15 # FILE: 22.locale.numpunct.mt.cpp # COMPILED: Sep 6 2012, 20:50:13 # COMMENT: thread safety # +---+--+--+--+ # | DIAGNOSTIC| ACTIVE | TOTAL | INACTIVE | # +---+--+--+--+ # | (S1) INFO | 11 | 11 | 0% | # | (S2) NOTE |1 |1 | 0% | # | (S8) ERROR|0 |3 | 100% | # | (S9) FATAL|0 |1 | 100% | # +---+--+--+--+ real 1035.05 user 1191.76 sys 63.49 --Stefan -- And now I see with eye serene The very pulse of the machine.
Re: A question (or two) of procedure, etc.
On 09/06/12 23:00, Martin Sebor wrote: Every project has certain branch strategy, I'm not sure about this so maybe Martin can advice. I prefer to develop on trunk and cherry pick to the other branches avoiding bulk merges (and that's in both directions). We've done most work on 4.2.x for historical reasons. I think a better strategy is to develop, as you suggest, on trunk which has the least restrictive commit policy, and merge changes out to the more restrictive branches as appropriate. If open to voting, I am for trunk first, branches later. Liviu
Re: STDCXX-1056 [was: Re: STDCXX forks]
On 09/06/12 19:54, Martin Sebor wrote:
I'm not sure how easily we can do that. Almost all of locale
is initialized lazily. Some of the layers might depend on the
facets being initialized lazily as well. This was a deliberate
design choice. One of the constraints was to avoid dynamic
initialization or allocation at startup. [...]
There would be a performance degradation. IMHO, it would be minor and would
simplify the code considerably.
After finally being able to reproduce the defect with SunPro 12.3 on x86_64 I
tried to remove the lazy initialization and a (smaller) test case now passes. I
am attaching the program and the numpunct patch.
Out of curiosity, does it still work if you move the locale into
the thread function? Like this:
I created the test case because I wanted something more specific and with more
predictable results. Initially, the locale object was created in the thread and
it was passing.
Also, does the 27.objects test pass with this patch?
Will try. I don't think that we can actually use this patch, I bundled it with
the test so that people can test the approach right away.
I don't know if we have tests for it but writing to cerr/cout
in a bad_alloc handler should succeed. I.e., this should not
abort:
try {
struct rlimit rlim = { };
getrlimit (RLIMIT_DATA, &rlim);
rlim.rlim_cur = 0;
setrlimit (RLIMIT_DATA, &rlim);
for ( ; ; ) new int;
}
catch (bad_alloc) {
cout << "caught bad alloc: << 123 << '\n';
}
I see..
Liviu
Re: A question (or two) of procedure, etc.
On Sep 7, 2012, at 7:26 AM, Jim Jagielski wrote: >board@ > > 2. ASF Projects are, well, ASF projects. They are external >adjuncts of corporate projects, Major typo: It should read: They are NOT external adjuncts of corporate projects.
Re: A question (or two) of procedure, etc.
Just a few points: 1. No single individual can "make a process more formal". If the project itself wants more process, and to make it more formal, then all is good. If a single committer decides on his/her own to add process *which is not formally required by the ASF* then committers are free to discuss and even ignore that process. If in doubt, ping others and, eventually, board@ 2. ASF Projects are, well, ASF projects. They are external adjuncts of corporate projects, and so having processes "flow" into the ASF project due to "requirements" from one's employer is *definitely* a NoNo. With all that said, Martin's process flow is a Good One and should the PMC decide it is the official procedure to follow, then the project would be the better for it. On Sep 6, 2012, at 10:36 PM, Martin Sebor wrote: > Anyone is welcome to express their opinion here, especially > if you are or have in the past contributed to the project. > The weight of the opinion is (or should be) commensurate to > the value of the contributions. I think the ASF calls this > Meritocracy. > > I made the stdcxx process increasingly more formal as I learned > from my own past mistakes that a loose process makes it harder > to track changes and find the root cause of the problems they > sometimes introduce. In practical terms, I've made an effort > to have an issue, with a test case if possible, for every > change made to the code, and commit a regression test into > the test suite for every bug fix. > > FWIW, in my day to day job, this is a requirement. Cisco > doesn't make a change to its code without an issue. My team > does the same with GCC changes. We find that projects that > don't follow this practice as closely (e.g., GNU Binutils), > tend to be more difficult for us to work with than those > that do. > > That being said, when it comes to the stdcxx configuration > machinery, or to the test suite, I think it's fine to be > somewhat less formal. We don't need test cases for problems > in configuration tests, or necessarily even test cases > reproducing failures in library tests (although small tests > can often be more useful than the large tests we have in > the test suite). We also don't need tests for makefile bugs. > Outside of that, when it comes to changing the library, I > do recommend making an effort to create test cases and open > issues for all changes. > > Martin > > On 09/06/2012 12:37 PM, Wojciech Meyer wrote: >> Liviu Nicoara writes: >> >>> What is the latest policy in what regards trivial fixes, e.g., the >>> volatile qualifier for the max var in LIMITS.cpp we discussed earlier, >>> etc.? It seems excessive to create a bug report for such issues. >> >> My advice based on some observations with other projects, is that in >> these cases we go just go on and apply fix. Non invasive code quality >> improvements over the codebase should be promoted not hindered. More >> risky patches, should be discussed on the list, the ones that needs >> either serious changes, attention, re-factoring, feature or fixes that >> may break something should be logged in Jira. >> >> So I vote for keeping the changes as lightweight as possible, and avoid >> extra bureaucracy if it makes sense. This assumption is based that >> developers here trust their selves, and run the tests often. I'm not >> subscribed to the commit list here, but if I do - I usually follow >> people's changes and assume that developers do read commit lists. >> >> So the general consensus from my experience with other project was: not >> sure - ask. >> >> That's my experience, also I don't have full rights to express my >> opinion right now about stdcxx. >> >>> Also, IIUC from reading previous discussions, forward and backward >>> binary compatible changes go in 4.2.x, followed by merges to 4.3.x and >>> trunk. Am I getting this right? >> >> Every project has certain branch strategy, I'm not sure about this so >> maybe Martin can advice. I prefer to develop on trunk and cherry pick >> to the other branches avoiding bulk merges (and that's in both >> directions). >> >>> >>> Also, besides the Linux, FreeBSD, Windows, Solaris builds hosted on Apache >>> (Jenkins) is anybody building on HP-UX, AIX, etc.? >>> >>> Thanks. >>> >>> Liviu >>> >> >> -- >> Wojciech Meyer >> http://danmey.org >
