Re: Installing on Windows 95 with Mingw32 1.1
I got the command line gdb to run, but what a pain. I'm researching both the GUI version as well as the JIT versions available for mingw. They may help out. However, the command line version just stranded me with no clear idea why things were failing, so I don't know if the other debuggers will be much help.
If it helps, I tried debugging the thread code with the latest cygwin GUI debugger (which is almost usable BTW), but still couldn't figure out what the issue was. I also tried with vc6+pthreads-win32 and Borland+pthreads-win32 and both of those check out OK, in the latter case I was able to build both boost.threads and pthreads-win32 with Borlands Codeguard support enabled, and there were no memory related errors, so I think this is something very specific to gcc. BTW I also see a page fault when building with gcc3.01 on Linux - this time the fault goes away if I build in release mode, so I suspect there is an assertion being triggered somewhere, and it's the assertion that's dying. I haven't got any further than that though. - John Maddock http://ourworld.compuserve.com/homepages/john_maddock/
From: "John Maddock" <john_maddock@compuserve.com>
I got the command line gdb to run, but what a pain. I'm researching both the GUI version as well as the JIT versions available for mingw. They may help out. However, the command line version just stranded me with no clear idea why things were failing, so I don't know if the other debuggers will be much help.
If it helps, I tried debugging the thread code with the latest cygwin GUI debugger (which is almost usable BTW), but still couldn't figure out what the issue was. I also tried with vc6+pthreads-win32 and Borland+pthreads-win32 and both of those check out OK, in the latter case I was able to build both boost.threads and pthreads-win32 with Borlands Codeguard support enabled, and there were no memory related errors, so I think this is something very specific to gcc.
BTW I also see a page fault when building with gcc3.01 on Linux - this time the fault goes away if I build in release mode, so I suspect there is an assertion being triggered somewhere, and it's the assertion that's dying. I haven't got any further than that though.
ISTR that when I tried to use boost.threads in the past on Win98, I encountered problems with the TSS code as well - with MSVC. I didn't see the page faults since a catch(...) handler on MSVC eats them but the results were worse than that - the machine locked up in about half of the cases, in the other half the thread that faulted died without warning. I think that it's possible that the problem is not gcc-specific. Note that both your successes use pthreads-win32, not the native win32 implementation of Boost.Threads. -- Peter Dimov Multi Media Ltd.
From: "John Maddock" <john_maddock@c...>
I got the command line gdb to run, but what a pain. I'm researching both the GUI version as well as the JIT versions available for mingw. They may help out. However, the command line version just stranded me with no clear idea why things were failing, so I don't know if the other debuggers will be much help.
If it helps, I tried debugging the thread code with the latest cygwin GUI debugger (which is almost usable BTW), but still couldn't figure out what the issue was. I also tried with vc6+pthreads-win32 and Borland+pthreads-win32 and both of those check out OK, in the latter case I was able to build both boost.threads and pthreads-win32 with Borlands Codeguard support enabled, and there were no memory related errors, so I think this is something very specific to gcc.
BTW I also see a page fault when building with gcc3.01 on Linux -
time
the fault goes away if I build in release mode, so I suspect
assertion being triggered somewhere, and it's the assertion
--- In Boost-Users@y..., "Peter Dimov" <pdimov@m...> wrote: this there is an that's dying.
I haven't got any further than that though.
ISTR that when I tried to use boost.threads in the past on Win98, I encountered problems with the TSS code as well - with MSVC. I didn't see the page faults since a catch(...) handler on MSVC eats them but the results were worse than that - the machine locked up in about half of the cases, in the other half the thread that faulted died without warning.
I believe this issue has been fixed. I'd suggest trying the test again and letting me know if there's still a problem. Unfortunately, I no longer have access to a Win 9x box to test on.
I think that it's possible that the problem is not gcc-specific. Note that both your successes use pthreads-win32, not the native win32 implementation of Boost.Threads.
Possible, but not likely. I've had reports from others about success with VC++ and Borland using native threads, though it may be a platform issue since they did not report what platform they were on. My own testing on Win2K shows the problem in gcc mingw, but not in VC++ (and I've run it through Bounds Checker under VC++ as well). Bill Kempf
--- In Boost-Users@y..., John Maddock <john_maddock@c...> wrote:
I got the command line gdb to run, but what a pain. I'm
researching
both the GUI version as well as the JIT versions available for mingw. They may help out. However, the command line version just stranded me with no clear idea why things were failing, so I don't know if the other debuggers will be much help.
If it helps, I tried debugging the thread code with the latest cygwin GUI debugger (which is almost usable BTW), but still couldn't figure out what the issue was. I also tried with vc6+pthreads-win32 and Borland+pthreads-win32 and both of those check out OK, in the latter case I was able to build both boost.threads and pthreads-win32 with Borlands Codeguard support enabled, and there were no memory related errors, so I think this is something very specific to gcc.
BTW I also see a page fault when building with gcc3.01 on Linux -
What's needed is testing with native Win32 threads on these compilers. The problem in question occurs with mingw using the native Win32 threads, and evidently occurs only with thread_specific_ptr<> and so may be related to DLL issues. this time
the fault goes away if I build in release mode, so I suspect there is an assertion being triggered somewhere, and it's the assertion that's dying. I haven't got any further than that though.
This will be a seperate issue entirely, and one I'd be very interested in hearing more about. Bill Kempf
participants (2)
-
John Maddock -
Peter Dimov -
williamkempf＠hotmail.com