POSIX Threading and Segmentation Fault...

D

DanielEKFA

Hey there :)

Just joined the group, looking for a resolution to a problem I and my
three groups members are having (we're students, making an FTP-like
server/client as an exam project).

We're getting segmentation faults when threading with the following
code (this code is not the actual code as it's going to look, but a
shortened version for debugging purposes, yet it segfaults the same way
as the "real" code):

-------------------------------------------------------------------------------

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

#include <iostream>
#include <cstdlib>
#include <vector>

#include "executer.h"
#include "taskmanager.h"

using namespace std;

typedef void ReporterFunctionType(const string&);
typedef bool QueueGetFunctionType(SymbolSequence&,
PerformerFunctionType*&);

struct ThreadParameters
{
string host, username, password;
int port;
ReporterFunctionType* reporter;
QueueGetFunctionType* retriever;
};





void reporter(const string& message) {
cout << message << endl;
}





void *worker(void *structPtr)
{/*
// TODO: Get this out somewhere global, it's in TaskManager, too:
struct ThreadParameters
{
string host, username, password;
int port;
ReporterFunctionType* reporter;
QueueGetFunctionType* retriever;
};

// We need the parameters readable:
ThreadParameters *MyParams = (ThreadParameters*) structPtr;

(*(MyParams->reporter))("inside the thread!");

// Done, so we deallocate the memory occupied by our parameter struct:
delete MyParams;*/
}





int main(int argc, char *argv[])
{
// TEST START:
pthread_t handler;
pthread_attr_t attr;

// Create a parameter struct for the thread:
ThreadParameters* Parameters;
Parameters = new ThreadParameters(); // NOTE: The thread must remember
to deallocate memory when it's done.

// Fill in common parameter values:
Parameters->host = "";
Parameters->username = "";
Parameters->password = "";
Parameters->port = 21;
Parameters->reporter = &reporter;
Parameters->retriever = NULL;

pthread_create(&handler, &attr, worker, (void *) Parameters);
// TEST STOP.

return EXIT_SUCCESS;
}

-------------------------------------------------------------------------------

The project is being written in kdevelop, so we were suspecting that
perhaps kdevelop was "forgetting" the "-lpthread" make parameter
(earlier on we were getting segfaults when threading because we had
forgotten this parameter in our custom made makefile), but making our
own makefile with the -lpthread parameter in place yielded the same
result. Compiling works, execution doesn't.

As you'll notice, the actual code in the thread function is commented
out, simply to try to determine if the segfault was happening inside
the thread, before the thread, or in the actual pthread_create call. It
is the latter that is the case, as was confirmed by using the debug
tool ("gdb", is it?).

We're thinking it has to be something with our parameters, but we're
not sure what... Help will be very very much appreciated, as we're
really scratching our dumb heads here ;)

Thanks in advance,
Daniel plus crew :)
 
C

Christoph Bartoschek

DanielEKFA wrote:
.....
Thanks in advance,
Daniel plus crew :)

I guess this is the wrong group, there are thread specific ones. But here
some remarks:

1. you have to initialize attr: pthread_attr_init(&attr);
2. You have to link against pthread: -pthread (not -lpthread)
3. You have to include the right header:

extern "C" {
#include "pthread.h"
}

I do not know why this compiles. Maybe one of the other headers includes
pthread.h.

Christoph
 
D

DanielEKFA

A little update: Noticed we forget a couple of initializers, so we
added them and the code is now:

-------------------------------------------------------------------------------

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

#include <iostream>
#include <cstdlib>
#include <vector>

#include "executer.h"
#include "taskmanager.h"

using namespace std;

typedef void ReporterFunctionType(const string&);
typedef bool QueueGetFunctionType(SymbolSequence&,
PerformerFunctionType*&);

struct ThreadParameters
{
string host, username, password;
int port;
ReporterFunctionType* reporter;
QueueGetFunctionType* retriever;
};





void reporter(const string& message) {
cout << message << endl;
}





void *worker(void *structPtr)
{/*
// TODO: Get this out somewhere global, it's in TaskManager, too:
struct ThreadParameters
{
string host, username, password;
int port;
ReporterFunctionType* reporter;
QueueGetFunctionType* retriever;
};

// We need the parameters readable:
ThreadParameters *MyParams = (ThreadParameters*) structPtr;

(*(MyParams->reporter))("inside the thread!");

// Done, so we deallocate the memory occupied by our parameter struct:
delete MyParams;*/
}





int main(int argc, char *argv[])
{
// TEST START:
pthread_t handler;
pthread_attr_t attr;

pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);

// Create a parameter struct for the thread:
ThreadParameters* Parameters;
Parameters = new ThreadParameters(); // NOTE: The thread must remember
to deallocate memory when it's done.

// Fill in common parameter values:
Parameters->host = "";
Parameters->username = "";
Parameters->password = "";
Parameters->port = 21;
Parameters->reporter = &reporter;
Parameters->retriever = NULL;

pthread_create(&handler, &attr, worker, (void *) Parameters);
// TEST STOP.

char pikko;
cin >> pikko;

return EXIT_SUCCESS;
}

-------------------------------------------------------------------------------

We also added the "cin >> pikko;" part to make sure the program doesn't
exit immediately after threading (thinking that might be the problem).

But, alas, the problem remains...
 
D

DanielEKFA

Hi Christoph, thanks for the reply :)

We already added the attr_init call, but it didn't help. And you're
right, the pthread.h library is included in the taskmanager.h include.
We will try the -pthread parameter instead of -lpthread, but the
-lpthread parameter is what worked before, so we're a little bit
sceptic ;) Anyways, you wouldn't happen to know how to check if and
where kdevelop sets such a parameter in its automatically generated
makefiles, would you? It would be nice to still be able to use kdevelop
if indeed it turns out to be the culprit :)

Thanks again,
Daniel :)

PS: Sorry about the long quotes (I assume) - not quite gotten a hang of
googlegroups yet, it's just that our school blocks traffic to
newsservers, so I can't use knode :(
 
C

Christoph Bartoschek

DanielEKFA said:
Just confirmed: -pthread parameter doesn't stop segfaults :(


Then you have other code than I do. I do not have executer.h and
taskmanager.h. The code of your first post works here when I comment out
the missing includes, add class SymbolSequence and class
PerformerFunctionType and do what I said in my first post.

Christoph
 
D

DanielEKFA

No, actually, we just discovered it's a bug in either the compiler or
the pthread library... Our previous server (earlier project preparing
for this one) compiled and ran fine on this computer prior to me
upgrading to Mandrakelinux 10.2, now the exact same code compiles, but
segfaults immediately upon execution :(

Out of curiosity, which versions are your gcc/pthread? And is it right
of me to assume problems with the newer versions in MDK 10.2 or could
it simply be something I need to install?

Thanks for your help :)
 
D

DanielEKFA

Okay, another couple of lines, and sorry for the constant yakking :|

The school has a Debian server running Telnet and FTP on which we can
upload, compile and run our servers. The kdevelop version of our
project segfaults on execution here, too, yet our own makefile
compiling the same source files does not (we presume because of the
missing -lpthread parameter, the kdevelop version segfaults).

Okay, so it'd be cool to
a) Know how to tell kdevelop to add this -lpthread (or -pthread as you
suggest, if that works, too) to its configure file/makefile.
b) Find out why both versions segfault on my computer as this is our
primary development platform, and it'd really suck to have to upload
and compile on the school server all the time ;) What should I look at?
The 10.2 beta worked, the official does not. I did do a complete
reinstall, not an upgrade, and I did chopse a bunch of developer stuff
that looked like I might need it for the project, including different
versions of gcc: gcc2.96, gcc-3.4.3.7, and gcc4.0. Could it be the 4.0
version being chosen as it is newest, yet that version is not ready for
primetime yet?

Argh... :)

Thanks,
Daniel et al.
 
D

DanielEKFA

I've now tried aliasing g++ to the three different versions and
compiling with each one, all of them segfault... Is the pthread library
part of the gcc package, or is it external? I don't understand why it
would segfault on every one... Or, as it's a system call, could it
simply be the kernel that's the problem? Maybe I should try an older
one...
 
D

DanielEKFA

Nevermind guys, stuff works now... Not sure exactly what I did, but the
puter seems happy and content now. Old code doesn't work though, but
who cares about that, right ;)

Cheers, and thanks for the input :)

Daniel
 
D

Default User

DanielEKFA said:
PS: Sorry about the long quotes (I assume) - not quite gotten a hang of
googlegroups yet, it's just that our school blocks traffic to
newsservers, so I can't use knode :(

The number one thing you need to learn if you plan to use Google as a
usenet reader (the term Google groups is INCORRECT in this context,
these are not Google groups), is to reply properly.

In their bumbling way, Google made the default Reply at the bottom of
each message broken. To reply properly, click on "show options" and use
the Reply shown in the expanded headers. This will give proper quotes
and attributions, and make you a much better netizen, huzzah.

Then be sure to review the netiquette guidelines in the comp.lang.c++
FAQ:

http://www.parashift.com/c++-faq-lite/how-to-post.html



Brian
 
D

DanielEKFA

Default said:
The number one thing you need to learn if you plan to use Google as a
usenet reader (the term Google groups is INCORRECT in this context,
these are not Google groups), is to reply properly.

Yeah, I must say the google groups thing is surprisingly good (the beta one,
at least), but I still wouldn't trade it for my good old knode anytime ;)
In their bumbling way, Google made the default Reply at the bottom of
each message broken. To reply properly, click on "show options" and use
the Reply shown in the expanded headers. This will give proper quotes
and attributions, and make you a much better netizen, huzzah.

Thanks for the tip, I just tried it out, weird that they think it's a good
idea to hide it all the way up there :/
Then be sure to review the netiquette guidelines in the comp.lang.c++
FAQ:

http://www.parashift.com/c++-faq-lite/how-to-post.html

Sure thing, open in konqueror right now :)

Cheers,
Daniel :)
 
D

Default User

DanielEKFA said:
Yeah, I must say the google groups thing is surprisingly good (the beta one,
at least), but I still wouldn't trade it for my good old knode
anytime ;)

You like it better than many do. I really don't complain about the user
interface aspects because, hey, what did I pay?

I'm in an inbetween state. Our newsfeed here is partly broked, we can
read just fine but posts just never make it out. So I use Google to
post.
Thanks for the tip, I just tried it out, weird that they think it's a good
idea to hide it all the way up there :/

I think they've forgotten their own motto, "Don't be evil." The effect
of this decision has been decidedly evil for usenet.




Brian
 
D

DanielEKFA

Default said:
You like it better than many do. I really don't complain about the user
interface aspects because, hey, what did I pay?

I'm in an inbetween state. Our newsfeed here is partly broked, we can
read just fine but posts just never make it out. So I use Google to
post.

Yeah, and I just lost the individual.net account once they got money hungry,
so now I'm stuck with two ISP servers, and the google stuff.
I think they've forgotten their own motto, "Don't be evil." The effect
of this decision has been decidedly evil for usenet.

I agree. Perhaps this is one of the things we should tell them to fix before
the beta goes gold?

Cheers,
Daniel :)
 
D

Default User

DanielEKFA said:
Default User wrote:

Yeah, and I just lost the individual.net account once they got money hungry,
so now I'm stuck with two ISP servers, and the google stuff.

My theory is that the German server went pay due to AOL getting rid of
usenet. They were probably getting a huge uptick in users, now Google
is getting them.
I agree. Perhaps this is one of the things we should tell them to fix before
the beta goes gold?


People have been telling them. They don't seem to be listening too
well.



Brian
 
L

Lionel B

DanielEKFA said:
Default User wrote:

/.../

Yeah, and I just lost the individual.net account once they got money hungry,
so now I'm stuck with two ISP servers, and the google stuff.

Me too... try news.sunsite.dk - free, seems ok for posting, speed not bad.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,994
Messages
2,570,223
Members
46,813
Latest member
lawrwtwinkle111

Latest Threads

Top