Re: build trouble on MacOS 10.5

[Ben Abbott]

On Dec 20, 2009, at 1:58 PM, Ben Abbott wrote:

> On Dec 20, 2009, at 1:29 PM, Ben Abbott wrote:
> 
>> On Dec 20, 2009, at 12:30 PM, Rob Mahurin wrote:
>> 
>>> On Sat, Dec 19, 2009 at 11:52:45PM -0500, Ben Abbott wrote:
>>>> I've assumed the bus error is a result of conflicting dylibs. Thus,
>>>> I wrote a simple script to list those being linked to so that I may
>>>> visually inspect them for conflicts.
>>>> 
>>>> For 10.6.2 I see conflicts for libiconv, libfontconfig, and
>>>> libfreetype (maybe others as well, but I'm done looking today).
>>>> 
>>>> Perhaps we can eliminate suspects by comparing results?
>>>> 
>>>> For comparison, I've included my result.
>>> 
>>> Here's my output from your script.  How should I interpret this?
>>> 
>>> Rob
>>> <dylib_output.txt>
>> 
>> My understanding is that conflicting version of libraries are a problem. If 
>> I include FLTK in my build, I have libstdc++.dylib from both gcc 4.2.1 and 
>> gcc 4.4.2 ... which *might* create troubles, but that does not appear to be 
>> my problem (or yours).
>> 
>> You are linking against libgcc_s.1.dylib from Apple's gcc 4.0.2 (?) and 
>> MacPorts gcc 4.3.? ... while I'm linking against Apples gcc 4.2.1 and Finks 
>> gcc 4.4.2. 
>> 
>> I'm not expert in interpreting the back trace, but if I understand correctly 
>> ...
>> 
>>      http://www.caf.dk/cafonly/gnu/gdb/gdb_42.html
>> 
>> ... the bus error for your occurs in 
>> 
>>      #0  0x03ca4156 in __gnu_cxx::__exchange_and_add ()
>>      #1  0x03c48526 in std::locale::operator= ()
>> 
>> ... and for me, in close proximity to your example 
>> 
>>      #0  0x0282902f in std::locale::operator= ()
>> 
>> I'm not sure what "std::locale::operator= ()" refers to, but I'd guess it is 
>> either libstdc++.6.dylib or maybe libgcc_s.1.dylib. Any thoughts?
>> 
>> Ben
> 
> std::locale does appear to be part of libstdc++
> 
>       
> http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.2/classstd_1_1locale.html
> 
> Since neither of us have conflicting libstdc++ libraries, I think it safe to 
> assume the problem is some where else.
> 
> Ben

With debugging information included, I get the following backtrace

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x02d2602f in std::locale::operator= ()
(gdb) bt
#0  0x02d2602f in std::locale::operator= ()
#1  0x02d24c9e in std::ios_base::_M_init ()
#2  0x02d3a25a in std::basic_ios<char, std::char_traits<char> >::init ()
#3  0x0014f053 in global constructors keyed to pager.cc () at ostream:362
#4  0x8fe0ed6d in 
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE 
()
#5  0x8fe0d31e in 
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#6  0x8fe0d2c2 in 
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#7  0x8fe0d3d1 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE 
()
#8  0x8fe024a9 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#9  0x8fe07950 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#10 0x8fe018b1 in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl ()
#11 0x8fe01057 in __dyld__dyld_start ()

If I understand correctly, the problem is crash is in pager.cc in the lines 
below.

362 void
363 flush_octave_stdout (void)
364 {
365   if (! flushing_output_to_pager)
366     {
367       unwind_protect::frame_id_t uwp_frame = unwind_protect::begin_frame ();
368 
369       unwind_protect::protect_var (really_flush_to_pager);
370       unwind_protect::protect_var (flushing_output_to_pager);
371 
372       really_flush_to_pager = true;
373       flushing_output_to_pager = true;
374 
375       octave_stdout.flush ();
376 
377       clear_external_pager ();
378 
379       unwind_protect::run_frame (uwp_frame);
380     }
381 }

I have no idea is anything useful in this. Anyone?

Ben