On Thu, 6 Jan 2005, Jeff Squyres wrote:
> This usually happens when the stdc++ libraries are not functioning properly.
>
> Can you run simple C++ programs with std::string?
Yes, I can (see below).
> Does the -D__interface
> switch that you used somehow impact the C++ standard libraries?
I used it because of an error in netinet/in.h with Intel C++ v8.1. See:
http://softwareforums.intel.com/ids/board/message?board.id=16&message.id=2059
> Finally, what's the values of i, size, str[i], and c when mpif77 seg faults?
I played a little with the following code:
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
#include <iostream.h>
#include <string.h>
#include <vector.h>
using namespace std;
bool lam_wrap_split(const string&,char c, vector<string>&);
int main() {
string str = "string";
vector<string> sv;
cout<<str.c_str()<<endl;
int i = str.size();
cout<<"i="<<i<<endl;
sv.push_back(str.substr(0, i-1));
cout<<"i="<<i<<endl;
lam_wrap_split(str,' ',sv);
return 0;
}
bool
lam_wrap_split(const string& str, char c, vector<string>& out)
{
int start, i(0), size(str.size());
out.clear();
// Strip off the first bunch of c's
while (i < size && str[i] == c)
++i;
if (i >= size)
return false;
// Now start making a vector of the strings
while (i < size) {
start = i;
while (i < size && str[i] != c)
++i;
cout <<"lam_wrap_split: i="<< i <<endl;
cout.flush();
out.push_back(str.substr(start, i - start));
cout <<"lam_wrap_split: i="<< i <<endl;
cout <<"str.size()="<<str.size()<<endl;
cout <<"c="<<c<<endl;
cout.flush();
while (i < size && str[i] == c)
++i;
}
return true;
}
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
=1=. With the call to lam_wrap_split() commented out:
[ks] stdc++check_LAM > icpc -Wno-deprecated test.cpp
[ks] stdc++check_LAM > ./a.out
string
i=6
i=6
So, it demonstrates that I can run a C++ prog with std::string. Notice
that the value of i does not change here after a call to
sv.push_back(str.substr()).
=2=. lam_wrap_split() uncommented:
[ks] stdc++check_LAM > icpc -Wno-deprecated test.cpp
[ks] stdc++check_LAM > ./a.out
string
6
6
lam_wrap_split: i=6
Segmentation fault
When compiling with -g flag logic in second inner while cycle works well
and programm terminates normaly. Output shows that the value of i changed
(got corrupted) after the call of "out.push_back(str.substr(start, i -
start));", which must not have happened.
[ks] stdc++check_LAM > icpc -g -Wno-deprecated test.cpp
[ks] stdc++check_LAM > ./a.out
string
6
6
lam_wrap_split: i=6
lam_wrap_split: i=134524312
str.size()=6
c=
Something really weird here with Intel C++ v8.1.
For example, I'm not getting seg fault in LAM's lam_wrap_split() with
gcc's c++.
[ks] stdc++check_LAM > c++ -Wno-deprecated test.cpp
[ks] stdc++check_LAM > ./a.out
string
6
6
lam_wrap_split: i=6
lam_wrap_split: i=6
str.size()=6
c=
OK. I guess that the first solution here is to switch to c++ ...
Regards,
Konstantin
> On Jan 5, 2005, at 10:11 PM, Konstantin Skaburskas wrote:
>
>>
>> Hi,
>>
>> LAM configures, compiles and boots fine but wrapper compilers give
>> setmentation fault (see below).
>>
>> My setup:
>> - glibc 2.3.3-74, Intel Compilers v8.1, Fedora Core 3, kernel 2.6.9-1.667
>> - LAM config:
>> CC=icc
>> CXX=icpc
>> CXXFLAGS=-D__interface=myinterace
>> FC=ifort
>> export CC CXX CXXFLAGS FC
>> ../lam-7.1.1/configure \
>> --prefix=/usr/local/lam-7.1.1_intel \
>> --with-trillium \
>> --with-prefix-memcpy \
>> --with-debug \
>> --with-tv-debug \
>> --enable-tv-dll-force \
>> --enable-shared \
>> --with-purify \
>> --with-rsh="ssh -x"
>>
>> ...... eg. segmentation fault with mpif77:
>>
>> [ks] ~ > gdb mpif77
>> GNU gdb Red Hat Linux (6.1post-1.20040607.41rh)
>> (gdb) run
>> Starting program: /usr/local/lam-7.1.1_intel/bin/mpif77
>> [Thread debugging using libthread_db enabled]
>> [New Thread 16384 (LWP 9425)]
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 16384 (LWP 9425)]
>> 0x0804e354 in lam_wrap_split (str=@0xfefff108, c=32 ' ', out=@0xfeffef88)
>> at ../../../lam-7.1.1/tools/wrappers/wrap_f77.cc:512
>> 512 while (i < size && str[i] == c)
>> (gdb) backtrace
>> #0 0x0804e354 in lam_wrap_split (str=@0xfefff108, c=32 ' ',
>> out=@0xfeffef88)
>> at ../../../lam-7.1.1/tools/wrappers/wrap_f77.cc:512
>> #1 0x0804bd1b in lam_wrap_get_compiler (env_list=@0xfefff0d8,
>> default_comp=@0xfefff108,
>> out=@0xfeffef88) at ../../../lam-7.1.1/tools/wrappers/wrap_f77.cc:173
>> #2 0x0804f060 in lam_wrap_engine (argc=1, argv=0xfefff204,
>> env_vars=@0xfefff0d8,
>> default_compiler=@0xfefff108, want_cxx_includes=true,
>> want_cxx_libs=false, want_f77_includes=true,
>> extra_args=@0xfefff110) at
>> ../../../lam-7.1.1/tools/wrappers/wrap_engine_f77.cc:68
>> #3 0x080499a1 in main (argc=1, argv=0xfefff204) at
>> ../../../lam-7.1.1/tools/wrappers/mpif77.cc:51
>>
>>
>> Thank you in advance,
>> Konstantin
>>
>> _______________________________________________
>> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
>>
>
> --
> {+} Jeff Squyres
> {+} jsquyres_at_[hidden]
> {+} http://www.lam-mpi.org/
>
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
|
