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 <[EMAIL PROTECTED]> 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?
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
