You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2007/10/15 02:37:31 UTC
4.2.0-rc-6, final candidate
After dispatching the remaining issues scheduled for 4.2.0(*) I'd
like to merge the few outstanding minor fixes and docs changes to
4.2.0 and create the (hopefully) final release candidate at the
end of the day (US/Mountain) tomorrow. If anyone has any concerns
please raise them ASAP.
[*] Here's a list of the remaining issues to deal with:
http://tinyurl.com/2g7hv8
Andrew and Farid, you each have an issue on the list assigned to
you. Please try to resolve them before the end of business tomorrow.
I'll take care of the rest (I'll need to spend some time reworking
the patch for STDCXX-509 so that it's binary compatible. If I can
fix STDCXX-406 and STDCXX-302 in isolation from other platforms
I will, otherwise I'll defer it to 4.2.1 with the effect of
Compaq/HP C++ not being supported on Tru64 in 4.2.0).
Thanks
Martin
Re: 4.2.0-rc-6, final candidate
Posted by Martin Sebor <se...@roguewave.com>.
I'm afraid I'm not quite done with all my issues, most notably
with STDCXX-509 (although I have committed a partial solution,
I still need to cook something up for MSVC). I'm hoping to get
things wrapped up and have the candidate by the end of tomorrow.
Martin
Martin Sebor wrote:
> After dispatching the remaining issues scheduled for 4.2.0(*) I'd
> like to merge the few outstanding minor fixes and docs changes to
> 4.2.0 and create the (hopefully) final release candidate at the
> end of the day (US/Mountain) tomorrow. If anyone has any concerns
> please raise them ASAP.
>
> [*] Here's a list of the remaining issues to deal with:
> http://tinyurl.com/2g7hv8
>
> Andrew and Farid, you each have an issue on the list assigned to
> you. Please try to resolve them before the end of business tomorrow.
> I'll take care of the rest (I'll need to spend some time reworking
> the patch for STDCXX-509 so that it's binary compatible. If I can
> fix STDCXX-406 and STDCXX-302 in isolation from other platforms
> I will, otherwise I'll defer it to 4.2.1 with the effect of
> Compaq/HP C++ not being supported on Tru64 in 4.2.0).
>
> Thanks
> Martin
RE: 4.2.0-rc-6, final candidate
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Farid Zaripov [mailto:Farid_Zaripov@epam.com]
> Sent: Tuesday, October 16, 2007 6:24 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: RE: 4.2.0-rc-6, final candidate
>
> > -----Original Message-----
> > From: Martin Sebor [mailto:sebor@roguewave.com]
> > Sent: Tuesday, October 16, 2007 5:52 PM
> > To: stdcxx-dev@incubator.apache.org
> > Subject: Re: 4.2.0-rc-6, final candidate
>
> > Out of curiosity, how do you test this? (I tested by building
> > 4.1.3 examples, replacing the 4.1.3 shared lib with symlinks to the
> > one from 4.2.0, and running them.)
>
> I've built 15s configuration (replaced the old static
> library by the new from 4.2.0).
>
> Now I'm checking the dynamic build (15d).
The same problem (invoking dtor instead of what()) in 15d
(i've just replaced stdlib15d.dll to libstd15d.dll from 4.2.0).
Farid.
RE: 4.2.0-rc-6, final candidate
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, October 16, 2007 9:19 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: 4.2.0-rc-6, final candidate
>
> Farid Zaripov wrote:
> >> -----Original Message-----
> >> From: Martin Sebor [mailto:sebor@roguewave.com]
> >> Sent: Tuesday, October 16, 2007 5:52 PM
> >> To: stdcxx-dev@incubator.apache.org
> >> Subject: Re: 4.2.0-rc-6, final candidate
> >
> >> Out of curiosity, how do you test this? (I tested by building
> >> 4.1.3 examples, replacing the 4.1.3 shared lib with
> symlinks to the
> >> one from 4.2.0, and running them.)
> >
> > I've built 15s configuration (replaced the old static
> library by the
> > new from 4.2.0).
> >
> > Now I'm checking the dynamic build (15d).
>
> Since 4.1.3 doesn't build with MSVC 8.0 I assume you were
> using MSVC 7.1 for both 4.1.3 and 4.2.0 in your tests, yes?
Correct.
Farid.
Re: 4.2.0-rc-6, final candidate
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Tuesday, October 16, 2007 5:52 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: 4.2.0-rc-6, final candidate
>
>> Out of curiosity, how do you test this? (I tested by building
>> 4.1.3 examples, replacing the 4.1.3 shared lib with symlinks
>> to the one from 4.2.0, and running them.)
>
> I've built 15s configuration (replaced the old static library by the
> new from 4.2.0).
>
> Now I'm checking the dynamic build (15d).
Since 4.1.3 doesn't build with MSVC 8.0 I assume you were using
MSVC 7.1 for both 4.1.3 and 4.2.0 in your tests, yes?
Martin
RE: 4.2.0-rc-6, final candidate
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, October 16, 2007 6:32 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: 4.2.0-rc-6, final candidate
>
> Farid Zaripov wrote:
> >> -----Original Message-----
> >> From: Martin Sebor [mailto:sebor@roguewave.com]
> >> Sent: Tuesday, October 16, 2007 5:52 PM
> >> To: stdcxx-dev@incubator.apache.org
> >> Subject: Re: 4.2.0-rc-6, final candidate
> >
> >> Out of curiosity, how do you test this? (I tested by building
> >> 4.1.3 examples, replacing the 4.1.3 shared lib with
> symlinks to the
> >> one from 4.2.0, and running them.)
> >
> > I've built 15s configuration (replaced the old static
> library by the
> > new from 4.2.0).
>
> I see. So you compiled with 4.1.3 headers but linked with the
> 4.2.0 archive, correct? That's a useful test as well.
Yes. I've just replaced the .lib file and relinked the example without
recompiling.
Farid.
Re: 4.2.0-rc-6, final candidate
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Tuesday, October 16, 2007 5:52 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: 4.2.0-rc-6, final candidate
>
>> Out of curiosity, how do you test this? (I tested by building
>> 4.1.3 examples, replacing the 4.1.3 shared lib with symlinks
>> to the one from 4.2.0, and running them.)
>
> I've built 15s configuration (replaced the old static library by the
> new from 4.2.0).
I see. So you compiled with 4.1.3 headers but linked with
the 4.2.0 archive, correct? That's a useful test as well.
>
> Now I'm checking the dynamic build (15d).
That's what I've been testing with it, too.
We need to come up with an automated way to do these tests.
Martin
RE: 4.2.0-rc-6, final candidate
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, October 16, 2007 5:52 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: 4.2.0-rc-6, final candidate
> Out of curiosity, how do you test this? (I tested by building
> 4.1.3 examples, replacing the 4.1.3 shared lib with symlinks
> to the one from 4.2.0, and running them.)
I've built 15s configuration (replaced the old static library by the
new from 4.2.0).
Now I'm checking the dynamic build (15d).
Farid.
Re: 4.2.0-rc-6, final candidate
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Farid Zaripov [mailto:Farid_Zaripov@epam.com]
>> Sent: Tuesday, October 16, 2007 5:39 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: RE: 4.2.0-rc-6, final candidate
>>
>>> -----Original Message-----
>>> From: Martin Sebor [mailto:sebor@roguewave.com]
>>> Sent: Tuesday, October 16, 2007 4:38 PM
>>> To: stdcxx-dev@incubator.apache.org
>>> Subject: Re: 4.2.0-rc-6, final candidate
>>>
>>>> Regarding binary compatibility, after upgrading from 4.1.3 to the
>>>> latest 4.2.0 I'm getting invalid pointer errors from glibc
>>> in some of
>>>> my programs. I reproduced the same error in the except example in
>>>> 4.1.3. Unfortunately, I don't have time to debug it right now.
>>> Yowza! That's not good. We not fix that ASAP. Farid, could any of
>>> these changes be causing the incompatibility?
>>>
>>> http://svn.apache.org/viewvc?view=rev&revision=549766
>>> http://svn.apache.org/viewvc?view=rev&revision=549586
>>> http://svn.apache.org/viewvc?view=rev&revision=549584
>> I have checked the except.cpp example on MSVC 7.1 and found
>> that the problem was caused by this change:
>> http://svn.apache.org/viewvc?rev=583667&view=rev
>>
>
> Sorry, I've tested with trunk but not with 4.2.0.
There isn't (shouldn't be) much of a difference between the two
as far as the library goes. Except for the (partially) binary
compatible fix for STDCXX-509 that's on the branch and that
wasn't on trunk until a few seconds ago, the are (should be)
the same.
Out of curiosity, how do you test this? (I tested by building
4.1.3 examples, replacing the 4.1.3 shared lib with symlinks
to the one from 4.2.0, and running them.)
Martin
RE: 4.2.0-rc-6, final candidate
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Farid Zaripov [mailto:Farid_Zaripov@epam.com]
> Sent: Tuesday, October 16, 2007 5:43 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: RE: 4.2.0-rc-6, final candidate
>
> > -----Original Message-----
> > From: Farid Zaripov [mailto:Farid_Zaripov@epam.com]
> > Sent: Tuesday, October 16, 2007 5:39 PM
> > To: stdcxx-dev@incubator.apache.org
> > Subject: RE: 4.2.0-rc-6, final candidate
> >
> > > -----Original Message-----
> > > From: Martin Sebor [mailto:sebor@roguewave.com]
> > > Sent: Tuesday, October 16, 2007 4:38 PM
> > > To: stdcxx-dev@incubator.apache.org
> > > Subject: Re: 4.2.0-rc-6, final candidate
> > >
> > > > Regarding binary compatibility, after upgrading from
> 4.1.3 to the
> > > > latest 4.2.0 I'm getting invalid pointer errors from glibc
> > > in some of
> > > > my programs. I reproduced the same error in the except
> example in
> > > > 4.1.3. Unfortunately, I don't have time to debug it right now.
> > >
> > > Yowza! That's not good. We not fix that ASAP. Farid, could any of
> > > these changes be causing the incompatibility?
> > >
> > > http://svn.apache.org/viewvc?view=rev&revision=549766
> > > http://svn.apache.org/viewvc?view=rev&revision=549586
> > > http://svn.apache.org/viewvc?view=rev&revision=549584
> >
> > I have checked the except.cpp example on MSVC 7.1 and
> found that the
> > problem was caused by this change:
> > http://svn.apache.org/viewvc?rev=583667&view=rev
> >
>
> Sorry, I've tested with trunk but not with 4.2.0.
The same problem in 4.2.0, because the r583667 was merged thus:
http://svn.apache.org/viewvc?rev=584965&view=rev
Farid.
RE: 4.2.0-rc-6, final candidate
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Farid Zaripov [mailto:Farid_Zaripov@epam.com]
> Sent: Tuesday, October 16, 2007 5:39 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: RE: 4.2.0-rc-6, final candidate
>
> > -----Original Message-----
> > From: Martin Sebor [mailto:sebor@roguewave.com]
> > Sent: Tuesday, October 16, 2007 4:38 PM
> > To: stdcxx-dev@incubator.apache.org
> > Subject: Re: 4.2.0-rc-6, final candidate
> >
> > > Regarding binary compatibility, after upgrading from 4.1.3 to the
> > > latest 4.2.0 I'm getting invalid pointer errors from glibc
> > in some of
> > > my programs. I reproduced the same error in the except example in
> > > 4.1.3. Unfortunately, I don't have time to debug it right now.
> >
> > Yowza! That's not good. We not fix that ASAP. Farid, could any of
> > these changes be causing the incompatibility?
> >
> > http://svn.apache.org/viewvc?view=rev&revision=549766
> > http://svn.apache.org/viewvc?view=rev&revision=549586
> > http://svn.apache.org/viewvc?view=rev&revision=549584
>
> I have checked the except.cpp example on MSVC 7.1 and found
> that the problem was caused by this change:
> http://svn.apache.org/viewvc?rev=583667&view=rev
>
Sorry, I've tested with trunk but not with 4.2.0.
Farid.
Re: 4.2.0-rc-6, final candidate
Posted by Martin Sebor <se...@roguewave.com>.
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Tuesday, October 16, 2007 4:38 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: 4.2.0-rc-6, final candidate
>>
>>> Regarding binary compatibility, after upgrading from 4.1.3 to the
>>> latest 4.2.0 I'm getting invalid pointer errors from glibc
>> in some of
>>> my programs. I reproduced the same error in the except example in
>>> 4.1.3. Unfortunately, I don't have time to debug it right now.
>> Yowza! That's not good. We not fix that ASAP. Farid, could
>> any of these changes be causing the incompatibility?
>>
>> http://svn.apache.org/viewvc?view=rev&revision=549766
>> http://svn.apache.org/viewvc?view=rev&revision=549586
>> http://svn.apache.org/viewvc?view=rev&revision=549584
>
> I have checked the except.cpp example on MSVC 7.1 and found
> that the problem was caused by this change:
> http://svn.apache.org/viewvc?rev=583667&view=rev
>
> ----------------
> catch (const std::ios::failure &e) {
> std::cout << "Caught an exception: " << e.what () << std::endl;
> }
> ----------------
>
> Here instead std::exception::what() invoked
> std::ios::failure::~failure().
Oh, crud! I was afraid this would cause problems but it didn't
occurr to me that switching the order of virtual functions is
a binary incompatible change. Makes sense. Doh!
Okay, thanks a lot for looking into it, I'll work on a fix.
I think the safe thing to do will be to enable the change
just for Darwin and leave it the way it was for all other
platforms.
Martin
RE: 4.2.0-rc-6, final candidate
Posted by Farid Zaripov <Fa...@epam.com>.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, October 16, 2007 4:38 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: 4.2.0-rc-6, final candidate
>
> > Regarding binary compatibility, after upgrading from 4.1.3 to the
> > latest 4.2.0 I'm getting invalid pointer errors from glibc
> in some of
> > my programs. I reproduced the same error in the except example in
> > 4.1.3. Unfortunately, I don't have time to debug it right now.
>
> Yowza! That's not good. We not fix that ASAP. Farid, could
> any of these changes be causing the incompatibility?
>
> http://svn.apache.org/viewvc?view=rev&revision=549766
> http://svn.apache.org/viewvc?view=rev&revision=549586
> http://svn.apache.org/viewvc?view=rev&revision=549584
I have checked the except.cpp example on MSVC 7.1 and found
that the problem was caused by this change:
http://svn.apache.org/viewvc?rev=583667&view=rev
----------------
catch (const std::ios::failure &e) {
std::cout << "Caught an exception: " << e.what () << std::endl;
}
----------------
Here instead std::exception::what() invoked
std::ios::failure::~failure().
Farid.
Re: 4.2.0-rc-6, final candidate
Posted by Martin Sebor <se...@roguewave.com>.
Mark Brown wrote:
> Martin Sebor wrote:
>> After dispatching the remaining issues scheduled for 4.2.0(*) I'd
>> like to merge the few outstanding minor fixes and docs changes to
>> 4.2.0 and create the (hopefully) final release candidate at the
>> end of the day (US/Mountain) tomorrow. If anyone has any concerns
>> please raise them ASAP.
>>
>> [*] Here's a list of the remaining issues to deal with:
>> http://tinyurl.com/2g7hv8
>>
>> Andrew and Farid, you each have an issue on the list assigned to
>> you. Please try to resolve them before the end of business tomorrow.
>> I'll take care of the rest (I'll need to spend some time reworking
>> the patch for STDCXX-509 so that it's binary compatible. If I can
>> fix STDCXX-406 and STDCXX-302 in isolation from other platforms
>> I will, otherwise I'll defer it to 4.2.1 with the effect of
>> Compaq/HP C++ not being supported on Tru64 in 4.2.0).
>>
>
> Regarding binary compatibility, after upgrading from 4.1.3 to
> the latest 4.2.0 I'm getting invalid pointer errors from glibc
> in some of my programs. I reproduced the same error in the
> except example in 4.1.3. Unfortunately, I don't have time to
> debug it right now.
Yowza! That's not good. We not fix that ASAP. Farid, could any
of these changes be causing the incompatibility?
http://svn.apache.org/viewvc?view=rev&revision=549766
http://svn.apache.org/viewvc?view=rev&revision=549586
http://svn.apache.org/viewvc?view=rev&revision=549584
Martin
>
> -- Mark
>
> $ LD_LIBRARY_PATH=../lib ./except
> *** glibc detected *** ./except: munmap_chunk(): invalid pointer:
> 0x0000000000602110 ***
> ======= Backtrace: =========
> /lib64/libc.so.6(cfree+0x1b6)[0x3571a72c56]
> ../lib/libstd15D.so(_ZN4__rw15__rw_eofbit_setD0Ev+0x39)[0x2aaaaab072dd]
> ./except(__gxx_personality_v0+0x2a0)[0x4010c0]
> /lib64/libc.so.6(__libc_start_main+0xf4)[0x3571a1d8a4]
> ./except(__gxx_personality_v0+0xe9)[0x400f09]
> ======= Memory map: ========
> 00400000-00402000 r-xp 00000000 08:02 22415427
> /home/mbrown/stdcxx-4.1.3-gcc-4.1.2-15D/examples/except
> 00601000-00602000 rw-p 00001000 08:02 22415427
> /home/mbrown/stdcxx-4.1.3-gcc-4.1.2-15D/examples/except
> 00602000-00623000 rw-p 00602000 00:00 0 [heap]
> 3571600000-357161a000 r-xp 00000000 08:02 17006839 /lib64/ld-2.5.so
> 3571819000-357181a000 r--p 00019000 08:02 17006839 /lib64/ld-2.5.so
> 357181a000-357181b000 rw-p 0001a000 08:02 17006839 /lib64/ld-2.5.so
> 3571a00000-3571b46000 r-xp 00000000 08:02 17006871 /lib64/libc-2.5.so
> 3571b46000-3571d46000 ---p 00146000 08:02 17006871 /lib64/libc-2.5.so
> 3571d46000-3571d4a000 r--p 00146000 08:02 17006871 /lib64/libc-2.5.so
> 3571d4a000-3571d4b000 rw-p 0014a000 08:02 17006871 /lib64/libc-2.5.so
> 3571d4b000-3571d50000 rw-p 3571d4b000 00:00 0
> 3571e00000-3571e82000 r-xp 00000000 08:02 17006891 /lib64/libm-2.5.so
> 3571e82000-3572081000 ---p 00082000 08:02 17006891 /lib64/libm-2.5.so
> 3572081000-3572082000 r--p 00081000 08:02 17006891 /lib64/libm-2.5.so
> 3572082000-3572083000 rw-p 00082000 08:02 17006891 /lib64/libm-2.5.so
> 3574a00000-3574a15000 r-xp 00000000 08:02 17006887
> /lib64/libpthread-2.5.so
> 3574a15000-3574c14000 ---p 00015000 08:02 17006887
> /lib64/libpthread-2.5.so
> 3574c14000-3574c15000 r--p 00014000 08:02 17006887
> /lib64/libpthread-2.5.so
> 3574c15000-3574c16000 rw-p 00015000 08:02 17006887
> /lib64/libpthread-2.5.so
> 3574c16000-3574c1a000 rw-p 3574c16000 00:00 0
> 357ec00000-357ec0d000 r-xp 00000000 08:02 17006830
> /lib64/libgcc_s-4.1.2-20070626.so.1
> 357ec0d000-357ee0d000 ---p 0000d000 08:02 17006830
> /lib64/libgcc_s-4.1.2-20070626.so.1
> 357ee0d000-357ee0e000 rw-p 0000d000 08:02 17006830
> /lib64/libgcc_s-4.1.2-20070626.so.1
> 2aaaaaaab000-2aaaaaaad000 rw-p 2aaaaaaab000 00:00 0
> 2aaaaaaad000-2aaaaabbc000 r-xp 00000000 08:02 22414809
> /home/mbrown/stdcxx-4.2.0-gcc-4.1.2-15D/lib/libstd15D.so.4.2.0
> 2aaaaabbc000-2aaaaadbb000 ---p 0010f000 08:02 22414809
> /home/mbrown/stdcxx-4.2.0-gcc-4.1.2-15D/lib/libstd15D.so.4.2.0
> 2aaaaadbb000-2aaaaadc5000 rw-p 0010e000 08:02 22414809
> /home/mbrown/stdcxx-4.2.0-gcc-4.1.2-15D/lib/libstd15D.so.4.2.0
> 2aaaaadc5000-2aaaaaddc000 rw-p 2aaaaadc5000 00:00 0
> 2aaaaadf7000-2aaaaadfb000 rw-p 2aaaaadf7000 00:00 0
> 7fff6350a000-7fff6351f000 rwxp 7fff6350a000 00:00 0 [stack]
> ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso]
> Aborted
Re: 4.2.0-rc-6, final candidate
Posted by Mark Brown <ma...@gmail.com>.
Martin Sebor wrote:
> After dispatching the remaining issues scheduled for 4.2.0(*) I'd
> like to merge the few outstanding minor fixes and docs changes to
> 4.2.0 and create the (hopefully) final release candidate at the
> end of the day (US/Mountain) tomorrow. If anyone has any concerns
> please raise them ASAP.
>
> [*] Here's a list of the remaining issues to deal with:
> http://tinyurl.com/2g7hv8
>
> Andrew and Farid, you each have an issue on the list assigned to
> you. Please try to resolve them before the end of business tomorrow.
> I'll take care of the rest (I'll need to spend some time reworking
> the patch for STDCXX-509 so that it's binary compatible. If I can
> fix STDCXX-406 and STDCXX-302 in isolation from other platforms
> I will, otherwise I'll defer it to 4.2.1 with the effect of
> Compaq/HP C++ not being supported on Tru64 in 4.2.0).
>
Regarding binary compatibility, after upgrading from 4.1.3 to
the latest 4.2.0 I'm getting invalid pointer errors from glibc
in some of my programs. I reproduced the same error in the
except example in 4.1.3. Unfortunately, I don't have time to
debug it right now.
-- Mark
$ LD_LIBRARY_PATH=../lib ./except
*** glibc detected *** ./except: munmap_chunk(): invalid pointer:
0x0000000000602110 ***
======= Backtrace: =========
/lib64/libc.so.6(cfree+0x1b6)[0x3571a72c56]
../lib/libstd15D.so(_ZN4__rw15__rw_eofbit_setD0Ev+0x39)[0x2aaaaab072dd]
./except(__gxx_personality_v0+0x2a0)[0x4010c0]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3571a1d8a4]
./except(__gxx_personality_v0+0xe9)[0x400f09]
======= Memory map: ========
00400000-00402000 r-xp 00000000 08:02 22415427
/home/mbrown/stdcxx-4.1.3-gcc-4.1.2-15D/examples/except
00601000-00602000 rw-p 00001000 08:02 22415427
/home/mbrown/stdcxx-4.1.3-gcc-4.1.2-15D/examples/except
00602000-00623000 rw-p 00602000 00:00 0
[heap]
3571600000-357161a000 r-xp 00000000 08:02 17006839
/lib64/ld-2.5.so
3571819000-357181a000 r--p 00019000 08:02 17006839
/lib64/ld-2.5.so
357181a000-357181b000 rw-p 0001a000 08:02 17006839
/lib64/ld-2.5.so
3571a00000-3571b46000 r-xp 00000000 08:02 17006871
/lib64/libc-2.5.so
3571b46000-3571d46000 ---p 00146000 08:02 17006871
/lib64/libc-2.5.so
3571d46000-3571d4a000 r--p 00146000 08:02 17006871
/lib64/libc-2.5.so
3571d4a000-3571d4b000 rw-p 0014a000 08:02 17006871
/lib64/libc-2.5.so
3571d4b000-3571d50000 rw-p 3571d4b000 00:00 0
3571e00000-3571e82000 r-xp 00000000 08:02 17006891
/lib64/libm-2.5.so
3571e82000-3572081000 ---p 00082000 08:02 17006891
/lib64/libm-2.5.so
3572081000-3572082000 r--p 00081000 08:02 17006891
/lib64/libm-2.5.so
3572082000-3572083000 rw-p 00082000 08:02 17006891
/lib64/libm-2.5.so
3574a00000-3574a15000 r-xp 00000000 08:02 17006887
/lib64/libpthread-2.5.so
3574a15000-3574c14000 ---p 00015000 08:02 17006887
/lib64/libpthread-2.5.so
3574c14000-3574c15000 r--p 00014000 08:02 17006887
/lib64/libpthread-2.5.so
3574c15000-3574c16000 rw-p 00015000 08:02 17006887
/lib64/libpthread-2.5.so
3574c16000-3574c1a000 rw-p 3574c16000 00:00 0
357ec00000-357ec0d000 r-xp 00000000 08:02 17006830
/lib64/libgcc_s-4.1.2-20070626.so.1
357ec0d000-357ee0d000 ---p 0000d000 08:02 17006830
/lib64/libgcc_s-4.1.2-20070626.so.1
357ee0d000-357ee0e000 rw-p 0000d000 08:02 17006830
/lib64/libgcc_s-4.1.2-20070626.so.1
2aaaaaaab000-2aaaaaaad000 rw-p 2aaaaaaab000 00:00 0
2aaaaaaad000-2aaaaabbc000 r-xp 00000000 08:02 22414809
/home/mbrown/stdcxx-4.2.0-gcc-4.1.2-15D/lib/libstd15D.so.4.2.0
2aaaaabbc000-2aaaaadbb000 ---p 0010f000 08:02 22414809
/home/mbrown/stdcxx-4.2.0-gcc-4.1.2-15D/lib/libstd15D.so.4.2.0
2aaaaadbb000-2aaaaadc5000 rw-p 0010e000 08:02 22414809
/home/mbrown/stdcxx-4.2.0-gcc-4.1.2-15D/lib/libstd15D.so.4.2.0
2aaaaadc5000-2aaaaaddc000 rw-p 2aaaaadc5000 00:00 0
2aaaaadf7000-2aaaaadfb000 rw-p 2aaaaadf7000 00:00 0
7fff6350a000-7fff6351f000 rwxp 7fff6350a000 00:00 0
[stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0
[vdso]
Aborted