WebPositive's threads crashes app_server team

[andy-kras]

Open ​http://vimeo.com/102598570 with WebPositive and just wait 5 min or watch video.

Then you see white screen with debugger in app_server team.

I've got this result on Nightly Images (x86 GCC 2 Hybrid) hrev48692 and hrev47455.

Hardware machines for my testing:

1. 2x Intel Core Duo 32-bit , 1Gb-RAM
2. 4x Intel Core™ i5-2405S, 16Gb-RAM
3. 2x Intel Celeron® 847, 8Gb-RAM

[andy-kras]

Added reports from all my hardware machines for testing

[andy-kras]

This is the same as #11769

[pulkomandy]

		0x726e9160	0x5b26de	DrawState::HasClipping(DrawState) + 0x3e 
		0x726e91d0	0x5e104f	View::RebuildClipping(bool) + 0x17b 
		0x726e9210	0x5b0a78	DrawingContext::SetUserClipping(BRegion*) + 0x3c 
		0x726e93f0	0x5d7d5b	ServerWindow::_DispatchViewMessage(int32, BPrivate::LinkReceiver&) + 0x1ea7 
		0x726e9520	0x5d5df4	ServerWindow::_DispatchMessage(int32, BPrivate::LinkReceiver&) + 0x1270 
		0x726e95a0	0x5dcdba	ServerWindow::_MessageLooper() + 0x27a 
		0x726e95d0	0x5b819e	MessageLooper::_message_thread(void*) + 0x26 
		0x726e95f8	0xdd8f0d	thread_entry + 0x21 

Triggers lots of recursion in DrawState::HasClipping(DrawState) and overflows the stack. It could be infinite recursion, but looking at the code it doesn't look like the DrawState instances could be put in a loop in any normal way, so that would involve a corrupted DrawState object. It could simply be way too much stacked clippings because they are never cleared from the drawing context.

[andy-kras]

With HaikuWebKit 1.4.9-2 running hrev48737 x86_gcc2_hybrid I have no triggers anymore.