[threads] Exception handling change on Windows?
Starting right about the time of the revision 41056 threads changes, the Windows smoke tests started to pop up dialog boxes (rather than just failing quietly) for various threads problems. bjam had not been recompiled, and there was nothing else running on the machine at the time. Is this a threads problem, or did something go haywire on my machine? --Beman
Beman Dawes <bdawes@acm.org> writes:
Starting right about the time of the revision 41056 threads changes, the Windows smoke tests started to pop up dialog boxes (rather than just failing quietly) for various threads problems. bjam had not been recompiled, and there was nothing else running on the machine at the time.
Is this a threads problem, or did something go haywire on my machine?
That sounds bad. That change shouldn't create any new problems --- it was primarily just tidying up existing code. What were the error messages about? Which compiler? Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Anthony Williams wrote:
Beman Dawes <bdawes@acm.org> writes:
Starting right about the time of the revision 41056 threads changes, the Windows smoke tests started to pop up dialog boxes (rather than just failing quietly) for various threads problems. bjam had not been recompiled, and there was nothing else running on the machine at the time.
Is this a threads problem, or did something go haywire on my machine?
That sounds bad. That change shouldn't create any new problems --- it was primarily just tidying up existing code. What were the error messages about? Which compiler?
VC++ 8.0 SP1. For example, test_thread.exe puts up an Application Error dialog "The instruction at blah referenced memory at blatch. The memory could not be read." Hum... It isn't threads tests, but Interprocess tests like mutex_test too. It acts as if Boost.Test is no longer catching exceptions. Yet it doesn't look like Boost.Test has changed recently. Confused, --Beman
Beman Dawes <bdawes@acm.org> writes:
Anthony Williams wrote:
Beman Dawes <bdawes@acm.org> writes:
Starting right about the time of the revision 41056 threads changes, the Windows smoke tests started to pop up dialog boxes (rather than just failing quietly) for various threads problems. bjam had not been recompiled, and there was nothing else running on the machine at the time.
Is this a threads problem, or did something go haywire on my machine?
That sounds bad. That change shouldn't create any new problems --- it was primarily just tidying up existing code. What were the error messages about? Which compiler?
VC++ 8.0 SP1.
For example, test_thread.exe puts up an Application Error dialog "The instruction at blah referenced memory at blatch. The memory could not be read."
Hum... It isn't threads tests, but Interprocess tests like mutex_test too.
It acts as if Boost.Test is no longer catching exceptions. Yet it doesn't look like Boost.Test has changed recently.
Confused,
So am I. I'm using VC 8 here for testing, and everything passes fine. Are you running incremental tests? If so, could you remove the thread binaries and try again? Revision 41056 changed the implementation of main thread info structure, so it's possible that this may cause random crashes if the incremental build hasn't rebuilt everything it needed to. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
John Maddock wrote:
Anthony Williams wrote:
It acts as if Boost.Test is no longer catching exceptions. Yet it doesn't look like Boost.Test has changed recently.
Confused, So am I. I'm using VC 8 here for testing, and everything passes fine.
Passes for me here as well.
Thanks, must be something local to my machine. I've rebooted and deleted bin.v2 to force a total rebuild. Running now... --Beman
Beman Dawes wrote:
John Maddock wrote:
Anthony Williams wrote:
It acts as if Boost.Test is no longer catching exceptions. Yet it doesn't look like Boost.Test has changed recently.
Confused, So am I. I'm using VC 8 here for testing, and everything passes fine. Passes for me here as well.
Thanks, must be something local to my machine.
I've rebooted and deleted bin.v2 to force a total rebuild. Running now...
Hi Beman, We also started seeing these fault dialog boxes on the VeecoFTC machine running the vc8-stlport tests. I rebooted the machine this morning and wiped out the existing binaries to initiate a full rebuild. So it wasn't just your local installation. We'll see if everything clears with the rebuild. If so, we may want to alert other incremental testers on VC8. -Dave
David Deakins wrote:
Beman Dawes wrote:
John Maddock wrote:
Anthony Williams wrote:
It acts as if Boost.Test is no longer catching exceptions. Yet it doesn't look like Boost.Test has changed recently.
Confused, So am I. I'm using VC 8 here for testing, and everything passes fine. Passes for me here as well. Thanks, must be something local to my machine.
I've rebooted and deleted bin.v2 to force a total rebuild. Running now...
Hi Beman,
We also started seeing these fault dialog boxes on the VeecoFTC machine running the vc8-stlport tests. I rebooted the machine this morning and wiped out the existing binaries to initiate a full rebuild. So it wasn't just your local installation. We'll see if everything clears with the rebuild. If so, we may want to alert other incremental testers on VC8.
Interesting... After I rebooted and deleted bin.v2, the fault dialog boxes stopped appearing for awhile, but now have started again for a wave test failure (but not for threads or other libraries). Furthermore, deleting the wave bin.v2 files didn't help; the problem is reoccurring. Also note that there have been no changes to wave whatsoever since October. So it looks like wave, threads, and the other libraries this is happening to are innocent bystanders. But it also doesn't look like Boost.Test or Build V2 files changed either. I'm at a complete loss. Anyone have any ideas? --Beman
2007/11/13, Beman Dawes <bdawes@acm.org>:
Starting right about the time of the revision 41056 threads changes, the Windows smoke tests started to pop up dialog boxes (rather than just failing quietly) for various threads problems. bjam had not been recompiled, and there was nothing else running on the machine at the time.
Is this a threads problem, or did something go haywire on my machine?
The error handling is changed in VC8, see: http://blog.kalmbachnet.de/?postid=75 When we started using VC8 SP1, we had to add a background process looking for error dialogs and automatically closing them (otherwise the failing processes just hangs, and our redundancy mechanisms could not do a ting). The change in VS SP1 was really bad for us. /$
Henrik Sundberg wrote:
2007/11/13, Beman Dawes <bdawes@acm.org>:
Starting right about the time of the revision 41056 threads changes, the Windows smoke tests started to pop up dialog boxes (rather than just failing quietly) for various threads problems. bjam had not been recompiled, and there was nothing else running on the machine at the time.
Is this a threads problem, or did something go haywire on my machine?
The error handling is changed in VC8, see: http://blog.kalmbachnet.de/?postid=75
When we started using VC8 SP1, we had to add a background process looking for error dialogs and automatically closing them (otherwise the failing processes just hangs, and our redundancy mechanisms could not do a ting).
The change in VS SP1 was really bad for us.
I wondered if something like that had happened, but since I applied SP1 a long time ago, don't understand why it would just now start to happen. Thanks for the link, --Beman
On Nov 14, 2007 10:40 PM, Beman Dawes <bdawes@acm.org> wrote:
Henrik Sundberg wrote:
2007/11/13, Beman Dawes <bdawes@acm.org>:
Starting right about the time of the revision 41056 threads changes, the Windows smoke tests started to pop up dialog boxes (rather than just failing quietly) for various threads problems. bjam had not been recompiled, and there was nothing else running on the machine at the time.
Is this a threads problem, or did something go haywire on my machine?
The error handling is changed in VC8, see: http://blog.kalmbachnet.de/?postid=75
When we started using VC8 SP1, we had to add a background process looking for error dialogs and automatically closing them (otherwise the failing processes just hangs, and our redundancy mechanisms could not do a ting).
The change in VS SP1 was really bad for us.
I wondered if something like that had happened, but since I applied SP1 a long time ago, don't understand why it would just now start to happen.
I'm not completely sure, but there have been a series of Windows updates since the release of SP1. I can't be entirely sure this has anything to do with this, but I'm willing to guess additional security measures made by the Windows operating system will cause dialog boxes to appear on sometimes seemingly innocuous errors. This is pure speculation though, but if rolling back to the last known build that works without the dialog boxes on failures doesn't work then it might be a case of Windows update changing the way things work for Boost testing inadvertently. I hope this helps. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis@gmail.com] [+63 928 7291459] [+1 408 4049523]
2007/11/15, Dean Michael Berris <mikhailberis@gmail.com>:
On Nov 14, 2007 10:40 PM, Beman Dawes <bdawes@acm.org> wrote:
Henrik Sundberg wrote:
2007/11/13, Beman Dawes <bdawes@acm.org>:
Starting right about the time of the revision 41056 threads changes, the Windows smoke tests started to pop up dialog boxes (rather than just failing quietly) for various threads problems. bjam had not been recompiled, and there was nothing else running on the machine at the time.
Is this a threads problem, or did something go haywire on my machine?
The error handling is changed in VC8, see: http://blog.kalmbachnet.de/?postid=75
When we started using VC8 SP1, we had to add a background process looking for error dialogs and automatically closing them (otherwise the failing processes just hangs, and our redundancy mechanisms could not do a ting).
The change in VS SP1 was really bad for us.
I wondered if something like that had happened, but since I applied SP1 a long time ago, don't understand why it would just now start to happen.
I'm not completely sure, but there have been a series of Windows updates since the release of SP1. I can't be entirely sure this has anything to do with this, but I'm willing to guess additional security measures made by the Windows operating system will cause dialog boxes to appear on sometimes seemingly innocuous errors.
This is pure speculation though, but if rolling back to the last known build that works without the dialog boxes on failures doesn't work then it might be a case of Windows update changing the way things work for Boost testing inadvertently.
Note that it didn't help to just compile with the old compiler. The new runtime must not exist on the machine where you run your program. The newest runtime is used if you don't write manifests. /$
participants (6)
-
Anthony Williams -
Beman Dawes -
David Deakins -
Dean Michael Berris -
Henrik Sundberg -
John Maddock