The linker for an iOS simulator target I have is reporting the following warning:
ld: warning: too many personality routines for compact unwind to encode
No line number is given, nor anything else that is actionable. Googling turned up some Apple open source code, but I'm not groking it.
What does it mean and what can I do to address it?
I found some information in the C++ ABI for Itanium docs that sheds some light on what this means.
The personality routine is the function in the C++ (or other language) runtime library which serves as an interface between the system unwind library and language-specific exception handling semantics.
Extrapolating, this warning indicates that you've got too many kinds of exception handling in the same binary, and at least one of them may fail. Indeed this is exactly what is observed in this question.
Sadly, there's no clear way to fix this, only workarounds. You can suppress the warning, remove code, rewrite code in a different language, disable a language's exception handing and possibly others.
If you have a crash on exception with this warning, i.e. ::terminate() call on every throw, the workaround is to use old dwarf exception-handling tables. Add following flags to Build Settings/Linking/Other Linker Flags:
-Wl,-keep_dwarf_unwind -Wl,-no_compact_unwind
You can try silencing the warning with -Wl,-no_compact_unwind for the Other Linker Flags setting. I think it's harmless.
I bumped into this issue as well when trying to run on the iOS simulator while my code was running correctly on the device. In my case, it was not a warning but a linker error.
Luckily, i remembered that I added two flags for luajit to run correctly following the instructions of this page under the section Embedding LuaJIT:
-pagezero_size 10000 -image_base 100000000
My guess is that the image_base address is simply out of bounds on the host CPU.
Anyway, removing these settings made it work in my configuration.
So go to your project's settings and look for any hard wired values of this kind if not the same.
Hope this helps,
M
Related
I'm working on some OpenCL code within a larger project. The code only gets compiled at run-time - but I don't want to deploy a version and start it up just for that. Is there some way for me to have the syntax of those kernels checked (even without consider), or even compile them, at least under some restrictions, to make it easier to catch errors earlier?
I will be targeting AMD and/or NVIDIA GPUs.
The type of program you are looking for is an "offline compiler" for OpenCL kernels - knowing this will hopefully help with your search. They exist for many OpenCL implementations, you should check availability for the specific implementation you are using; otherwise, a quick web search suggests there are some generic open source ones which may or may not fit the bill for you.
If your build machine is also your deployment machine (i.e. your target OpenCL implementation is available on your build machine), you can of course also put together a very basic offline compiler yourself by simply wrapping clBuildProgram() and friends in a basic command line utility.
Currently I'm running into a known problem with asan (See report)
==5097==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.
==5097==ASan shadow was supposed to be located in the [0x00007fff7000-0x10007fff7fff] range.
Is it possible to use an environment variable to stop asan being used to prevent this error?
Or at least stop this error from being fatal.
The reason I want to do this is the failing command happens when generating code, but I'd like to use asan for the resulting binary. Having different CFLAGS for generated binaries and the final binary is possible but it would be hard to do without hard-coding it in for everyone else. So I'd like a way to disable asan during the build step, but use afterwards.
Edit: in case it's useful, this occurs with an extremely simple program: Error, Code.
No, this is a fundamental error which prevents all later instrumentation by Asan from working correctly. E.g. stack poisoning in function prologues would end up causing segfaults or corrupting random memory.
The error you reported is not an addressabilty error found by address sanitizer but an issue with the address sanitizer itself. Read the FAQ here. Reporting here the part that is relevant to your case:
Q: I'm using dynamic ASan runtime and my program crashes at start with
"Shadow memory range interleaves with an existing memory mapping. ASan
cannot proceed correctly.".
A1: If you are using shared ASan DSO, try LD_PRELOAD'ing Asan runtime
into your program.
If the dynamic linker/loader is itself a shared object file, how is it properly loaded into a dynamically linked program's process image space if it's not already there? Is this some kind of catch 22 thing?
This answer provides some details (although there are technical mistakes in it).
Is this some kind of catch 22 thing?
Yes: ld.so is special -- it is a self-relocating binary.
It starts by carefully executing code that doesn't require any relocations. That code relocates ld.so itself. After this self-relocation / bootstrap process is done, ld.so continues just as a regular shared library.
Refer to
Oracle Solaris 11.1 Linkers and Libraries Guide
It's the best linkers reference that I have come across, concise and explains things well.
On page 89:
As part of the initialization and execution of a dynamic executable,
an interpreter is called to complete the binding of the application to
its dependencies. In the Oracle Solaris OS, this interpreter is
referred to as the runtime linker.
During the link-editing of a dynamic executable, a special .interp section, together with an
associated program header, are created. This section contains a path
name specifying the program's interpreter. The default name supplied
by the link-editor is the name of the runtime linker: /usr/lib/ld.so.1
for a 32–bit executable and /usr/lib/64/ld.so.1 for a 64–bit
executable.
Note – ld.so.1 is a special case of a shared object. Here,
a version number of 1 is used. However, later Oracle Solaris OS
releases might provide higher version numbers.
During the process of
executing a dynamic object, the kernel loads the file and reads the
program header information. See “Program Header” on page 371. From
this information, the kernel locates the name of the required
interpreter. The kernel loads, and transfers control to this
interpreter, passing sufficient information to enable the interpreter
to continue executing the application.
This is a very strange situation. Why do I get error
CL_PLATFORM_NOT_FOUND_KHR
when I'm calling this function:
clGetPlatformIDs(0, NULL, &platformCount);
Earlier this error was not. I have installed the driver and SDK from Intel and Nvidia. Are there any suggestions?
Here is explained why such error can occur. clGetPlatformIDs returns CL_SUCCESS if the function is executed successfully and there are a non-zero number of platforms available. Otherwise it can return CL_PLATFORM_NOT_FOUND_KHR if the cl_khr_icd extension is enabled and no platforms are found.
You are in luck. Well sort of... Seeing this is 3 years later.
Disclaimer: I HAVE NO CLUE WHY THIS WORKS:
Machine: x64 windows 10.
Graphics Card: Geforce GTX 960
Total Failure To Load Library : LoadLibraryA( "OpenCL64.dll" )
WRONG (but loads) : LoadLibraryA( "C:/Program Files/NVIDIA Corporation/OpenCL/OpenCL64.dll" )
WRONG (but loads) : LoadLibraryA( "C:/Program Files/NVIDIA Corporation/OpenCL/OpenCL.dll" )
CORRECT: LoadLibraryA( "OpenCL.dll" )
Here is the really insideous thing: Both of my "WRONG" answers will let you
grab function pointers, but when you call clGetPlatformIDs the return status
will be 0xFFFFFC17 ( CL_PLATFORM_NOT_FOUND_KHR ).
Then you'll be examining your function call correctness.
Maybe you'll even look at the calling convention. Maybe you'll check
the header files and make sure there are not any typos there. And yet,
you are looking in all the wrong places because the original problem happened
more steps back than you think.
Because of this problem, I build into my programs code that reads a file:
"OPEN_CL_SEARCH_PATHS.TXT" so the user of the software can change what DLL file
the program attempts to load.
While I am here, I would also like to add that there seems to be a bug with the
driver that makes it so OpenCL <==> OpenGL sharing is NOT a zero-copy share and
is incredibly laggy. Now I've got to go figure out Vulkan to make my fractal
rendering engine even though OpenCL's abstraction better suits the problem.
It is probably important to note that I am NOT using an SDK or any
validation layers. In fact, I am not even using
windows.h.
I wrote assembly code to grab the address of GetProcAddress and LoadLibrary by navigating the PEB file. I am also not using cl.h or cl_platform.h.
I reconstruct the structs I need from the documentation. I am also not
bothering with prototypes for function signatures either. For example,
I call "clGetPlatformIDs" by casting it to type "F_03" and then
calling it that way.
typedef void* (F_03)( void, void*, void* );
My machine doesn't have GPU and so had to use hashcat with OpenCL for CPU alone. My machine was Intel core i3, so I have downloaded the OpenCL softwares from Intel website and installed manually and the error gone.
Source: https://youtu.be/AieYqNQ6ADM
Why do server errors occur on running a solution, even if the solution is building successfully?
Compile time versus run-time errors. See this stackoverflow thread for the difference between these two.
From wikipedia:
Thus, for example, a "run-time error" is detected only during the execution of the program, whereas a "compile-time error" is detected by the compiler before the program is started.
It's impossible for the compiler to catch all errors beforehand: see the 'halting problem'.
There are several possibilities:
Difference in run-time vs. compile-time environments (version of .NET, version of IIS, system-level web.config or machine.config or applicationHost.config, etc)
Run-time errors vs. compile-time errors
Different security environment / permissions
Different database connection string requirements
Using IIS vs. Cassini
If you have dynamic references (eg. if you're using NHibernate, for example), it's possible that there are references to an assembly that's not present. These kind of references cannot be picked up by the compiler. It's only one of many possible situations where you'll get a run-time error that's not logic related.
As Q8-coder said, what is the error? Impossible to give solutions without knowing what the error is.