SIGABRT

[Guest]

I've been unusually plagued by programs compiling flawlessly but
aborting halfway through due to SIGABRT error 6. I've done my best to
diagnose, but it's not clear what I'm looking for; the code causing can
be boiled down to basic commands. Below is the simplest instance I've
made that reproduces the problem.

Assume a class A. Class A contains a void function called insert:
// file A.h

#include <string>

class A {
public:
void insert (string y1, string y2, string y3, string y4);
};

// file A.cpp

void insert (string y1, string y2, string y3, string y4) {
return;
}

// main.cpp

#include <fstream>
#include <string>

int main (int argc, char * const argv[]) {
// VARIABLES -----------------------------
ifstream inFile ("InSymbols.txt"); // Program
assumes InSymbols.txt exists in program dir

string x1, x2, x3, x4;

A myA;

if (inFile.is_open ()) {
while (!inFile.eof ()) { // read
each word separately
inFile >> x1;
inFile >> x2;
inFile >> x3;
inFile >> x4;

myA.insert (x1, x2, x3, x4);
}
}
else
cout << "Error opening file!\n";

inSymbols.close (); //
close file stream

return 0;
}

// end code

Debugging has shown x1 --> x4 to have been given the string values I
expected. However, the second myA.insert() is called, the error signal
occurs:

ZeroLink: unknown symbol '__ZN11A6insertESsSsSsSs'

I'm baffled. Thank you so much!

Will

 

[Guest]

I've been unusually plagued by programs compiling flawlessly but
aborting halfway through due to SIGABRT error 6. I've done my best to
diagnose, but it's not clear what I'm looking for; the code causing can
be boiled down to basic commands. Below is the simplest instance I've
made that reproduces the problem.

[snip]

Debugging has shown x1 --> x4 to have been given the string values I
expected. However, the second myA.insert() is called, the error signal
occurs:

ZeroLink: unknown symbol '__ZN11A6insertESsSsSsSs'

I'm baffled. Thank you so much!

Will

P.S. I believe a code error or two worked its way into the above
message whilst editing. I did not include <iostream> and using
namespace std; in main.cpp. Sorry. My version of the code *does* build
flawlessly, though, I swear.

 

[Moonlit]

Hi,

Is that
A::insert

or
insert

? Please cut and paste your code instead copying by hand.

--


Regards, Ron AF Greve

http://moonlit.xs4all.nl

I've been unusually plagued by programs compiling flawlessly but
aborting halfway through due to SIGABRT error 6. I've done my best to
diagnose, but it's not clear what I'm looking for; the code causing can
be boiled down to basic commands. Below is the simplest instance I've
made that reproduces the problem.
[snip]

Debugging has shown x1 --> x4 to have been given the string values I
expected. However, the second myA.insert() is called, the error signal
occurs:

ZeroLink: unknown symbol '__ZN11A6insertESsSsSsSs'

I'm baffled. Thank you so much!

Will

P.S. I believe a code error or two worked its way into the above
message whilst editing. I did not include <iostream> and using
namespace std; in main.cpp. Sorry. My version of the code *does* build
flawlessly, though, I swear.

 

[Jim Langston]

I've been unusually plagued by programs compiling flawlessly but
aborting halfway through due to SIGABRT error 6. I've done my best to
diagnose, but it's not clear what I'm looking for; the code causing can
be boiled down to basic commands. Below is the simplest instance I've
made that reproduces the problem.

Assume a class A. Class A contains a void function called insert:
// file A.h

#include <string>

class A {
public:
void insert (string y1, string y2, string y3, string y4);
};

// file A.cpp

void insert (string y1, string y2, string y3, string y4) {
return;
}

// main.cpp

#include <fstream>
#include <string>

int main (int argc, char * const argv[]) {
// VARIABLES -----------------------------
ifstream inFile ("InSymbols.txt"); // Program
assumes InSymbols.txt exists in program dir

string x1, x2, x3, x4;

A myA;

if (inFile.is_open ()) {
while (!inFile.eof ()) { // read
each word separately
inFile >> x1;
inFile >> x2;
inFile >> x3;
inFile >> x4;

Not a fix for your problem (or it could be?), but I would suggest changing
this to at least:
while (inFile >> x1 ) {
inFile >> x2;
// etc...

eof() is not the only thing that could prevent you from reading the file
(simplest case being file is in floppy drive and you remove the floppy while
it's reading).

I would actually make it:

if (inFile.is_open())
while (inFile >> x1 >> x2 >> x3 >> x4 )
myA.insert(x1, x2, x3, x4);

 

[Salt_Peter]

I've been unusually plagued by programs compiling flawlessly but
aborting halfway through due to SIGABRT error 6. I've done my best to
diagnose, but it's not clear what I'm looking for; the code causing can
be boiled down to basic commands. Below is the simplest instance I've
made that reproduces the problem.
[snip]

Debugging has shown x1 --> x4 to have been given the string values I
expected. However, the second myA.insert() is called, the error signal
occurs:

ZeroLink: unknown symbol '__ZN11A6insertESsSsSsSs'

I'm baffled. Thank you so much!

Will

P.S. I believe a code error or two worked its way into the above
message whilst editing. I did not include <iostream> and using
namespace std; in main.cpp. Sorry. My version of the code *does* build
flawlessly, though, I swear.

ok, look at the error, its obvious that a symbol was not found for
A::insert().

try defining insert in A.cpp like so:

#include "A.h"

void A::insert(...)
{
...
}

and is there any reason why you aren't passing the std::strings by
reference?

 

[Guest]

Hi,

Is that
A::insert

or
insert

? Please cut and paste your code instead copying by hand.

--


Regards, Ron AF Greve

http://moonlit.xs4all.nl

I've been unusually plagued by programs compiling flawlessly but
aborting halfway through due to SIGABRT error 6. I've done my best to
diagnose, but it's not clear what I'm looking for; the code causing can
be boiled down to basic commands. Below is the simplest instance I've
made that reproduces the problem.
[snip]

Debugging has shown x1 --> x4 to have been given the string values I
expected. However, the second myA.insert() is called, the error signal
occurs:

ZeroLink: unknown symbol '__ZN11A6insertESsSsSsSs'

I'm baffled. Thank you so much!

Will

P.S. I believe a code error or two worked its way into the above
message whilst editing. I did not include <iostream> and using
namespace std; in main.cpp. Sorry. My version of the code *does* build
flawlessly, though, I swear.

No, actually, that was the problem, and not a consequence of editing.
(I copied and pasted but removed excess material like commented-out
lines, etc.) Thanks to you and Salt_Peter for bringing it up.

My question is, wouldn't a gaffe like that be caught by the compiler
and not left as something to be discovered at runtime?

 

[Moonlit]

Hi,

Yes, well actually not by the compiler (it can't) but by the linker. The
linker should try to resolve all calls, variables etc in all modules. Since
there is no A::insert function I think it should complain (which it normally
does as far as I know).

What platform/compiler do you use?

Regards, Ron AF Greve

http://moonlit.xs4all.nl

Hi,

Is that
A::insert

or
insert

? Please cut and paste your code instead copying by hand.

--


Regards, Ron AF Greve

http://moonlit.xs4all.nl

(e-mail address removed) wrote:
I've been unusually plagued by programs compiling flawlessly but
aborting halfway through due to SIGABRT error 6. I've done my best to
diagnose, but it's not clear what I'm looking for; the code causing
can
be boiled down to basic commands. Below is the simplest instance I've
made that reproduces the problem.

[snip]

Debugging has shown x1 --> x4 to have been given the string values I
expected. However, the second myA.insert() is called, the error signal
occurs:

ZeroLink: unknown symbol '__ZN11A6insertESsSsSsSs'

I'm baffled. Thank you so much!

Will

P.S. I believe a code error or two worked its way into the above
message whilst editing. I did not include <iostream> and using
namespace std; in main.cpp. Sorry. My version of the code *does* build
flawlessly, though, I swear.

No, actually, that was the problem, and not a consequence of editing.
(I copied and pasted but removed excess material like commented-out
lines, etc.) Thanks to you and Salt_Peter for bringing it up.

My question is, wouldn't a gaffe like that be caught by the compiler
and not left as something to be discovered at runtime?