After porting one huge project from BDS2006 to RAD11 (C++ VCL win32 classic compiler) I found out that one checkbox that should be unchecked at app start is always checked...
After breakpoint/tracing I localized the problem to this function:
void main_caption()
{
if (_simple_gfx) { _GLSL=0; Main->Caption=version+" Simplified graphics."; }
else if (_GLSL) Main->Caption=version+" GLSL";
else Main->Caption=version;
Main->ck_simple_gfx->Checked=_simple_gfx; // WTF here _simple_gfx is handled as true on RAD11 even if its not (even watch list shows false)
Main->ck_GLSL ->Enabled=!_simple_gfx;
Main->ck_GLSL ->Checked=_GLSL;
}
where _simple_gfx is simple global bool set to false (confirmed also with watchlist) used to fall back to OpenGL 1.0 on questionable gfx hardware/drivers (which is not the case now), Main is my main window/form and ck_simple_gfx is the checkbox that should not be checked (but it is checked after the assignment marked with comment WTF).
If I reset the _simple_gfx=false; like this:
void main_caption()
{
if (_simple_gfx) { _GLSL=0; Main->Caption=version+" Simplified graphics."; }
else if (_GLSL) Main->Caption=version+" GLSL";
else Main->Caption=version;
_simple_gfx=false;
Main->ck_simple_gfx->Checked=_simple_gfx; // WTF here _simple_gfx is handled as true on RAD11 even if its not (even watch list shows false)
Main->ck_GLSL ->Enabled=!_simple_gfx;
Main->ck_GLSL ->Checked=_GLSL;
}
then its unchecked as it should. What is happening? the main_caption is called from Main constructor if that matters...
I do not think its related to the VCL checkbox itself because if I do this:
if (_simple_gfx)
the stuff inside get executed while _simple_gfx "is" still false. There is no conflict with _simple_gfx identificator that I know of. If the same code (just different project file) is compiled on older IDE (BDS2006 C++ Turbo Explorer) the code works as should.
Changing the bool _simple_gfx to static and or volatile did not change anything.
Does anyone know what kind of bug is this and how to workaround it?
Did global variables behavior changed in newer versions of C++ Builders? (similar to GC compilers buggy behavior for non volatile global variables on MCU platforms)
Sorry I did not create MCVE as the project is really huge which is most likely the root cause of problem like this.
Related
This is my first question ever posted, so please let me know if there is anything that needs changes in my post :)
I am currently working on a dialog that is supposed to let the user change the background-color for some signal plotting. The "wxColourPickerCtrl" seems to do exactly what I need. Since there are multiple plots/pictures to be manipulated, the ColourPickerCtrls are initialized in a loop with the chosen background color as the default value:
for (const auto& [signalName, signalProperties] : properties)
{
wxColourPickerCtrl* selectBackgroundColor = new wxColourPickerCtrl(this, signalProperties.first, signalProperties.second.backgroundColor, wxDefaultPosition, wxDefaultSize);
}
"this" is an object of type SignalPropertiesDialog, which is directly inherited from wxDialog.
I have left out all the necessary sizer stuff, since it's not relevant for the problem (at least imo). "properties" is structured as follows:
std::map<std::string, std::pair<int, GraphPicture::Properties>> signalProperties_;
where GraphPicture::Properties contains the properties I want to manipulate:
struct Properties
{
wxColour backgroundColor{ *wxWHITE };
wxColour lineColor{ *wxBLACK };
int linewidth_px{ 1 };
bool isShown{ true };
};
The application successfully builds but immediately crashes on startup while generating those color picker objects.
wxIshiko has uploaded multiple tutorials and code snippets as examples for various wxWidgets controls, including the wxColourPickerCtrl. So I downloaded the sample code and tried to run it. Surprisingly, it worked.
While running through the code step by step I noticed the following difference:
The wxColourPickerCtrl is based on wxPickerBase. The wxPickerBase is created by calling the constructor of wxColourPickerCtrl (what I am actually doing in my code). During the construction of the wxPickerBase, the desired color is called by the name wxColourDataBase::FindName(const wxColour& color) const where the wxColourBase itself is instantiated. This is where the difference is:
When running the code snippet by wxIshiko, wxColourDataBase is instantiated correctly including the member m_map of type wxStringToColourHashMap* which is set to be NULL.
When running the code written by myself, wxColourDataBase is not correctly instantiated, and thus the member m_map is not set to be NULL, which leads to to the crash.
I have the feeling that there is nothing wrong with the way I set up the wxColourPickerCtrls. I somehow think there is a difference in the solution properties of the projects. I checked those but was not able to find any relevant differences.
I would really appreciate any hint or help since I am completely stuck on that problem.
Thank you very much in advance and have a good one,
Alex
EDIT:
I attached a screeny of the call stack.
Call stack
When does this code run exactly? If it is done after the library initialization (which would be the case, for example, for any code executed in your overridden wxApp::OnInit()), then wxTheColourDatabase really should be already initialized and what you observe should be impossible, i.e. if it happens it means that something is seriously wrong with your library build (e.g. it doesn't match the compiler options used when compiling your applications).
As always with such "impossible" bugs, starting with a known working code and doing bisection by copying parts of your code into the working version until it stops working will usually end up by finding a bug in your code.
Not sure how to word the title so feel free to rename, but the issue I'm having is that I've got a function that works in one project, but fails in another. Below is rough pseudocode to show that one call in LibraryProject works, whereas the call in GameProject doesn't.
In ChildClass::do_stuff, the win32_window HWND is valid, whereas the second one, failed_win32_window is null and glfw throws an error saying it isn't initialized, despite it already having been initialized (since the first glfw call was successful and I've manually stepped through to verify it was):
GLFWError #65537 Happen, The GLFW library is not initialized
Here's pseudocode showing the two projects, and the files. GLFW is set initialized properly since if I do all my glfw logic within LibraryProject, the window shows up as normal.
//LibraryProject
////library_header.h
class ParentClass {
GLFW* _mainWindow; //filled in elsewhere in the real code
HWND getWin32Window() { return glfwGetWin32Window(_mainWindow); }
}
//GameProject
////game_header.h
#include "library_header.h" //from other Project
class ChildClass : public ParentClass {
void do_stuff() {
HWND win32_window = this->getWin32Window(); //this works because it goes down into LibraryProject.dll's module
HWND failed_win32_window = glfwGetWin32Window(_mainWindow); //but literally the same call here doesn't because it happens within GameProject.exe
}
}
////game_body.cpp
void function_called_elsewhere_in_game() {
//called from GameProject.exe
auto child = ChildClass();
child.do_stuff();
}
I'm not sure if this is an issue with glfw and my setup, or just my misunderstanding how projects and dependencies work.
Things I've tried:
Downloading the latest glfw3
Rebuilding the entire solution
Toggling with References and Linking Dependency Inputs
Things to note:
This is happening in the main thread, nothing else is using glfw at the same time. Its 100% reproducible too.
glfw3.lib is always being created in my GameProject output folder, based on the one inside LibraryProject
Stepping through the disassembly for each of the two glfwGetWin32Window calls has different addresses in disassembly, leading me to believe they're two different copies of the same library, but I'm not sure.
This is not an issue with cocos2d, the game engine I'm using as starting a blank project and calling glfwGetWin32Window(..) returns a valid pointer, even in GameProject, so there's something that I'm doing wrong, but I don't know what.
Images showing off the actual behaviour. magnolia_cocos_proj is GameProject and is the exe I'm running, and libcocos2d is LibraryProject I'm using as a DLL (I'm unfamiliar with the details of how linking and dlls work).
win32_window has valid value
definition of getWin32Window() to be 100% sure. Notice the module is in libcocos2d.dll now.
after going over the second line, the error throws and the second window is null
As I understood from "glfw3.lib is always being created" you use static linking. Static linking of a lib to different dll and exe lead to duplicating of all static memory of the lib. You should use a dynamic library for GLFW in the case. It's glfw3dll.lib.
There are two main cases why this error could appear:
GLFWError #65537 Happen, The GLFW library is not initialised
Case One :
The mentioned error occurs if a GLFW function was called that mustn't be called unless the library is initialised. So, you need to initialise GLFW before calling any function that requires initialisation.
Read an API introduction for reference. Use if-else statement for handling glfwInit() and errors.
Reading Moving from GLFW 2 to 3 is also useful.
Case Two :
This error quite often occurs in the case you have previous versions of GLFW installed on your machine. GLFW3 doesn't like running along with previous version installed. So, delete all the GLFW libraries and linkers and reinstall the latest GLFW 3 from scratch.
Hope this helps.
Let me elaborate on the title:
I want to implement a system that would allow me to enable/disable/modify the general behavior of my program. Here are some examples:
I could switch off and on logging
I could change if my graphing program should use floating or pixel coordinates
I could change if my calculations should be based upon some method or some other method
I could enable/disable certain aspects like maybe a extension api
I could enable/disable some basic integrated profiler (if I had one)
These are some made-up examples.
Now I want to know what the most common solution for this sort of thing is.
I could imagine this working with some sort of singelton class that gets instanced globally or in some other globally available object. Another thing that would be possible would be just constexpr or other variables floating around in a namespace, again globally.
However doing something like that, globally, feels like bad practise.
second part of the question
This might sound like I cant decide what I want, but I want a way to modify all these switches/flags or whatever they are actually called in a single location, without tying any of my classes to it. I don't know if this is possible however.
Why don't I want to do that? Well I like to make my classes somewhat reusable and I don't like tying classes together, unless its required by the DRY principle and or inheritance. I basically couldn't get rid of the flags without modifying the possible hundreds of classes that used them.
What I have tried in the past
Having it all as compiler defines. This worked reasonably well, however I didnt like that I couldnt make it so if the flag file was gone there were some sort of default settings that would make the classes themselves still operational and changeable (through these default values)
Having it as a class and instancing it globally (system class). Worked ok, however I didnt like instancing anything globally. Also same problem as above
Instancing the system class locally and passing it to the classes on construction. This was kinda cool, since I could make multiple instruction sets. However at the same time that kinda ruined the point since it would lead to things that needed to have one flag set the same to have them set differently and therefore failing to properly work together. Also passing it on every construction was a pain.
A static class. This one worked ok for the longest time, however there is still the problem when there are missing dependencies.
Summary
Basically I am looking for a way to have a single "place" where I can mess with some values (bools, floats etc.) and that will change the behaviour of all classes using them for whatever, where said values either overwrite default values or get replaced by default values if said "place" isnt defined.
If a Singleton class does not work for you , maybe using a DI container may fit in your third approach? It may help with the construction and make the code more testable.
There are some DI frameworks for c++, like https://github.com/google/fruit/wiki or https://github.com/boost-experimental/di which you can use.
If you decide to use switch/flags, pay attention for "cyclometric complexity".
If you do not change the skeleton of your algorithm but only his behaviour according to the objets in parameter, have a look at "template design pattern". This method allow you to define a generic algorithm and specify particular step for a particular situation.
Here's an approach I found useful; I don't know if it's what you're looking for, but maybe it will give you some ideas.
First, I created a BehaviorFlags.h file that declares the following function:
// Returns true iff the given feature/behavior flag was specified for us to use
bool IsBehaviorFlagEnabled(const char * flagName);
The idea being that any code in any of your classes could call this function to find out if a particular behavior should be enabled or not. For example, you might put this code at the top of your ExtensionsAPI.cpp file:
#include "BehaviorFlags.h"
static const enableExtensionAPI = IsBehaviorFlagEnabled("enable_extensions_api");
[...]
void DoTheExtensionsAPIStuff()
{
if (enableExtensionsAPI == false) return;
[... otherwise do the extensions API stuff ...]
}
Note that the IsBehaviorFlagEnabled() call is only executed once at program startup, for best run-time efficiency; but you also have the option of calling IsBehaviorFlagEnabled() on every call to DoTheExtensionsAPIStuff(), if run-time efficiency is less important that being able to change your program's behavior without having to restart your program.
As far as how the IsBehaviorFlagEnabled() function itself is implemented, it looks something like this (simplified version for demonstration purposes):
bool IsBehaviorFlagEnabled(const char * fileName)
{
// Note: a real implementation would find the user's home directory
// using the proper API and not just rely on ~ to expand to the home-dir path
std::string filePath = "~/MyProgram_Settings/";
filePath += fileName;
FILE * fpIn = fopen(filePath.c_str(), "r"); // i.e. does the file exist?
bool ret = (fpIn != NULL);
fclose(fpIn);
return ret;
}
The idea being that if you want to change your program's behavior, you can do so by creating a file (or folder) in the ~/MyProgram_Settings directory with the appropriate name. E.g. if you want to enable your Extensions API, you could just do a
touch ~/MyProgram_Settings/enable_extensions_api
... and then re-start your program, and now IsBehaviorFlagEnabled("enable_extensions_api") returns true and so your Extensions API is enabled.
The benefits I see of doing it this way (as opposed to parsing a .ini file at startup or something like that) are:
There's no need to modify any "central header file" or "registry file" every time you add a new behavior-flag.
You don't have to put a ParseINIFile() function at the top of main() in order for your flags-functionality to work correctly.
You don't have to use a text editor or memorize a .ini syntax to change the program's behavior
In a pinch (e.g. no shell access) you can create/remove settings simply using the "New Folder" and "Delete" functionality of the desktop's window manager.
The settings are persistent across runs of the program (i.e. no need to specify the same command line arguments every time)
The settings are persistent across reboots of the computer
The flags can be easily modified by a script (via e.g. touch ~/MyProgram_Settings/blah or rm -f ~/MyProgram_Settings/blah) -- much easier than getting a shell script to correctly modify a .ini file
If you have code in multiple different .cpp files that needs to be controlled by the same flag-file, you can just call IsBehaviorFlagEnabled("that_file") from each of them; no need to have every call site refer to the same global boolean variable if you don't want them to.
Extra credit: If you're using a bug-tracker and therefore have bug/feature ticket numbers assigned to various issues, you can creep the elegance a little bit further by also adding a class like this one:
/** This class encapsulates a feature that can be selectively disabled/enabled by putting an
* "enable_behavior_xxxx" or "disable_behavior_xxxx" file into the ~/MyProgram_Settings folder.
*/
class ConditionalBehavior
{
public:
/** Constructor.
* #param bugNumber Bug-Tracker ID number associated with this bug/feature.
* #param defaultState If true, this beheavior will be enabled by default (i.e. if no corresponding
* file exists in ~/MyProgram_Settings). If false, it will be disabled by default.
* #param switchAtVersion If specified, this feature's default-enabled state will be inverted if
* GetMyProgramVersion() returns any version number greater than this.
*/
ConditionalBehavior(int bugNumber, bool defaultState, int switchAtVersion = -1)
{
if ((switchAtVersion >= 0)&&(GetMyProgramVersion() >= switchAtVersion)) _enabled = !_enabled;
std::string fn = defaultState ? "disable" : "enable";
fn += "_behavior_";
fn += to_string(bugNumber);
if ((IsBehaviorFlagEnabled(fn))
||(IsBehaviorFlagEnabled("enable_everything")))
{
_enabled = !_enabled;
printf("Note: %s Behavior #%i\n", _enabled?"Enabling":"Disabling", bugNumber);
}
}
/** Returns true iff this feature should be enabled. */
bool IsEnabled() const {return _enabled;}
private:
bool _enabled;
};
Then, in your ExtensionsAPI.cpp file, you might have something like this:
// Extensions API feature is tracker #4321; disabled by default for now
// but you can try it out via "touch ~/MyProgram_Settings/enable_feature_4321"
static const ConditionalBehavior _feature4321(4321, false);
// Also tracker #4222 is now enabled-by-default, but you can disable
// it manually via "touch ~/MyProgram_Settings/disable_feature_4222"
static const ConditionalBehavior _feature4222(4222, true);
[...]
void DoTheExtensionsAPIStuff()
{
if (_feature4321.IsEnabled() == false) return;
[... otherwise do the extensions API stuff ...]
}
... or if you know that you are planning to make your Extensions API enabled-by-default starting with version 4500 of your program, you can set it so that Extensions API will be enabled-by-default only if GetMyProgramVersion() returns 4500 or greater:
static ConditionalBehavior _feature4321(4321, false, 4500);
[...]
... also, if you wanted to get more elaborate, the API could be extended so that IsBehaviorFlagEnabled() can optionally return a string to the caller containing the contents of the file it found (if any), so that you could do shell commands like:
echo "opengl" > ~/MyProgram_Settings/graphics_renderer
... to tell your program to use OpenGL for its 3D graphics, or etc:
// In Renderer.cpp
std::string rendererType;
if (IsDebugFlagEnabled("graphics_renderer", &rendererType))
{
printf("The user wants me to use [%s] for rendering 3D graphics!\n", rendererType.c_str());
}
else printf("The user didn't specify what renderer to use.\n");
I am currently using TGUI (a GUI library based on SFML) together with ECL (so I can use Lisp for config and scripts). It works fine on Linux/gcc, but on Windows/MinGW ECL throws an error:
Condition of type: FLOATING-POINT-INVALID-OPERATION
#<a FLOATING-POINT-INVALID-OPERATION>
Available restarts:
1. (CONTINUE) Ignore signal
Top level in: #<process TOP-LEVEL>.
>
The point in code at which the error is thrown (minimal code that creates it) is:
empty_panel = tgui::Panel::Ptr(*cur_gui, "empty_panel");
empty_panel->setSize(cfg.res.x, cfg.res.y);
empty_panel->setBackgroundColor(sf::Color::Transparent);
tgui::EditBox::Ptr txt_test(*empty_panel, "txt_test");
Note that I can create Labels, Buttons, Checkboxes, etc. just fine - but once I try to make an Edit Box, ECL complains.
This does not make any sense to me whatsoever. TGUI and ECL are completely unrelated libraries, not sharing functions or depending on each other in any way that I know of. Does anyone have an idea what might cause this behavior?
EDIT: Just did a complete recompile of SFML, TGUI and ECL with the most recent version of MinGW, and it still breaks in exactly the same way. So I've decided that enough is enough and I'll rewrite my project to use SFGUI instead.
From now on, this question is of academic interest only.
I finally found out what might have happened there:
While ECL is running, it tries to handle all uncaught exceptions, segfaults, etc that happen on it's watch, even if they never interact with LISP. And the way it handles them is by immediately jumping to the REPL when they occur, to allow for manual debugging.
Which is the sane thing to do for anything that happens because of errors in a LISP program or C/C++ functions that interact with it, but is mildly confusing when the error happens in unrelated C++ code (like the presumed bug in TGUI).
Minimal way to reproduce: Load ECL and try some invalid operation, like so:
#include <ecl/ecl.h>
int main(int argc, char **argv) {
cl_boot(argc, argv);
atexit(cl_shutdown);
int x = 1/0;
return EXIT_SUCCESS; }
Our unit tests fire off child processes, and sometimes these child processes crash. When this happens, a Windows Error Reporting dialog pops up, and the process stays alive until this is manually dismissed. This of course prevents the unit tests from ever terminating.
How can this be avoided?
Here's an example dialog in Win7 with the usual settings:
If I disable the AeDebug registry key, the JIT debugging option goes away:
If I disable checking for solutions (the only thing I seem to have control over via the control panel), it looks like this, but still appears and still stops the program from dying until the user presses something. WerAddExcludedApplication is documented to also have this effect.
A summary from the answers by jdehaan and Eric Brown, as well as this question (see also this question):
N.B. These solutions may affect other error reporting as well, e.g. failure to load a DLL or open a file.
Option 1: Disable globally
Works globally on the entire user account or machine, which can be both a benefit and a drawback.
Set [HKLM|HKCU]\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI to 1.
More info: WER settings.
Option 2: Disable for the application
Requires modification to the crashing program, described in documentation as best practice, unsuitable for a library function.
Call SetErrorMode: SetErrorMode(SetErrorMode(0) | SEM_NOGPFAULTERRORBOX); (or with SEM_FAILCRITICALERRORS). More info: Disabling the program crash dialog (explains the odd arrangement of calls).
Option 2a: Disable for a function:
Requires modification to the crashing program, requires Windows 7/2008 R2 (desktop apps only) or higher, described in documenation as preferred to SetErrorMode, suitable for a thread-safe library function.
Call and reset SetThreadErrorMode:
DWORD OldThreadErrorMode = 0;
SetThreadErrorMode(SEM_FAILCRITICALERRORS,& OldThreadErrorMode);
…
SetThreadErrorMode (z_OldThreadErrorMode, NULL);
More info: not much available?
Option 3: Specify a handler
Requires modification to the crashing program.
Use SetUnhandledExceptionFilter to set your own structured exception handler that simply exits, probably with reporting and possibly an attempt at clean-up.
Option 4: Catch as an exception
Requires modification to the crashing program. For .NET applications only.
Wrap all code into a global try/catch block. Specify the HandleProcessCorruptedStateExceptionsAttribute and possibly also the SecurityCriticalAttribute on the method catching the exceptions. More info: Handling corrupted state exceptions
Note: this might not catch crashes caused by the Managed Debugging Assistants; if so, these also need to be disabled in the application.
Option 5: Stop the reporting process
Works globally on the entire user account, but only for a controlled duration.
Kill the Windows Error Reporting process whenever it shows up:
var werKiller = new Thread(() =>
{
while (true)
{
foreach (var proc in Process.GetProcessesByName("WerFault"))
proc.Kill();
Thread.Sleep(3000);
}
});
werKiller.IsBackground = true;
werKiller.Start();
This is still not completely bullet-proof though, because a console application may crash via a different error message, apparently displayed by an internal function called NtRaiseHardError:
The only solution is to catch all exceptions at a very high level (for each thread) and terminate the application properly (or perform another action).
This is the only way to prevent the exception from escaping your app and activating WER.
Addition:
If the exception is something you do not except to happen you can use an AssertNoThrow(NUnit) or alike in another Unit Test framework to enclose the code firing the child processes. This way you would also get it into your Unit test report. This is in my opinion the cleanest possible solution I can think of.
Addition2:
As the comments below show, I was mistaken: you cannot always catch the asynchronous exceptions, it depends on what the environment allows. In .NET some exceptions are prevented from being caught, what makes my idea worthless in this case...
For .NET: There are complicated workarounds involving the use of AppDomains, leading to an unload of an AppDomain instead of a crash of the whole application. Too bad...
http://www.bluebytesoftware.com/blog/PermaLink,guid,223970c3-e1cc-4b09-9d61-99e8c5fae470.aspx
http://www.develop.com/media/pdfs/developments_archive/AppDomains.pdf
EDIT:
I finally got it. With .NET 4.0 You can add the HandleProcessCorruptedStateExceptions attribute from System.Runtime.ExceptionServices to the method containing the try/catch block. This really worked! Maybe not recommended but works.
using System;
using System.Reflection;
using System.Runtime.InteropServices;
using System.Runtime.ExceptionServices;
namespace ExceptionCatching
{
public class Test
{
public void StackOverflow()
{
StackOverflow();
}
public void CustomException()
{
throw new Exception();
}
public unsafe void AccessViolation()
{
byte b = *(byte*)(8762765876);
}
}
class Program
{
[HandleProcessCorruptedStateExceptions]
static void Main(string[] args)
{
Test test = new Test();
try {
//test.StackOverflow();
test.AccessViolation();
//test.CustomException();
}
catch
{
Console.WriteLine("Caught.");
}
Console.WriteLine("End of program");
}
}
}
Try setting
HKCU\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI
to 1. (You can also set the same key in HKLM, but you need admin privs to do that.)
This should prevent WER from showing any UI.