Crashes happening 2-10 time a day.

[JoshuaBatty]

It seems that the following dll's are causing the PM software to crash multiple times a day.

nvoglv64.dll
ucrtbase.dll
nvxdplcy.dll

UCRTBASE.DLL
People have reported fixing this dll crashing once they have uninstalled Nvidia "hd audio driver". Would be worth checking if this is indeed installed on the system.

NVXDPLCY.DLL
This is a Dell resource media dll. Need to look more into why this driver is causing crashes.

NVOGLV64.DLL
This is an Nvidia driver, might need updating?

[freesig]

Ok so every crash has the same code '0xc0000005'. Which is an access violation error. Not that this is super helpful because people say it could be anything from faulty hardware to a opengl buffer access error.

Putting this discussion here for reference. I will keep digging. I'm not sure how easy this will be to find. The fact that it happens periodically make me suspicious that it's a hardware issue.

[freesig]

Just got lucky working on a different bug. The app crashed in debug mode with the same access violation. Here's the stack trace:

This is happening when creating the piMapper. The call to ofHideCursor()

The call to glfwSetTime() seems to be the cause but that is being called by hideCursor().
Note as well this is happening on an amazon windows machine not the science works so that confirms this bug is not hardware or dependent on the SW machines

[JoshuaBatty]

Agh nice find @freesig ! I think we dont actually need to have that ofHideCursor call as it's impossible for them to touch off the screen into the projection window anyway. We should probably just take it out.

[freesig]

I think this access violation is because of the lack of support for opengl on amazon but because the crashes are so similar it definitely provides a clue.

Todo

• Run a debug build of PM overnight (from visual studio) to try and capture a stacktrace from a crash.

[freesig]

There was no crash overnight. Julien said it happens more when people are interacting with the touch screen. This might be a clue as it could be something to do with the changes to mouse adjustments. However it could just be a result of interaction. For example adding shapes.

Todo

• Look for anything to do with gui that could cause an exception.
• Send some fake touch events while running a debug build from VS to try and trigger a crash.

[freesig]

Heres a fake touch generator I'll add in tonight:
ofApp.cpp:298

void ofApp::fake_touch(){
    for(int i = 0; i < 10; i++){
        ofTouchEventArgs::Type touch_type;
        
        bool choice = (ofRandom(1.0) > 0.5) ? true : false;
        
        int id = last_fake_touch_id[i];
        
        switch(last_fake_touch[i]){
            case ofTouchEventArgs::down:
                touch_type = (choice) ? ofTouchEventArgs::move : ofTouchEventArgs::down;
                break;
            case ofTouchEventArgs::Type::up:
                touch_type = (choice) ? ofTouchEventArgs::down : ofTouchEventArgs::up;
                if(choice){ id = int(1 + ofRandom(1000)); }
                break;
            case ofTouchEventArgs::move:
                touch_type = (choice) ? ofTouchEventArgs::up : ofTouchEventArgs::move;
                break;
            default:
                touch_type = ofTouchEventArgs::down;
                id = int(1 + ofRandom(1000));
                break;
        }
        
        int x = int( ofGetScreenWidth() * ofRandom(1.0) );
        int y = int( ofGetScreenHeight() * ofRandom(1.0) );
        
        ofTouchEventArgs touch(touch_type, x, y, id);
        
        switch(touch_type){
            case ofTouchEventArgs::down:
                ofApp::touchDown(touch);
                break;
            case ofTouchEventArgs::Type::up:
                ofApp::touchUp(touch);
                break;
            case ofTouchEventArgs::move:
                ofApp::touchMoved(touch);
                break;
            default:
                break;
        }
        
        last_fake_touch_id[i] = id;
        last_fake_touch[i] = touch_type;
    }
}

ofApp.h:95

// Touch testing
    void fake_touch();
    vector<ofTouchEventArgs::Type> last_fake_touch = {
        ofTouchEventArgs::cancel,
        ofTouchEventArgs::cancel,
        ofTouchEventArgs::cancel,
        ofTouchEventArgs::cancel,
        ofTouchEventArgs::cancel,
        ofTouchEventArgs::cancel,
        ofTouchEventArgs::cancel,
        ofTouchEventArgs::cancel,
        ofTouchEventArgs::cancel,
        ofTouchEventArgs::cancel
    };
    vector<int> last_fake_touch_id = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};

If this doesn't work I will try this

[freesig]

New version of fake touch that actually triggers clicks.
ofEvents.cpp:194

	for(int i = 0; i < 30; i++){
		FakeTouch ft = {
			FakeDirection::CANCEL,
			i,
			0,
			0,
			0,
			0,
			std::chrono::system_clock::now(),
		};
		fake_touches.push_back(ft);
	}

ofEvents.cpp:208

float ofCoreEvents::myRandom(float max) {
	return (max * rand() / float(RAND_MAX)) * (1.0f - std::numeric_limits<float>::epsilon());
}

void ofCoreEvents::fake_touch() {
	auto create_ft = [this] (FakeTouch & ft) {
		ft.my_id = int(1 + myRandom(1000));
		ft.last_direction = FakeDirection::CANCEL;
		ft.x = int(1920 * myRandom(1.0));
		ft.y = int(1080 * myRandom(1.0));
		ft.dx = int(10 * myRandom(1.0));
		ft.dy = int(10 * myRandom(1.0));
		
	};
	for (auto & ft : fake_touches) {
		if( std::chrono::duration_cast<std::chrono::milliseconds>( std::chrono::system_clock::now() - ft.last_time).count() < 300 + int(300 * myRandom(1.0))){
			continue;
		}
		FakeDirection touch_type;
		
		bool choice = (myRandom(1.0) > 0.5) ? true : false;
		bool click = (myRandom(1.0) > 0.3) ? true : false;
		
		int id = ft.my_id;
		
		switch (ft.last_direction) {
			case FakeDirection::DOWN: {
				touch_type = (click) ? FakeDirection::MOVE : (choice) ?
				FakeDirection::MOVE : FakeDirection::DOWN;
			}
				break;
			case FakeDirection::UP:
				touch_type = FakeDirection::DOWN;
				create_ft(ft);
				break;
			case FakeDirection::MOVE:
				touch_type = (click) ? FakeDirection::UP : (choice) ?
				FakeDirection::UP : FakeDirection::MOVE;
				break;
			default:
				touch_type = FakeDirection::DOWN;
				create_ft(ft);
				break;
		}
		
		int x = ft.x;
		int y = ft.y;
		if (!click) {
			x += ft.dx;
			y += ft.dx;
		}
		
		ofTouchEventArgs touch(ofTouchEventArgs::cancel, x, y, id);
		ofMouseEventArgs mouse(ofMouseEventArgs::Pressed, x, y, OF_MOUSE_BUTTON_LEFT);
		
		switch (touch_type) {
			case FakeDirection::DOWN:
				mouse.type = ofMouseEventArgs::Pressed;
				touch.type = ofTouchEventArgs::down;
				notifyMouseEvent(mouse);
				ofNotifyEvent( touchDown, touch);
				break;
			case FakeDirection::UP:
				mouse.type = ofMouseEventArgs::Released;
				touch.type = ofTouchEventArgs::up;
				notifyMouseEvent(mouse);
				ofNotifyEvent( touchUp, touch);
				break;
			case FakeDirection::MOVE:
				mouse.type = ofMouseEventArgs::Moved;
				touch.type = ofTouchEventArgs::move;
				notifyMouseEvent(mouse);
				ofNotifyEvent( touchMoved, touch);
				break;
			default:
				mouse.type = ofMouseEventArgs::Pressed;
				touch.type = ofTouchEventArgs::down;
				notifyMouseEvent(mouse);
				ofNotifyEvent( touchDown, touch);
				break;
		}
		
		ft.my_id = id;
		ft.last_direction = touch_type;
		ft.x = x;
		ft.y = y;
		ft.last_time = std::chrono::system_clock::now();
	}
	
}

ofEvents.cpp:303

fake_touch();

ofEvents.h:199

enum class FakeDirection { UP, DOWN, MOVE, CANCEL };
struct FakeTouch {
	FakeDirection last_direction;
	int my_id;
	int x;
	int y;
	int dx;
	int dy;
	std::chrono::time_point<std::chrono::system_clock> last_time;
};

ofEvents.h:290

	// Touch testing
	void fake_touch();
	vector<FakeTouch> fake_touches;
	float myRandom(float max);
	int count_fakes = 0;

Todo

• run this overnight at SW from visual studio in debug mode

[freesig]

I got a crash last night. It came from here
I've also verified that you can crash the program by sending a packet to port 9002. The osc port.
I'm not certain that this is the cause of the above problem because I don't see why it would need the use of the gui. It could be just a correlation between gui use and crash though.
Solution
Could just alter the OSC library to catch the exception and maybe log it so that we have a record of packets not being received. Unfortunately we can't do this inside our code because it's coming from a different thread but instead will need to do it in the ofxOsc library
Put a try catch cerr print around this line and remove the __throw and put cerr

[freesig]

Yep this is the cause. Sending anything to 9002 that's not formatted correctly crashes the program

[freesig]

ip/posix/UdpSocket.cpp:546

            if( data ) {
                std::cerr << "Bad packet: " << data << std::endl;
                delete [] data;
            }
            //throw;

ip/win32/UdpSocket.cpp:474

try{
socketListeners_[i].first->ProcessPacket( data, (int)size, remoteEndpoint );
}catch(...){
if(data){
  std::cerr << "Bad packet: " << data << std::endl;
}
}

[freesig]

Apparently they are still getting crashes. The log I saw showed about 3 crashes per day but no print out from the error message that I put in there. So it must be something else. I'll run another test and see if we can find another crash.

[freesig]

Assembly:
0000000005187044 add al,14h
000000000225FD25 mov edi,dword ptr [rsi]

This is the output. I'm not sure if they are related. Also not sure why a Teamviewer dll is involved. Might just be because that was the "screen" I was viewing it through.
'EnergeticVibrationsProjectionMapping_debug.exe' (Win32): Unloaded 'C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.10586.0_none_396e892957c7fb25\comctl32.dll'
'EnergeticVibrationsProjectionMapping_debug.exe' (Win32): Unloaded 'C:\Program Files (x86)\TeamViewer\tv_x64.dll'
Actual crash line:
Exception thrown at 0x000000000225FD25 in EnergeticVibrationsProjectionMapping_debug.exe: 0xC0000005: Access violation reading location 0x000000003FDC4000.

[JoshuaBatty]

Arturo in this issue seems to think this is a Visual Studio 2015 problem.

"visual studio does this anoying thing where the debugger stops on any
exception even if they are being capture by the application. i think
it's only that and you can just press continue to keep running the app.
the dialog with the error also gives you the option to disable capturing
that exception in the future i think"

I wonder if there is a way to tell Visual Studio to ignore all Exceptions....?

[JoshuaBatty]

This article shows how to enable and disable certain types of exceptions in Visual Studio. I might see if I can reproduce this crash using team viewer first. Then I'll un tick the 0xC0000005 Exception and see if it somehow stops VS from panicking when this exception occurs.