My wild guess is, once again, context sharing. That is the only thing I can think of when comparing your code and the OpenGL example that is currently in master.
It is already not unexpected that sharing screws up even on implementations that claim to work, *cough* Intel *cough*. It is even worse when the people who support the implementation say themselves that it is in an unstable/broken state as is the case with the VirtualBox modules. This is basically "undefined behaviour by design" and there is nothing we can really do about it.
In software development, when using external libraries, one simply has to assume that a set of assumptions provided by those libraries holds true. OpenGL is a specification. Its context management functions (in wgl and glx) are more or less also specifications that provide assumptions which should hold true as well. If an implementation can't guarantee that sharing works as the specification requires, I have no choice but to call it broken, and you can't really expect SFML to support every single broken implementation out there. I can't really blame the VirtualBox guys that much, because they openly state that 3D support is a work in progress. On the other hand, vendors that say that "hardware" product XYZ supports OpenGL X.Y but fail to tell users that half of it is in software is simply unacceptable to me. People fail to realize that if a driver update fixes an issue with something that is normally taken care of in hardware, chances are that feature is fully realized in software and barely hardware accelerated. Unless there is a physical discrete card stuck into a PCIe slot in my system, vendors will have to convince me that their implementation is even partially hardware accelerated. Often they don't mention anything of the sort, because let's face it, 99% of their "customers" don't even know what the difference is. The 1% being us, for which it makes a difference are the losers in the end.
You can try to force all SFML resources and their underlying OpenGL resources to be created in one and the same context by first probing sf::Shader::isAvailable() and sf::Texture::getMaximumSize() right after you create the window. After that, set the window as active once more and it should stay active until the application closes. Everything that happens after that should happen in a single context (the window's one) and sharing shouldn't even be required in that case. So even if it is broken, the application should behave as expected.