"Unable to open file libc++abi.dylib". Program builds, but crashes upon being run. Using xcode 10.1 (10B61) - c++

newbie here. I am following along this SFML flappy bird tutorial. I am currently stuck at this portion of stage creation where a "Splash State" (or logo loading screen) is made. The code of which is exactly the same as what is shown here.
I am using xcode 10.1.
The project builds. But when I tried running it, it crashes and I am greeted with the following:
Failed to load image "Resouces/res/Splash Background.png". Reason: Unable to open file
libc++abi.dylib: terminating with uncaught exception of type std::out_of_range: map::at: key not found
(lldb)"
If I understand it correctly, it's saying it cannot perform the action of loading the image at the aforementioned path because it is not able to open "libc++abi.dylib". And now the program is being terminated. (please help me understand this problem better by either confirming or correcting me here).
When I tried looking for "libc++abi.dylib", it is missing. Instead, I can only find "libc++abi.td".
This thread says to add that under Link Binary With Libraries. That did not produce any result.
The tutorial shows that the code runs and a "Splash State" or logo screen is expected to appear. Instead my program crashes and I am greeted with the aforementioned error.
I was wondering if anyone else ran into similar issues?

It's solved. It is made by a typo on my end... sorry.
I'll try my best to explain it here for those of you who may have the same issues:
The game asset is governed by a map, which is a private member variable of a "AssetManager" class. The typo is at the file path. Because of this, the map never inserted the key since the file path isn't valid.
When the map is later accessed, it would be out of range since nothing ever got inserted (since the asset did not load).
Basically, the error of not being to open "libc++abi.dylib" is caused by the map being out of range.

Related

OCaml: Error while trying to open a graph - 'Exception: Graphics.Graphic_failure "Cannot open display ".'

I'm trying to get back into programming with OCaml after a long time of not using it, and since I don't have Linux on my current computer, I've been trying to do it through WSL (Windows Subsystem for Linux).
After doing everything as I would have in Linux, whenever I try to compile a piece of code using the Graphics module, I get the following outcomes:
If I try to use the open_graph command, I get the following error:
Exception: Graphics.Graphic_failure "Cannot open display ".
I get that exact error if the argument of open_graph is an empty string, or starts with a space. If the string argument is not empty and doesn't start with a space (which, from what I've read, shouldn't be used anyway), the error message includes said argument as follows:
Exception: Graphics.Graphic_failure "Cannot open display [argument of open_graph]".
If the code only uses base OCaml commands and Graphics commands that doesn't require an open graph (like rgb), everything compiles normally.
I found this thread where users raised the question of the DISPLAY variable possibly being "wrong". The original poster of said thread has a different issue, but I felt it is relevant, as I was thinking that perhaps using WSL could have made my DISPLAY variable "off", or could require me to use a different value for DISPLAY than I would use on a complete Linux OS - but, to be perfectly honest, I have no idea what that would be.
I tried my best to understand everything I read and to explain my issue clearly, but I only have moderate experience with Linux and programming in general, so I'm sorry if I misunderstood something or if my explanations weren't the clearest. In that case, please let me know, and I will try my best to rectify it.
Cheers!
Example of complete code and exact error message:
#use "topfind";; #require "graphics";; Graphics.open_graph "";;
Error message returned:
Exception: Graphics.Graphic_failure "Cannot open display ".
According to https://github.com/ocaml/graphics/issues/21 you need to install a X11 server in your WSL environment.

LINK 1104: Cannot open file '...test.exe' randomly occurred

I'm a beginner C++ developer working on a quality assurance project utilizing the GoogleTest framework. While creating unit tests, to verify whether solution outputs were within an acceptable range or not, I received the error message of " LINK1104: cannot open file 'C:Users\kfung\Documents\SAM\sam_dev\ssc\build_vs2017\x64\Release\test.exe' ".
It came out of nowhere. I've been working within the SAM\sam_dev branch for quite sometime now, where I have complete access to this. On top of that, this error message came after trying to build my solution. When this message came, I was only changing integer values, so I do not think it really is linked to that action. It wasn't anything major.
The test.exe program works fine and is able to test all of the files within my test explorer. The program works, yet VS17 is unable to locate/use this file.
I've searched throughout stack overflow and google and nothing like my issue has been discussed. The error has came out of nowhere with nothing really to prompt it.
I've tried "resetting" my development branch on Gitbash using the commands "checkout -- . ", where I should have reverted my project to it's workings state before this occurred. This did not effect my solution where the error keeps occurring.
What should I do?

Chromium-browser build fatal errors in module_list.cc: Check Failed

I've been trying to build chromium on Windows 10, but I am getting weird errors on runtime, which appear to be caused by that pattern:
void CheckFreeLibrary(HMODULE module) {
BOOL result = ::FreeLibrary(module);
DCHECK(result);
}
The first errors are displayed after a few seconds after Chromium is started. Here's what it says:
[5904:9192:0726/025753:FATAL:module_list.cc(18)] Check failed: result.
Backtrace:
base:debug:StackTrace:StackTrace [0x0000....] (e:\projects\clones\chromium\src\base\debug\stack_trace.cc) ...
Since I couldn't copy paste the whole stack, I will join a screenshot of what it all feels like:
I am successful in building the last revision, or at least, it appears to be successful since no errors are showing up when compiling with the toolchain recommended in Building instructions.
Luckily, the first errors aren't modal and it is possible to browse a little bit afterwards. Then, if I put the application into heavy loading (such as Facebook newsfeed), it will suddently stop responding in a silent way. Mouse hovering effects will not show anymore and reloading the page will result in infinite loading. This behavior is also reproductible when right-clicking on some pages (e.g.: google's home page does it sometimes).
What could be an explanation of this not working "out of the box" with default configuration? How to fix this?
P.S.: This question is complementary to this question:
Windows chromium-browser fresh build stacktrace and anonymous fatal errors on runtime, if it can help getting the big picture of the question.
P.S.2.: I am currently trying to rebuild from start again with this slight change to see if it works out better. I will be able to see it after about 10 hours, though (yes, the build is painful on my current setup).
void CheckFreeLibrary(HMODULE module) {
BOOL result = ::FreeLibrary(module);
if (!result) {
result = ::UnmapViewOfFile(module);
}
DCHECK(result);
}
Update - 2016/07/29
Test with CheckFreeLibrary still failed in debug, but I finally found a way to resolve the issues in a build. See update 3 in superuser question. What I did was configuring the build into release mode via gn args. This is, obviously, almost impossible to debug with, so a solution / explanation is yet to be found about why it fails in debug mode. This is quite close now, though.
Update 2 - 2016/08/13
Started all over again to have a debug version again with the latest version in the repositories, and this time I was sure enough to find something. In fact, after I've run through the usual procedure to update, generate and build, I noticed that some win-core-* DLL libraries located in the Windows Kit debugger weren't copied src folder but one of those was assumed to be there during the link process. As a precaution, I've simply copied them all to be sure that any delay-load or build dependency was there. The first time chromium has launched, the errors didn't show up and thought it was resolving the issue. However, right-clicking on the Google Homepage had the same effect (no response, then browser not showing pages anymore). After closing and reopening it, errors are beginning to show up.
Is there anyone that had experienced that? I would be very happy with something like "do it on linux, it works better on this platform". I am not willing to do it without knowing it will work any better, though.
So
BOOL result = ::FreeLibrary(module);
fails in debug builds see if you have a
DWORD WINAPI GetLastError(void);
to get the real error.
I could guess
module not loaded
module is NULL
Perhaps some DEBUG statement is changing the value of module?

Qt5/c++ generating 'Corrupted shared library list' error during debug

I have a Qt5/C++ app which appears to be working fine, but when running in debug mode (GDB), this error pops up on the QT Creator console (stderr) - OCCASIONALLY!:
Corrupted shared library list: 0x7fffe8008e90 != 0x751e50
I can't find any reference to the cause, and I can't figure out what is triggering it (other that something to do with using a QLinkedList.) I tried switching to a QVector but sometimes the same error pops up.
What is this and how do I fix it? Valgrind says no memory corruption...so is this a false reporting issue? Or am I doing something wrong.
I've traced the above error to the last line (line 4) below.
Settings *programSettings = Settings::instance();
QString driver=programSettings->database_driver();
driver="QMYSQL"; // Override for testing
m_db = QSqlDatabase::addDatabase(driver);
This makes no sense to me...can someone explain why the QSqlDatabase::addDatabase line causes corruption? As well, why does the error ONLY appear when debugging...but not when running without gdb?
Based on the number of views there seem to be a lot of people with this issue. We pared the code down to a simple example and then reproduced the problem. The source of the problem is not user code, but Qt Creator itself. We can't go much further - just put up with it until a Qt Creator fix comes along.
It looks like you're writing over memory that doesn't belong to yourself. It looks like you're dereferencing a pointer that has an uninitialized value. Compile your application with all warnings enabled, and make sure you understand all of the warnings. After that you may need to start a code audit, after you minimize the code of course.

iOS: execl(3) doesn't work anymore

I'm trying to call execl within my iOS application, which is running in the iPhone Simulator. But that fails. Xcode shows this error:
error: address doesn't contain a section that points to a section in a object file
When going step by step, this error pops up at the moment when I try to step into execl.
So, this makes me think that there is a problem with that very specific method. That it actually doesn't exist in the compiled executable? Do I need to link specific libraries? I tried this as well:
printf("execl(): %llx", &execl); // get the address of that method
Which prints values like: execl(): 3aeee0e. However, when debugging it states: EXC_BAD_ACCESS and Thread 1: 0x0000000.
Any ideas? I also tried methods like execve(), but give the exact same result. In the past, the exact same code work perfect.
For those who know what I'm talking about: Yes, I really want to use valgrind and not the tools by Apple.