[Rd] Problem using ofstream in C++ class in package for MacOS X

[cstrato]

Ross Boylan wrote:
> On Thu, Feb 08, 2007 at 10:04:14PM +0100, cstrato wrote:
>   
>> Ross Boylan wrote:
>>     
>>> On Sun, Feb 04, 2007 at 10:47:37PM +0100, cstrato wrote:
>>>  
>>>       
>>>> Seth Falcon wrote:
>>>>    
>>>>         
>>>>> cstrato <cstrato at aon.at> writes:
>>>>>  
>>>>>      
>>>>>           
>>>>>> Thank you for your fast answer.
>>>>>> Sorrowly, I don´t know how to use a debugger on MacOS X, I am using 
>>>>>> old-style print commands.
>>>>>>    
>>>>>>        
>>>>>>             
>>>>> You should be able to use gdb on OS X (works for me, YMMV).  So you
>>>>> could try:
>>>>>
>>>>>      R -d gdb
>>>>>      run
>>>>>      # source a script that causes crash
>>>>>      # back in gdb, use backtrace, etc.
>>>>>
>>>>> + seth
>>>>>
>>>>>
>>>>>  
>>>>>      
>>>>>           
>>>> Dear Seth
>>>>
>>>> Thank you for this tip, I just tried it and here is the result:
>>>>
>>>> Welcome to MyClass
>>>>         
>>>>> writeFileCpp("myout_fileCpp.txt")
>>>>>           
>>>> [1] "outfile =  myout_fileCpp.txt"
>>>> Writing file myout_fileCpp.txt using C++ style.
>>>> ---MyClassA::MyClassA()---------
>>>> ---MyClassA::WriteFileCpp---------
>>>>
>>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000006
>>>> 0x020fe231 in std::ostream::flush (this=0x214f178) at 
>>>> /Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc:395
>>>> 395     
>>>> /Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc: 
>>>> No such file or directory.
>>>>        in 
>>>> /Builds/unix/o403/i686-apple-darwin8/libstdc++-v3/include/bits/ostream.tcc
>>>> (gdb)
>>>>
>>>> It seems that it cannot find ostream.tcc, whatever this extension means.
>>>>
>>>> Best regards
>>>> Christian
>>>>    
>>>>         
>>> I also don't see what the problem is, but have a couple of thoughts.
>>> Under OS-X there is an environment variable you can define to get the
>>> dynamic linker to load debug versions of libraries.  I can't remember
>>> what it is, but maybe something like DYLD_DEBUG (but probably DEBUG is
>>> part of the value of the variable).
>>>
>>> For that, or the tracing above, to be fully informative you need to
>>> have installed the appropriate debugging libraries and sources.
>>>
>>> You may need to set an explicit source search path in gdb to pick up
>>> the source files.
>>>
>>> Try stepping through the code from write before the crash to determine
>>> exactly where it runs into trouble.
>>>
>>> Does the output file you are trying to create exist?
>>>
>>> Unfortunately, none of this really gets at your core bug, but it might
>>> help track it down.
>>>
>>> Ross
>>>
>>>
>>>  
>>>       
>> Dear Ross
>>
>> Thank you, my problem is that I know exactly where the problem is but 
>> not how to solve it.
>>
>> I have installed R-2.4.1 on three different machines to test the package:
>> - Intel-Laptop running Fedora Core 4:         package is OK
>> - PPC-PowerBook Titanium OS X 10.4.4:         package is OK
>> - Intel-MacBook Pro Core 2 Duo OS X 10.4.8:   C output OK, C++ output 
>> crashes R
>>
>> The following code in method WriteFileCpp() works, but gives no result:
>> {
>>  std::ofstream output(outfile);
>>  output.close();
>> }
>>
>> The following code in method WriteFileCpp() crashes R:
>> {
>>  std::ofstream output(outfile);
>>  output << "21" << endl;
>>  output.close();
>> }
>>
>> It seems that on the Intel-MacBook Pro the operator "<<" is not 
>> recognized, when called from within my package in R.
>> In contrast, when compiled as a C++ library, the same code does work on 
>> my Intel-Mac!
>>
>> Best regards
>> Christian
>>
>>
>>     
> Knowing the line isn't as specific as knowing exactly where it was
> when it crashed.
>
> Your stack trace was
> Thread 0 Crashed:
> 0   libstdc++.6.dylib     0x020fe231 std::basic_ostream<char,
> std::char_traits<char> >::flush() + 17 (ostream.tcc:395)
> 1   libstdc++.6.dylib     0x020fe358 std::basic_ostream<char,
> std::char_traits<char>
>  >::sentry::sentry[in-charge](std::basic_ostream<char,
> std::char_traits<char> >&) + 120 (ostream.tcc:56)
> 2   libstdc++.6.dylib     0x02100b5d std::basic_ostream<char,
> std::char_traits<char> >& std::operator<< <std::char_traits<char>
>  >(std::basic_ostream<char, std::char_traits<char> >&, char const*) + 29
> (ostream.tcc:620)
> 3   MyClass.so            0x0004a30f MyClassA::WriteFileCpp(char const*)
> which doesn't look as if the problem is that << isn't recognized.
> What is the thing that was at address 0x06?
>
> The flush is probably from the endl.  If you traced it through, you
> could tell if the first << completed.
>
> Does
>  output << endl;
> work?
>   
Does not work!
> or
>  output << "21";
>   
Does not work!
> or
>  output << 21 << endl;
>   
Does not work!
> or
>  #include <string>
>  string s("21");
>  output << s;
> ?
>   
Does work!  Even
"output << s << endl;"
works, but the outfile is empty!
> The different fates of the two OS-X platforms is certainly vexing.
> These are all shots in the dark, but
> 1) Was the complete system (i.e., R as well as your code) built with
> the the toolchain on both platforms?
>   
Yes
> 2) Are your environments (e.g., environment variables) the same?
>   
Yes
> 3) The recommended way to build stuff that will be talking to R is
> with R CMD config.  Check first if that gives the same results on both
> systems, and second if your build is using them.
>   
Not tested yet
> 4) Maybe some dylib (e.g., stdc++) is not getting initialized
> properly.
>
> Maybe there's some subtle linker problem, or a problem with the
> representation of strings
>
>
>   
What do you mean with linker problem?