Hi,

I hava a question about pthread..
I hava a some program which running multithread.
This program runs well on x86 platform, but when it cross-compiled and run on MIPS platform,
after some time, got segmentation fault..

I want to know why this happening.

Any suggestion that will be very appreciated.

PS:
1. i didn't implemented this program, i just take this over.
the person who had given it to me, insist it maybe the bugs is about kernel or device driver not his program fault..

2. personally, i prefer ipc/semaphore or select/poll solution, though i haven't programming so much.

pthreads is notorious for allowing programmers to create programs which almost all of the time, but then fail inexplicably when some new factor is introduced, such as porting to a different platform. The problem is that issues of timing will make a program look as though it has been written correctly, until the accidents of timing are changed so they are no longer in the user's favor.

Statistically, it is unlikely that the bugs are in the kernel or a device driver. Statistically, it is almost certain that the bugs are in the application you've been asked to maintain.

You have a long, long road ahead. Get Programming with POSIX Threads, by David R. Butenhof (Addison Wesley, publisher). (Do not get the O'Reilly book pthreads Programming; at least the edition I had showed the author's familiarity with the subject, but not a deep-seated understanding of the subtleties.)

Then read the book, at least almost all of it. Let it get under your skin. Write a few toy programs which deliberately illustrate the problems that pthreads programming can present.

Then read the application you've been handed. Every line of it.

If you enjoy a challenge, this situation will make you very happy.

Hope this helps.

Thanks for your advice.

So it seems the timing in MIPS(or pthread implementation of glibc on MIPS) different to x86's.

Oh, i forgot to mention one more thing, the program has one bug on x86.
I can't tell you more, but, this person implemented it his own way, regardless of existen good open source which is in good quality..

And about the book, actually, i have read the book a little (Programming with POSIX Threads)..
I don't like it, it smell like devil's advocate..

I believe in ESR's "the art of unix programming"

PS: i tried to read the book twice(Programming with POSIX Threads), and i gave up.

The book has far more wisdom than meets the eye. Most of the "devil's advocate" stuff is warnings about stuff that can bite you. I found one misprint in the book (a bug in one of his chunks of sample code), but other than that, everything I've read in the book is grounded in truth. Ignoring something in the book has the potential to bite you.

But if the book doesn't appeal to you, then do this:

When you encounter a bug which seems impossible to fix, and it seems thread related or timing related, dip into the book until you find the answer to the problem.

In the long run, it will take longer to clean up the code this way; a shorter way would be to digest the book thoroughly and then read all the code. But I sense that this longer way sits with you a little better.

Good luck.