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. If you're talking about DYLD_LIBRARY_PATH, I think that has to be set while building the compiler, so the new libstdc++ is used by the new compiler. 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?
