mingw environment gives me headaches...

[pheres]

Hi,

porting my actual app from linux/gcc to windows xp/mingw gets me very strange behavior I've no explanation for. My hope is that the things I describe in that loose way triggers some feeling of deja-vu in someones head.

Basically my app uses wxwidgets, some boost stuff, pthread and a proprietary lib. It is coded as platform independent as possible. Very little parts of the code are written platform specific, mainly the code to handle runtime loading of plugin dll/so 's.

under win32 I compiled all libraries the app uses myself with the same tool chain as the app.

The windows XP used as development environment lives in a vmware virtual machine. I don't know if thats important in any way, so I better add that information

Under linux the app runs very stable, I really tried hard to crash it without luck.
But what happens under win32? Segfaults! If i backtrace them the trace always seems to end in either a pthread_mutex_lock() or _unlock() operation. I identified 2 places so far this happens (between them many locks/unlocks are done successfully). I tried the last two versions of pthreads for win32, the GC2 und GCE2 versions each time. This didn't change anything.

I am able to eliminate one of the segfaults by just changing a line of code (a silly cout). It does NOT matter if I add that cout or comment it out. Just recompiling with the modified line does the job. How strange is that?!

If you have any idea, no matter how strange it is, I'll try it. I tinkered around the last 3 days and my mind is really empty. As a last option I could try to reinstall/-build everything but I havent a good mind to do so

[cyberfish]

if your code happens to use the rand() function, note that in mingw, rand() has to be seeded in every thread (as opposed to in Linux, it only needs to be seeded in every process)

I figured this out the hard way two days ago.

[pheres]

Thanks for the hint. Unfortunately i use no rand().

[pheres]

At least one of the bugs is resolved. accessing a mutex after it's destruction leads to undefined behavior. Under gcc nothing exciting does happen, but under win32 pthread segfaults.
Believe me or not, before finding that bug late afternoon today for some reason Salems signature did go around my head while getting up this morning taking a shower and I wondered why. I still wonder...

But the strange of the two bugs, that one that does go away due to recompiling the project, is still out there waiting for me.
I figured out:
Cleaning the project -> compile from scratch -> segfault -> changing a silly line -> call make again (incremental) -> no segfault -> reverse the change -> incremental make -> no segfault -> make clean -> make -> segfault
funny :/

[Mario F.]

Hmm...

I'd use wxWidgets own threads library pheres. It's pretty much stable and working from my own (limited yet, but fruitfull) experience. Boost::threads, which I like very much, gave me nonetheless the willies when I first tried to use it with wxWigets. I wouldn't place my hands on the fire for pthreads library either.

Try to use it in the early stages of your code and see if those segfaults still fire. My bet is they won't.

[pheres]

Thanks for your statement! The thing what prevents me from doing so i that I rely on other components and they all rely on pthread. wxwidgets is actually just used for a prototype what gets definitely thrown away. The binary that last bug is in, acting as a kind of backend, isn't even linked to wxwidgets.

I compared now the binaries:
the .exe has the same size in the buggy and non-buggy version, but differs slightly in it's header.
A plugin dll is 517kb in the buggy and 530kb in the non-buggy version.

How can that happen?

I'm trying to analyze the make process now...

[pheres]

The make process seems to use identical commands to rebuild the needed files.

I compared all object files now (wuha, what was a bunch) and they are identical. so I guess the linker (ld) is going crazy?

[pheres]

Finally I got it. It was an little error in the make system (developed by an unreflected copy&paste of a make module). So an import library was overwritten later in the build process due to equal file names and the linking was totally broken (I still wonder why it actually linked at all - never mind).
The segfault is gone. That bzr commit was really satisfactory.

note to myself: boot the brain before pressing ctrl-c/v
and for the protocol: pthread and mingw/ld are super great tools and I'm barely worth using them

thank you for listening.