* On 30.10.2011 11:18 PM, Jonathan Wakely wrote: > On 30 October 2011 21:10, Mihai Moldovan <ionic@xxxxxxxx> wrote: >> * On 30.10.2011 09:56 PM, Jonathan Wakely wrote: >>> On 30 October 2011 20:42, Mihai Moldovan wrote: >>>> * On 30.10.2011 09:24 PM, Jonathan Wakely wrote: >>>>> On 30 October 2011 19:25, Mihai Moldovan wrote: >>>>>> As the first paste in http://trac.macports.org/ticket/27237#comment:14 >>>>>> suggests (extracted from new_allocator.h:98), __p should be permitted to >>>>>> be a null pointer.. which... well, is clearly not the case here for some >>>>>> reason. >>>>> Calling delete on a null pointer is permitted, but passing a null >>>>> pointer to that allocator's deallocate function is not. Which is it? >>>> Did you have a look at the paste? new_allocator.h:98 is "{ ::operator >>>> delete(__p); }" which is the deallocate function, yep. >>> That's ok to call with a null pointer then, operator delete can be >>> called with a null pointer. >>> >>> From another trac comment: >>> >>> Breakpoint 9, std::string::assign (this=0x101777fa8, __str=<value >>> temporarily unavailable, due to optimizations>) at new_allocator.h:98 >>> 98 { ::operator delete(__p); } >>> (gdb) print __p >>> Cannot access memory at address 0x0 >>> >>> >>> That doesn't look like __p is null to me, I would expect it to print >>> 0x0 for a null pointer: >>> >>> (gdb) print __p >>> $1 = 0x0 >> Yeah, delete can be called on a null pointer, but free shouldn't, or am >> I messing something up? > No, free(0) isn't valid, but operator delete won't call free if the > pointer is null. > >> On the other hand, why would free() crash if __p was not null? It may >> have been previously free'd but... I don't see that happening. > Really? > ld(39160) malloc: *** error for object 0x100285640: pointer being > freed was not allocated > > That looks like an invalid pointer to me. > >> Still, something weird is happening here and the GCC build system >> shouldn't try to use the new stdlibc++, I wonder why and how it tries to >> in the first place. > I don't understand what you mean, or what you mean by preloading in > the trac report. By preloading I actually mean forcing the linker to use the new libstdc++. > If ld can't be linked with your new libstdc++ then it is probably due > to an ABI compatibility. My guess would be something to do with > fully-dynamic-string but you claim that's being used correctly. How > was the system libstdc++ configured? How are you configuring your gcc > builds? I suspect that too, but the build system should really not force the libstdc++ on ld, or things like that may happen. If I interpret www.ionic.de/libstdc++3.diff correctly (diff between GCC 4.5.3 and GCC 4.6.2 libstdc++ with some fuzzyness), the ABI version changed from 6 to 7. Commonly this happens on breaking ABI changes. However, even though GCC 4.5.3 libstdc++ had ABI version 6, it can't be used by ld either, so there is definitely some incompatibility. Configure line: ../gcc-4.6.1/configure --prefix=/opt/local --build=x86_64-apple-darwin10 --enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/opt/local/lib/gcc46 --includedir=/opt/local/include/gcc46 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.6 --with-local-prefix=/opt/local --with-libiconv-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.6 --with-gxx-include-dir=/opt/local/include/gcc46/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --enable-stage1-checking --disable-multilib --enable-fully-dynamic-string I'll try to rebuild with --disable-fully-dynamic-string, but per http://newartisans.com/2009/10/a-c-gotcha-on-snow-leopard/ I assume this feature is used in the libc and thus cause even more problems then it solves.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
