I'm working with a C++ DLL project. I tried to use simple boost thread in there. here is the source-code. this run time exception at uploadThread = boost::thread(uploadFileThread); line. Any idea?
Unhandled exception at 0x6fa1bd89 (Controller.dll) in UserInterfaces.exe: 0xC0000005: Access violation reading location 0xbaadf05d.
Controller.h
namespace controller{
class CController {
public:
boost::thread uploadThread;
}
}
Controller.cpp
namespace controller{
static void uploadFileThread(){}
void CController::StartFileUpload(){
uploadThread = boost::thread(uploadFileThread);
uploadThread.join();
}
}
main.cpp
int main(){
controller::CController my_Controller;
my_Controller.StartFileUpload();
return 0;
}
Related
I'm trying to create a program that, on execution, zips a given directory. Most of my errors have been resolved and I am hopefully getting to the end of this, but I still have the issue of an exception being thrown and a question regarding the program. I code in C++20 and on Visual Studio 2019.
I've come across this exact error when debugging the program:
Exception thrown at 0x76820B42 in aixLogger.exe: Microsoft C++ exception: bit7z::BitException at memory location 0x001AF440.
I already checked with a breakpoint what code is giving me this error:
catch (const BitException& ex) {
ex.what(); //<-
}
The code runs otherwise and isn't giving me any error messages, the breakpoint activates on the line I marked with an arrow (not actually part of my code).
To eliminate further possible edits I will add the rest of my code as well:
main.cpp
#include <QCoreApplication>
#include <string>
#include <iostream>
#include <filesystem>
#include <bit7z.hpp>
#include "main.h"
#include <bitcompressor.hpp>
namespace fs = std::filesystem;
using namespace bit7z;
using namespace std;
int main(int argc, char* argv[])
{
QCoreApplication a(argc, argv);
try {
Bit7zLibrary lib{ L"7z.dll" };
BitCompressor compressor{ lib, BitFormat::Zip };
//vector< wstring > files = { L"aretz/Downloads/test" };
wstring dir = { L"D: / local / aretz / Programmierung / git - workplace / aixLogger / test /" } ;
wstring zip = { L"zippedtest.zip" };
compressor.compressDirectory(dir, zip);
}
catch (const BitException& ex) {
ex.what();
}
return a.exec();
}
void AIXLogger::CompressDir() {
/*try {
Bit7zLibrary lib{ L"7z.dll" };
BitCompressor compressor{ lib, BitFormat::Zip };
vector< wstring > files = { L"C:/Users/aretz/Downloads/test" };
wstring zip = { L"zippedtest.zip" };
compressor.compressFiles(files, zip);
}
catch (const BitException& ex) {
ex;
}*/
}
main.h
#pragma once
#include <qwidget.h>
#include <qobject.h>
#include <bit7z.hpp>
class AIXLogger : public QWidget
{
Q_OBJECT
public slots:
public:
void CompressDir();
};
I've currently commented out the function CompressDir() as I can't call it in my main since it gives me either a syntax error or tells me the identifier is undefined.
Syntax Error:
AIXLogger.CompressDir(); the dot is marked as the error
identifier is undefined:
CompressDir();
I don't know what exactly is causing the catch to thrown an exception. From other posts I suspected that my paths for the files and directories are at fault, but changing them or moving my test directory didn't help at all. Removing the try and catch lines from my codeblock only adds the same error message where Exception Thrown is being replaced by Unhandled Exception. Thanks to anyone who can help.
I already checked with a breakpoint what code is giving me this error:
catch (const BitException& ex) {
ex.what(); //<-
}
The code runs otherwise and isn't giving me any error messages
The code isn't giving you any error message since you're not doing anything with the information provided by the thrown exception.
You're simply calling ex.what() without, for example, printing the error message string it returns, e.g., via std::cout.
the breakpoint activates on the line I marked with an arrow (not actually
part of my code).
I don't know what exactly is causing the catch to thrown an exception. From other posts I suspected that my paths for the files and directories are at fault, but changing them or moving my test directory didn't help at all.
The ex.what() error message should give you more details about the actual issue you're having.
By the way, I'm the author of the bit7z library, and from my experience and looking at the code you posted, I can think of some possible causes (the most common ones):
The program could not find the 7z.dll library.
Please ensure that the DLL is in the same directory as the executable or in one of the default DLL search paths of Windows.
The program could not find the directory path to be compressed.
As before, make sure that the path exists.
When I'm trying to run executable compiled using VS2017 I catch
Exception thrown at 0x00007FFF05BC1063 (msvcp140d.dll) in a.exe: 0xC0000005: Access violation reading location 0x0000000000000000. immediately after launching.
After debugging i figured out that it happens when I'm trying to lock static mutex _coutMutex. How can I fix it because when I have compiled using mingw it worked fine. Here is part of my code:
Game.hpp:
#include "Logger.hpp"
class Game
{
public:
static Logger logger;
};
Game.cpp:
#include "Game.hpp"
Logger Game::logger{ "logs/client", Logger::LoggingLevels::Info,
Logger::LoggingLevels::Trace, 2, 100 };
Logger.hpp:
#include <mutex>
class Logger
{
public:
Logger(std::string path, short consoleLoggingLevel, short
fileLoggingLevel, uint32_t count, size_t maxSize);
enum LoggingLevels : short
{
Off = 0,
Fatal = 1,
Error = 2,
Warn = 3,
Info = 4,
Debug = 5,
Trace = 6
};
void _addToQueue(std::string data);
private:
static std::mutex _coutMutex;
};
Logger.cpp:
std::mutex Logger::_coutMutex;
Logger::Logger(std::string path, short consoleLoggingLevel,
short fileLoggingLevel, uint32_t count, size_t maxSize)
{
_addToQueue("dd/mm/yyyy hh:mm:ss.sss\n");
}
void Logger::_addToQueue(std::string data)
{
_coutMutex.lock();
std::cout << data;
_coutMutex.unlock();
}
main.cpp:
#include "Logger.hpp"
#include "Game.hpp"
int main()
{
Game game;
}
As Richard Critten suggests, this must be the global initialisation order problem.
You have 2 global variables, logger and _coutMutex, and these are in a different compilation unit. The order which they are initialized is not defined.
When Logger's constructor runs, _coutMutex is not initialized yet, but _addToQueue wants to use it.
You could have three solutions:
Avoid using global objects. Or avoid using global constructors which do something serious (if you remove _addToQueue from logger constructor, it will work).
put these global variables into one compilation unit, in correct order
add an accessor function for _coutMutex, and define mutex inside of it (as a static variable). Beware of this solution, as it has its drawbacks (speed, thread safety)
I'm working on an CLR C++ project, it works properly when running single instace.
However when i debug run the program from visual studio and then run the compiled executable from the project debug folder i get Socket and IO exceptions, the application doesn't crash and it keeps running normally.
I'm using the following class to enable single instance:
initializer.h
#pragma once
namespace Project2
{
public ref class SingleApplication: public Microsoft::VisualBasic::ApplicationServices::WindowsFormsApplicationBase
{
protected:
virtual void OnCreateMainForm() override;
protected:
~SingleApplication ()
{
}
public:
SingleApplication (void);
System::Void StartNextInstance (System::Object ^sender, Microsoft::VisualBasic::ApplicationServices::StartupNextInstanceEventArgs ^e);
};
}
initializer.cpp
#include "initializer.h"
#include "MyForm.h"
using namespace Project2;
using namespace System;
using namespace System::Windows::Forms;
using namespace Microsoft::VisualBasic::ApplicationServices;
SingleApplication::SingleApplication (void)
{
this->IsSingleInstance = true;
this->EnableVisualStyles = true;
this->StartupNextInstance += gcnew
StartupNextInstanceEventHandler (this, &SingleApplication::StartNextInstance);
}
Void SingleApplication::StartNextInstance (Object ^sender, StartupNextInstanceEventArgs ^e)
{
MyForm ^form = safe_cast<MyForm ^> (this->MainForm);
if (form->IsMinimizedToSystemTray()) form->MakeVisible();
else if (form->WindowState == FormWindowState::Minimized)
{
form->Show();
form->WindowState = FormWindowState::Normal;
}
else form->BringToFront();
form->Focus();
}
void SingleApplication::OnCreateMainForm()
{
this->MainForm = gcnew MyForm();
}
Entry Point:
[STAThread]
int main (array<String ^> ^argv)
{
SingleApplication ^MyApplication = gcnew SingleApplication();
MyApplication->Run (argv);
return 0;
}
Debug log:
A first chance exception of type 'System.Net.Sockets.SocketException' occurred in System.dll
A first chance exception of type 'System.IO.IOException' occurred in System.dll
After enabling break on exceptions i got these details:
1.SocketException:
Additional information: An existing connection was forcibly closed by the remote host
If there is a handler for this exception, the program may be safely continued.
2.IOException:
Additional information: The read operation failed, see inner exception.
If there is a handler for this exception, the program may be safely continued.
What's causing these exceptions and how can handle them?
I think your visual studio debugger is still running basically not terminating properly, it could be that you may still have a thread running in the background that is holding the socket open.
I am trying to define a variable from an external library in C++, Visual Studio 2010. It only works when I put it outside of the main function.
This code crashes:
#include "StdAfx.h"
#include <ogdf\basic\Graph.h>
#include <ogdf\basic\graph_generators.h>
int main()
{
ogdf::Graph g;
ogdf::randomSimpleGraph(g, 10, 20);
return 0;
}
It gives me an unhandheld exception: Access violation.
However, if it is outside main function, it works without any problem:
#include "StdAfx.h"
#include <ogdf\basic\Graph.h>
#include <ogdf\basic\graph_generators.h>
ogdf::Graph g;
int main()
{
ogdf::randomSimpleGraph(g, 10, 20);
return 0;
}
Do you have any how do I fix that? I assume, that it is caused by some kind of linking problem.
EDIT: It looks like the problem is not the initialization of the variable. It throws an exception, when the application exits.
int main()
{
ogdf::Graph g; // No problem
ogdf::randomSimpleGraph(g, 10, 20); // No problem
int i; // No problem
std::cin>>i; // No problem
return 0; // Throws an exception after read i;
}
Call stack:
The output is:
First-chance exception at 0x0126788f in graphs.exe: 0xC0000005: Access violation writing location 0x00000000.
Unhandled exception at 0x0126788f in graphs.exe: 0xC0000005: Access violation writing location 0x00000000.
Works on my machine™.
Esoteric errors like that are often a result of binary incompability. Basically, because of different compiler/preprocessor options, effective headers that your code and the library "see" are different.
For instance, if you have a library with following header code:
class Foo
{
#ifdef FOO_DEBUG
int debug_variable;
#endif
int variable;
};
Library function:
void bar(Foo& foo)
{
std::cout << foo.variable;
}
And client code:
Foo foo;
foo.variable = 666;
bar(foo);
If FOO_DEBUG is not in sync amongst client and the library, this will possibly crash and burn -- variable will have different expected offset.
In your case, I suspect one of the following may be true:
You have built the ogdf with different compiler than your code
If not, you ogdf and your code have different build configurations (Release vs Debug)
Both are debug, but you have defined OGDF_DEBUG (as recommended here)
You have different "Struct Member Alignment" setting
I got this error
Unhandled exception at 0x0049b946 in Program.exe: 0xC0000005: Access violation reading location 0x00000090.
and the error points to this line:
// thread.hpp ln 56
void run()
{
f(); // here <<
}
When trying to run this code:
void frameFunc()
{
for(;;)
{
//..........do something. it is too long to paste. (calculations)
}
}
int main()
{
boost::thread framethread(frameFunc);
framethread.join();
//........
}
The error will simply gone when I remove the loop in frameFunc.
Any kind of help would be appreciated :)
The code that you showed looks valid. I think the problem is inside the code that is not shown.