Problem using ofstream in C++ class in package for MacOS X
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?
or
output << "21";
or
output << 21 << endl;
or
#include <string>
string s("21");
output << s;
?
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?
2) Are your environments (e.g., environment variables) the same?
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.
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