Same sources compiled as shared lib segfault, process works fine.

[aagrawal]

Hello,

I've got this strange problem that the same sources compiled as shared lib segfaults as soon as I try to access a list object but exactly the same sources compiled as process work fine with no problem.!

class C_NameValue
{
public:
string name;
string value;

C_NameValue(const string& name, const string& value);
};

typedef list<C_NameValue> L_NameValues;

class C_Filedef
{
public:
string filename;
struct stat filestat;
bool fileChanged;
L_NameValues nameValues;

C_Filedef(const string& filename);
};

C_NameValue::C_NameValue(const string& n, const string& v)
: name(n), value(v)
{
}

C_Filedef::C_Filedef(const string& f)
: filename(f)
{
{
fileChanged = true;
filestat.st_mtime = 0;
}

typedef list<C_Filedef> L_Filedef;

class ACI_OCD
{
private:
OCDMap __map;
L_Filedef _filedefs;

public:
ACI_OCD(const BZ_CHAR *seg = NULL);

void addFile(const BZ_CHAR *filename);
};

void ACI_OCD::addFile(const BZ_CHAR *filename)
{
C_Filedef filedef(filename);

for (L_Filedef::iterator fd=_filedefs.begin(); fd!=_filedefs.end(); ++fd)
{
if (fd->filename == filename) return; ---> ERROR HERE
}

_filedefs.push_back(filedef);
}

above is compiled as a static lib, no problem. Now when I call addFile from a program and compile it both as a shared lib and a process, the process works fine but the shared lib segfaults as soon as i try to access anything in the list, namely the _filedefs.begin(). gdb shows the fd to be 0x0!! and has a size of 8. When I run the process through gdb it also shows a size of 8 but a valid address for fd.

Would appreciate any suggestions.

[jsmith]

What instance of ACI_OCD are you calling addFile on?

[aagrawal]

its called in a public method of ACI_OCD, do you suspect the call is being directed to another static method or something?

Additionally, could it have sometihng to do with 32 bit SuSe Linux, compiled using gcc 4.1.2? It works fine on Tru64 Unix.

[jsmith]

It sounds like a variable is not getting initialized when it is being linked as a .so.

If there are global variables (in the .so) involved, the question is what causes them to be initialized?

When linked statically, the compiler will just call a thunk as part of the static initialization that occurs prior to main. When linked as a .so, that thunk doesn't exist, so the variable does not get initialized.

[aagrawal]

Well I've tried calling a public method of ACI_OCD that calls addFile from a simple c program that has no global variables. In fact it does nothing more than return the returnVal from this method. The only difference is, for shared lib call its in a named function, for the process in main. No luck, continues to fail with SIGSEGV on the line above.

Thanks for your help so far, I'll try and see if there any global variables in this static lib I can get rid of. Do let me know if something else occurs to you.

[aagrawal]

Jesus man jsmith. That was a brilliant hint.! There is this global variable, just one that I had, moved its declaration into a method of ACI_OCD which now returns this variable and voila.! Everything works great. Much appreciated.

[jsmith]

Well, I wish I could say it was brilliant, but it was more like "been there, done that"... :)