I am new to PCL(Point Cloud Library).I used the default All-in-one-installer to install the PCL .The visual studio version is 2019.
Now, I want to run the simple PCD visualization code like this:
'''
#include <pcl/visualization/cloud_viewer.h>
#include <iostream>
#include <pcl/io/io.h>
#include <pcl/io/pcd_io.h>
int user_data;
void
viewerOneOff(pcl::visualization::PCLVisualizer& viewer)
{
viewer.setBackgroundColor(1.0, 0.5, 1.0);
pcl::PointXYZ o;
o.x = 1.0;
o.y = 0;
o.z = 0;
viewer.addSphere(o, 0.25, "sphere", 0);
std::cout << "i only run once" << std::endl;
}
void
viewerPsycho(pcl::visualization::PCLVisualizer& viewer)
{
static unsigned count = 0;
std::stringstream ss;
ss << "Once per viewer loop: " << count++;
viewer.removeShape("text", 0);
viewer.addText(ss.str(), 200, 300, "text", 0);
//FIXME: possible race condition here:
user_data++;
}
int
main()
{
pcl::PointCloud<pcl::PointXYZ>::Ptr cloud(new pcl::PointCloud<pcl::PointXYZ>);
pcl::io::loadPCDFile("C:/Users/Shinelon/Desktop/test_pcd.pcd", *cloud);
pcl::visualization::CloudViewer viewer("Cloud Viewer");
//blocks until the cloud is actually rendered
viewer.showCloud(cloud);
//use the following functions to get access to the underlying more advanced/powerful
//PCLVisualizer
//This will only get called once
viewer.runOnVisualizationThreadOnce(viewerOneOff);
////This will get called once per visualization iteration
viewer.runOnVisualizationThread(viewerPsycho);
while (!viewer.wasStopped())
{
//you can also do cool processing here
//FIXME: Note that this is running in a separate thread from viewerPsycho
//and you should guard against race conditions yourself...
user_data++;
}
return 0;
}
'''
The Result is:
I don't get any error, the compilation was successful. When I run, it will display a window, and then the program crashes.
I can not find the cause.Could someone help me?
Any suggestions will be appreciated.
Sorry, I don't know the version number of the previous NVIDIA driver on my laptop.
Coincidentally, a game running on my computer crashed yesterday because of "nvwgf2umx.DLL".The official solution is to reinstall the latest version of the NVIDIA driver which I did later.
As a result, the game worked, and the bugs in the post disappeared.
I hope that this answer will be helpful to others in the future.
Related
System used: ROS2 foxy on Ubuntu 20.04 with PCL 1.10 installed on amd64 architecture.
I have created a C++ subscriber for ROS2 topic velodyne_points of the message type sensor_msgs::msg::PointCloud2. Since, this is ROS2 message and PCL can't handle it. So, I first convert it to something (pcl::PCLPointCloud2 cloud;) which PCL can understand using pcl_conversions::toPCL(*msg, cloud); where msg is the pointer to ROS message and cloud contains the converted PCL data. Then, I want to apply PCL's voxelGrid functionality. Since voxelGrid.setInputCloud(cloudPtr); takes the argument as a pointer(the const boost shared pointer to a PointCloud message), I create one which points to PCL "cloud" using pcl::PCLPointCloud2::Ptr cloudPtr (&cloud);, process it further and save the result in a memory location pointed by cloud_filtered. But as soon as program reaches the end of this subscriber callback function, it gives an error double free or corruption (out) on the terminal and execution stops (No error in compilation, only in execution).
I tried to understand this error but I am not trying to free some pointer explicitly which is already free. This issue happens because of the line pcl::PCLPointCloud2::Ptr cloudPtr (&cloud); because when I tried commenting this line and the voxelization steps, execution worked well. But I need to do voxelization and some more steps after it is done (ground plane segmentation, clustering etc.).
I am trying to build ROS2 package and run the executable using this command : clear && colcon build --packages-select custom_nav_stack_pkg --symlink-install && source install/local_setup.bash && ros2 run custom_nav_stack_pkg cpp_executable which looks fine to me.
Here is the code.
#include <memory>
#include <iostream>
#include "rclcpp/rclcpp.hpp"
#include "std_msgs/msg/string.hpp"
#include "sensor_msgs/msg/point_cloud2.hpp"
#include <pcl/point_cloud.h>
#include <pcl/point_types.h>
#include <pcl/PCLPointCloud2.h>
#include <pcl/conversions.h>
#include <pcl_conversions/pcl_conversions.h>
#include <pcl/visualization/cloud_viewer.h>
#include <boost/foreach.hpp>
#include <pcl/filters/voxel_grid.h>
class MinimalSubscriber : public rclcpp::Node
{
public:
MinimalSubscriber() //Constructor which has the same name as that of class followed by a parentheses. A constructor in C++ is a special method that is automatically called when an object of a class is created.
: Node("minimal_subscriber")
{
subscription_ = this->create_subscription<sensor_msgs::msg::PointCloud2>
("velodyne_points", 10, std::bind(&MinimalSubscriber::topic_callback, this, std::placeholders::_1));
}
private:
void topic_callback(const sensor_msgs::msg::PointCloud2::SharedPtr msg) const
{
RCLCPP_INFO(this->get_logger(), "I received the message , height is: '%d'", msg->height); //
pcl::PCLPointCloud2 cloud;
pcl_conversions::toPCL(*msg, cloud);
RCLCPP_INFO(this->get_logger(), "I received the PCL message , height is: '%d'", cloud.height);
std::cerr << "PointCloud before filtering: " << cloud.width * cloud.height
<< " data points (" << pcl::getFieldsList (cloud) << ")." << std::endl;
// Declaring pointer for the PCL "cloud"
pcl::PCLPointCloud2::Ptr cloudPtr (&cloud);
// define a new container for the data
pcl::PCLPointCloud2::Ptr cloud_filtered (new pcl::PCLPointCloud2 ());
// define a voxelgrid
pcl::VoxelGrid<pcl::PCLPointCloud2> voxelGrid;
// set input to cloud
voxelGrid.setInputCloud(cloudPtr);
// set the leaf size (x, y, z)
voxelGrid.setLeafSize(0.1, 0.1, 0.1);
// apply the filter to dereferenced cloudVoxel
voxelGrid.filter(*cloud_filtered);
std::cerr << "PointCloud after filtering: " << cloud_filtered->width * cloud_filtered->height
<< " data points (" << pcl::getFieldsList (*cloud_filtered) << ")." << std::endl;
std::cin.ignore();
}
rclcpp::Subscription<sensor_msgs::msg::PointCloud2>::SharedPtr subscription_;
};
int main(int argc, char * argv[])
{
std::cout << "Inside main function now" << std::endl;
rclcpp::init(argc, argv);
rclcpp::spin(std::make_shared<MinimalSubscriber>());
rclcpp::shutdown();
return 0;
}
Running it gives me below output.
Starting >>> custom_nav_stack_pkg
Finished <<< custom_nav_stack_pkg [16.4s]
Summary: 1 package finished [16.7s]
Inside main function now
[INFO] [1664396894.528685765] [minimal_subscriber]: I received the message , height is: '1'
[INFO] [1664396894.528876950] [minimal_subscriber]: I received the PCL message , height is: '1'
PointCloud before filtering: 15000 data points (x y z intensity ring time).
PointCloud after filtering: 5937 data points (x y z intensity ring time).
double free or corruption (out)
The line pcl::PCLPointCloud2::Ptr cloudPtr (&cloud); is the problem: the variable cloud (declared as pcl::PCLPointCloud2 cloud;) is managed by the stack and automatically destroyed/freed at the end of the function. pcl::PCLPointCloud2::Ptr is a shared_ptr (a boost::shared_ptr in older PCL versions and std::shared_ptr in newer PCL versions, but that makes no difference here). The shared pointer will manage the object it points to and will destroy/free it when no longer needed, which is the case at the end of the function. So cloud is destroyed/freed twice.
pcl::PCLPointCloud2::Ptr cloudPtr (new pcl::PCLPointCloud2 ()); is the right way to use the shared pointer. To avoid copy operations, I would recommend to create cloudPtr at the beginning of the function, don't use the stack-managed pcl::PCLPointCloud2 cloud; at all, and instead use *cloudPtr in pcl_conversions::toPCL and everywhere else where you would use cloud.
I am trying to setup ImGui to make some apps in, however I can't get it working. I installed the .h and .cpp files from the GitHub, https://github.com/ocornut/imgui, and followed the instructions to allow the project to compile, which it does. But on Windows and Linux (i've tried both), it spits out a runtime error, (stopped responding Windows, segmentation fault (core dumped) Linux). This is the sample code that was published,
#include "imgui.h"
int main()
{
// Create a window called "My First Tool", with a menu bar.
ImGui::Begin("My First Tool", &my_tool_active, ImGuiWindowFlags_MenuBar);
if (ImGui::BeginMenuBar())
{
if (ImGui::BeginMenu("File"))
{
if (ImGui::MenuItem("Open..", "Ctrl+O")) { /* Do stuff */ }
if (ImGui::MenuItem("Save", "Ctrl+S")) { /* Do stuff */ }
if (ImGui::MenuItem("Close", "Ctrl+W")) { my_tool_active = false; }
ImGui::EndMenu();
}
ImGui::EndMenuBar();
}
// Edit a color (stored as ~4 floats)
ImGui::ColorEdit4("Color", my_color);
// Plot some values
const float my_values[] = { 0.2f, 0.1f, 1.0f, 0.5f, 0.9f, 2.2f };
ImGui::PlotLines("Frame Times", my_values, IM_ARRAYSIZE(my_values));
// Display contents in a scrolling region
ImGui::TextColored(ImVec4(1,1,0,1), "Important Stuff");
ImGui::BeginChild("Scrolling");
for (int n = 0; n < 50; n++)
ImGui::Text("%04d: Some text", n);
ImGui::EndChild();
ImGui::End();
return 0;
}
Now this code doesn't compile due to my_tool_active and my_color, so I added these 2 lines to the code before the ImGui::Begin():
bool my_tool_active = true;
float my_color[4] = {0.5, 0.5, 0.5, 1};
So now when I compile and run, it gets to the ImGui::Begin() and then crashes at that stage. I have tried it in a much smaller example where it is just the ImGui::Begin() and ImGui::End() and placed print statements around it, and it showed that it never finished executing the Begin().
Imgui doesn't provide a graphics backend, neither it creates a window or a graphics API context. You have to provide it by yourself (using OpenGL/DirectX/Vulkan ecc...) or use a library that creates one for you (SDL/glfw ecc...).
Refer to the sample directory to a more complete sample.
This one is using sdl+openGl.
https://github.com/ocornut/imgui/blob/master/examples/example_sdl_opengl3/main.cpp
After my first successful attempt at a 3D engine using Java and OpenGL (LWJGL3), I have decided to try my hand at Vulkan, using C++.
I have barely any experience with C/C++ and I am aware of the steep learning curve of Vulkan. This is however not a problem.
I decided to follow this tutorial: https://vulkan-tutorial.com/Introduction
It has showed me how to create a new project with Vulkan using XCode (as I am on Mac OS Mojave). I would, however, like to continue the rest of the tutorial using CLion as I would be switching between multiple operating systems.
I tried my hand at creating a CLion project and succeeded in making my first CMakeLists file, however something seems to be wrong. The file currently consists of the following:
cmake_minimum_required(VERSION 3.12)
project(VulkanTesting)
set(CMAKE_CXX_STANDARD 14)
add_executable(VulkanTesting main.cpp)
include_directories(/usr/local/include)
include_directories(/Users/[username]/Documents/Vulkan/SDK/vulkansdk-macos-1.1.92.1/macOS/include)
target_link_libraries(VulkanTesting /usr/local/lib/libglfw.3.3.dylib)
target_link_libraries(VulkanTesting /Users/[username]/Documents/Vulkan/SDK/vulkansdk-macos-1.1.92.1/macOS/lib/libvulkan.1.dylib)
target_link_libraries(VulkanTesting /Users/[username]/Documents/Vulkan/SDK/vulkansdk-macos-1.1.92.1/macOS/lib/libvulkan.1.1.92.dylib)
# Don't know if I need the next two lines
link_directories(/usr/local/lib)
link_directories(/Users/[username]/Documents/Vulkan/SDK/vulkansdk-macos-1.1.92.1/macOS/lib)
The reason I showed the above file will become apparent in the question.
The 'Program' so far is the following:
#define GLFW_INCLUDE_VULKAN
#include <GLFW/glfw3.h>
#include <iostream>
#include <stdexcept>
#include <functional>
#include <cstdlib>
#include <vector>
const int WIDTH = 800;
const int HEIGHT = 600;
class HelloTriangleApplication {
public:
void run() {
initWindow();
initVulkan();
mainLoop();
cleanup();
}
private:
GLFWwindow* window;
VkInstance instance;
void initWindow(){
glfwInit();
glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API);
glfwWindowHint(GLFW_RESIZABLE, GLFW_FALSE);
window = glfwCreateWindow(WIDTH, HEIGHT, "My first Vulkan window", nullptr, nullptr);
}
void initVulkan() {
createInstance();
}
void createInstance(){
// Instantiate Application Info
VkApplicationInfo applicationInfo = {};
applicationInfo.sType = VK_STRUCTURE_TYPE_APPLICATION_INFO;
applicationInfo.pApplicationName = "Hello Triangle";
applicationInfo.applicationVersion = VK_MAKE_VERSION(1,0,0);
applicationInfo.pEngineName = "No Engine";
applicationInfo.engineVersion = VK_MAKE_VERSION(1,0,0);
applicationInfo.apiVersion = VK_API_VERSION_1_0;
// Instantiate Instance Creation Info
VkInstanceCreateInfo createInfo = {};
createInfo.sType = VK_STRUCTURE_TYPE_INSTANCE_CREATE_INFO;
createInfo.pApplicationInfo = &applicationInfo;
// Get GLFW platform specific extensions
uint32_t glfwExtensionCount = 0;
const char** glfwExtensions;
glfwExtensions = glfwGetRequiredInstanceExtensions(&glfwExtensionCount);
// Fill in required extensions in Instance Creation Info
createInfo.enabledExtensionCount = glfwExtensionCount;
createInfo.ppEnabledExtensionNames = glfwExtensions;
// For validation layers, this is a later step in the tutorial.
createInfo.enabledLayerCount = 0;
// Create the Vulkan instance, and check if it was successful.
VkResult result = vkCreateInstance(&createInfo, nullptr, &instance);
if(result != VK_SUCCESS){
std::cout << "glfwExtensionCount: " << glfwExtensionCount << "\n";
std::cout << "glfwExtensionNames: " << &glfwExtensions << "\n";
std::cout << "result: " << result << "\n";
throw std::runtime_error("Failed to create Vulkan Instance");
}
}
void mainLoop() {
while(!glfwWindowShouldClose(window)){
glfwPollEvents();
}
}
void cleanup() {
glfwDestroyWindow(window);
glfwTerminate();
}
};
int main() {
HelloTriangleApplication app;
try {
app.run();
} catch (const std::exception& e) {
std::cerr << e.what() << std::endl;
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}
The problem I am having is that when I try to run the program, it will not create a VkInstance. The function returns VK_ERROR_INCOMPATIBLE_DRIVER. Now, I doubt that the driver is in fact incompatible as I have run the demo applications that came with the Vulkan SDK for one, and for another I have been able to run the exact same 'program' in XCode. When I investigated the problem a bit further, I noticed that the glfwGetRequiredInstanceExtensions function returns no extensions when the program is run in CLion like this, but does return one in the XCode equivalent.
This all leads me to believe that there is something I have done wrong in linking the libraries/frameworks in the Cmake file because I am aware of the fact that Vulkan is not directly supported in Mac OS, but instead (somehow?) passes through a layer to communicate with Metal.
Do I need to specify a way for the program to pass its Vulkan functionality through a Metal layer, and is this done automagically in XCode, or is there another problem with my approach?
Any help would be greatly appreciated!
You might want to look at the MacOS Getting Started Guide on the LunarXchange website and in your SDK. There is a section at the end that shows how to use CMake to build a Vulkan app and run it on MacOS. You also may want to use the FindVulkan CMake module instead of manually setting the include directories and the target link libraries.
But my first guess about your specific problem is that you may not be setting the VK_ICD_FILENAMES environment variable. You are correct in your observation that there is no direct support for Vulkan. Instead, the support is provided by the MoltenVK library which is treated as a Vulkan driver. But this "driver" is not installed in any system directory by the SDK. The SDK is just unzipped in your home directory structure, so you must tell the Vulkan loader where to find it via this environment variable.
Again, the CMake section at the end of the Getting Started Guide demonstrates the use of this environment variable. And the entire guide goes into additional detail about how the various Vulkan and MoltenVK components work.
I am finding that QGLShaderProgram is consistently failing to compile any shader and providing no error log. Here are the symptoms:
QGLShaderProgram reports that it failed to compile but produces an empty error log. If I try to bind the shader an exception is thrown.
I can compile a shader using glCompileShader without problem. However, the first time I try to compile this way after QGLShaderProgram has failed, fails with this error log:
ERROR: error(#270) Internal error: Wrong symbol table level
ERROR: 0:2: error(#232) Function declarations cannot occur inside of functions:
main
ERROR: error(#273) 2 compilation errors. No code generated
Following that one failure, the next time I try to compile using glCompileShader works fine.
The problem has arisen only since upgrading from Qt 4.8 to 5.2. Nothing else has changed on this machine.
I have tested on two PCs, one with an ATI Radeon HD 5700, the other with an AMD FirePro V7900. The problem only appears on the Radeon PC.
Here is my test code demonstrating the problem:
main.cpp
#include <QApplication>
#include "Test.h"
int main(int argc, char* argv[])
{
QApplication* app = new QApplication(argc, argv);
Drawer* drawer = new Drawer;
return app->exec();
}
Test.h
#pragma once
#include <qobject>
#include <QTimer>
#include <QWindow>
#include <QOpenGLContext>
#include <QOpenGLFunctions>
class Drawer : public QWindow, protected QOpenGLFunctions
{
Q_OBJECT;
public:
Drawer();
QTimer* mTimer;
QOpenGLContext* mContext;
int frame;
public Q_SLOTS:
void draw();
};
Test.cpp
#include "Test.h"
#include <QGLShaderProgram>
#include <iostream>
#include <ostream>
using namespace std;
Drawer::Drawer()
: mTimer(new QTimer)
, mContext(new QOpenGLContext)
, frame(0)
{
mContext->create();
setSurfaceType(OpenGLSurface);
mTimer->setInterval(40);
connect(mTimer, SIGNAL(timeout()), this, SLOT(draw()));
mTimer->start();
show();
}
const char* vertex = "#version 110 \n void main() { gl_Position = gl_Vertex; }";
const char* fragment = "#version 110 \n void main() { gl_FragColor = vec4(0.0,0.0,0.0,0.0); }";
void Drawer::draw()
{
mContext->makeCurrent(this);
if (frame==0) {
initializeOpenGLFunctions();
}
// Compile using QGLShaderProgram. This always fails
if (frame < 5)
{
QGLShaderProgram* prog = new QGLShaderProgram;
bool f = prog->addShaderFromSourceCode(QGLShader::Fragment, fragment);
cout << "fragment "<<f<<endl;
bool v = prog->addShaderFromSourceCode(QGLShader::Vertex, vertex);
cout << "vertex "<<v<<endl;
bool link = prog->link();
cout << "link "<<link<<endl;
}
// Manual compile using OpenGL direct. This works except for the first time it
// follows the above block
{
GLuint prog = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(prog, 1, &fragment, 0);
glCompileShader(prog);
GLint success = 0;
glGetShaderiv(prog, GL_COMPILE_STATUS, &success);
GLint logSize = 0;
glGetShaderiv(prog, GL_INFO_LOG_LENGTH, &logSize);
GLchar* log = new char[8192];
glGetShaderInfoLog(prog, 8192, 0, log);
cout << "manual compile " << success << endl << log << endl;
delete[] log;
}
glClearColor(1,1,0,1);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
mContext->swapBuffers(this);
frame++;
}
Elsewhere, I have tested using QGLWidget, and on a project that uses GLEW instead of QOpenGLFunctions with exactly the same results.
The version of Qt I'm linking against was built with the following configuration:
configure -developer-build -opensource -nomake examples -nomake tests -mp -opengl desktop -icu -confirm-license
Any suggestions? Or shall I just send this in as a bug report?
Update
In response to peppe's comments:
1) What does QOpenGLDebugLogger says?
The only thing I can get from QOpenGLDebugLogger is
QWindowsGLContext::getProcAddress: Unable to resolve 'glGetPointerv'
This is printed when I initialize it (and not as a debug event firing, but just to console). It happens even though mContext->hasExtension(QByteArrayLiteral("GL_KHR_debug")) returns true and I'm initializing it within the first frame's draw() function.
2) Can you print the compile log of the QOGLShaders even if they compile successfully?
I cannot successfully compile QOpenGLShader or QGLShader at any point so I'm not able to test this. However, when compiling successfully using plain GL functions, the log returns blank.
3) Which GL version did you get from the context? (Check with QSurfaceFormat).
I've tried with versions 3.0, 3.2, 4.2, all with the same result.
4) Please set the same QSurfaceFormat on both the context and the window before creating them
5) Remember to create() the window
I've implemented both of these now and the result is the same.
I've just tested on a third PC and that has no issues. So it is this specific computer which, incidentally, happens to be a Mac Pro running Windows in bootcamp. It has had absolutely no trouble in any other context running the latest ATI drivers but I can only really conclude that there is a bug somewhere between the ATI drivers, this computer's graphics chip and QOpenGLShaderProgram.
I think I'm unlikely to find a solution, so giving up. Thank you for all your input!
I just recently started playing around with SFML and I wrote this simple program.
I'm using visual studio 2010 btw.
The program compiles and runs fine when using the "start debugging" option.
but if I open the .exe file as if I was running a normal desktop application or something, it will crash on exit.
I've spent a while trying to figure it out but all I can say is that it's probably a heap corruption.
here's all the code:
#include <iostream>
#include <sstream>
#include <SFML/System.hpp>
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
void moveSquare();
void avgFPS();
class displayFPS : public sf::Thread{
public:
private:
virtual void Run();
};
int checkEvent(sf::RenderWindow &win){
sf::Event Event;
while(win.GetEvent(Event)){
// Window closed
if (Event.Type == sf::Event::Closed){
return 0;
}
// Escape key pressed
if ((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Key::Escape)){
return 0;
}
}
return -1;
}
sf::RenderWindow win(sf::VideoMode(800,600,32),"Mario Clone Test");
sf::Image img1(200,200,sf::Color(255,255,0));
sf::Sprite sprite1;
std::stringstream ss;
sf::String fps;
bool threadFPS;
int main(){
sprite1.SetImage(img1);
sprite1.SetCenter(-300,-300);
win.SetFramerateLimit(30);
moveSquare();
win.Close();
sf::Sleep(0.5);
return 0;
}
void moveSquare(){
displayFPS dispFPS;
threadFPS = true;
dispFPS.Launch();
fps.SetSize(20);
while(1){
if(!win.IsOpened() || checkEvent(win) == 0){
threadFPS = false;
dispFPS.Wait();
break;
}
win.Draw(sprite1);
win.Draw(fps);
win.Display();
win.Clear();
if(win.GetInput().IsKeyDown(sf::Key::Left)){
sprite1.Move(-100*win.GetFrameTime(),0);
}
if(win.GetInput().IsKeyDown(sf::Key::Right)){
sprite1.Move(100*win.GetFrameTime(),0);
}
if(win.GetInput().IsKeyDown(sf::Key::Up)){
sprite1.Move(0,-100*win.GetFrameTime());
}
if(win.GetInput().IsKeyDown(sf::Key::Down)){
sprite1.Move(0,100*win.GetFrameTime());
}
}
return;
}
void avgFPS(){
double frames=0.0,avg=0.0;
int j=0;
while(threadFPS){
if(win.GetFrameTime() != 0){
j++;
frames = frames+(1.0/win.GetFrameTime());
avg = frames/j;
}
ss << "avg FPS: " << avg << std::endl << "Arrow Keys to Move" << std::endl << "Press ESC to Exit";
fps.SetText(ss.str());
ss.str("");
}
return;
}
void displayFPS::Run(){
avgFPS();
}
I've had the same issue.
You need to recompile SFML when using VS2010.
Few things for you to try:
If you are suspecting heap corruption, run gflags (found in Debugging Tools for Windows) and enable page heap. Some instructions on how it works can be found here. Basically when page heap is enabled, your app will crash at the point of the memory error, not sometime later.
You said you get a crash on exit. When that happens, I'm assuming windows throws up a crash dialog box. Open one of those links that say something like "see what information is being uploaded". Somewhere among those files will be a minidump of your process. You can load that up in visual studio (open file and hit F5). Sometimes visual studio is glitchy, so another, more reliable but more difficult but more difficult to use alternative is WinDbg, also part of Debugging Tools for Windows.
SFML has multiple versions of their .lib's for release and debug.
Examples:
sfml-audio.lib
sfml-audio-d.lib
sfml-audio-s.lib
sfml-audio-s-d.lib
Make sure you are using the lib without the -d in it.
Also, when you put the .dll's with your exe (assuming you are using the dynamic libraries) make sure to use the normal versions not the debug (-d) versions.
Finally, when you are building the project make sure you build for release and not debug.