I am trying to use the StackWalker which is used to get the call stacks. While when running, the 487 error shows. Does anybody have some idea?
It just means that StackWalker couldn't find debugging information for the function at that point in the backtrace. You can just ignore it if you don't need know the source file and line number for that function. You can make it go way for functions in Windows components by using the Microsoft symbol server: http://support.microsoft.com/?kbid=311503
Related
I'm running the following realsense2_camera launch command:
roslaunch realsense2_camera rs_rgbd.launch
I see this error:
04/01 22:02:12,523 WARNING [139805191870208] (types.cpp:49) Out of frame resources!
04/01 22:02:12,523 ERROR [139805191870208] (synthetic-stream.cpp:47) Exception was thrown during user processing callback!
There's a few problems with trying to debug this:
1. We are using the compiled realsense-ros library, so there's no types.cpp we can find on our system.
The message "Out of frame resources!" is uninformative. Looking at types.cpp here: http://docs.ros.org/kinetic/api/librealsense2/html/types_8cpp_source.html
It's still uninformative, as types.cpp line 47 is just generic error handling code:
45 recoverable_exception::recoverable_exception(const std::string& msg,
46 rs2_exception_type exception_type) noexcept
47 : librealsense_exception(msg, exception_type)
48 {
49 LOG_WARNING(msg);
50 }
How do we see the code logic that actually explains this error message? I assume this would require going to the source of the message. How do we find that?
Intel® RealSense™ is open source, you can find the source code at GitHub. If you check the sources for the exception, you will find the
three lines 327, 388 and 411
the exception gets thrown (class wrong_api_call_sequence_exception : public recoverable_exception).
All of the exceptions are thrown based of an failed allocation like
_actual_source.alloc_frame(...);
where frame_source & _actual_source;. Digging deeper, you will find the definition of frame_source::alloc_frame which returns a nullpointer in our case. This nullpointer is returned by a virtual method alloc_and_track, whichs implementation leads to a failure of publish_frame.
For me it looks like there is a buffer of frames which are able to be published and reused later on if released. Your software (ROS in this case) is simply not releasing the frames fast enought to be reused again.
This should basically answer your question. If required, you now could dig deeper to find out how to parametrize the parameter of intrest uint32_t max_publish_list_size or try to find out why your frames are not released fast enough. The way to do this is exactly the same like done until this point. Just try to step through the code.
Open your launch file, and modify the frame rate parameter. Your default value is 30, you can make it smaller.
<arg name="depth_fps" default="15"/>
<arg name="infra_fps" default="15"/>
<arg name="color_fps" default="15"/>
I am using libsndfile and portaudio to play audio from a .wav file and I am getting some weird undefined reference (in time.h...?) errors upon use of sf_open(const char*, int, SF_INFO*) Before showing the errors, here is some basic info: I'm using MinGW 3.21 (cannot upgrade due to IDE constraints) on Windows 10, with CMake as my build system. I have verified that the const char* passed to sf_open is a valid file name and I have checked that no other lines of code are causing this compilation error. Without further ado, have some lovely errors:
libsndfile/lib/libsndfile.a(aiff.o): In function time':
c:/dwimperl/c/bin/../lib/gcc/i686-w64-mingw32
/4.4.7/../../../../i686-w64-mingw32/include/time.h:242:
undefined reference to _time32'
This is printed several times, probably because the function time is used a lot in sf_open although I haven't a clue as to why. This happens as well:
In function `gmtime':
c:/dwimperl/c/bin/../lib/gcc/i686-w64-
mingw32/4.4.7/../../../../i686-w64-mingw32/include/time.h:240:
undefined reference to `_gmtime32'
These errors imply no correlation between sf_open and time.h, but I even tried the following,
#include<sndfile.h>
int main {
sf_open(nullptr, 0, nullptr);
return 0;
}
and gotten the same result. I have libsndfile-1.dll in the same directory as my compiled binaries, and am linking to both libsndfile.a and libsndfile.dll.a. I have tried only linking to libsndfile.a with the same result. However, I tried linking only to libsndfile.dll.a and the program compiled but then crashed, saying:
An error occured while using the portaudio stream
Error number: -9984
Error message: Incompatible host API specific stream info
I'm not sure whether or not that is something for another question, but I thought I'd mention it, seeing that sf_open, the faulty function, seems to do something with stream info. Anyways, this is as far as I've gotten. Help is appreciated!
Look at me being such a genius, answering the question by asking it and then not noticing. Sometimes I wonder how I'm still alive. Anyways, it was simple. Don't link libsndfile.a, just libsndfile.dll.a. That's all. The PortAudio error was something entirely unrelated. Sorry for the idiocy, hope this helps at least one person...?
I have a dump file which I managed to create, from my DLL which is created for any unhandled exception.
When I did something like int* tt = new int[4]; return int[n]; with n = 4, I would get the dump file, and could open it, and see at what line the error is caused. This was possible for both directly from a release exe, and a release DLL.
Now this was an easy error, and I only entered it to test my memory dump creation.
I now have a 900kb dump file, and the event log says the error comes from my .DLL, yet if I open the file, it does not display any source code.
The call stack is
KERNELBASE.dll!RaiseException() + 0x3d bytes
clr.dll!RaiseTheExceptionInternalOnly() + 0x18f bytes
clr.dll!IL_Throw() + 0xe2 bytes
000007fe81f65fd7()
00000000034d1610()
000000002d06ecb8()
436f93ce00050011()
436f93cf00110012()
000000002d06ec50()
00006d930c4f7680()
clr.dll!InlinedCallFrame::`vftable'()
000000002d06f3d8()
which does not help me at all to figure out where in the DLL my error is coming from.
Another issue with debugging this is, it only happens on a live-PC, but never on my debugging system. Can anyone help me finding a way how to debug this? It seems to happen on the calling of the DLL, but: not every time, only like every 2nd time (sometimes on 1st try, sometimes on 5th). I am completely lost on what is happening here.
Edit:
Updated the call stack with the Microsoft symbols loaded, but I still do not know where this may be coming from.
You need to load the symbols for kernelbase.dll. And possibly clr.dll.
Presumably you are using visual studio?
Set it up to access symbols from the microsoft symbol server: http://msdn.microsoft.com/en-us/library/b8ttk8zy(v=vs.80).aspx
You may need to right click on items in the callstack and tell it to load symbols.
Additionally be sure to keep a copy of the pdb file for any releases of software you make.
I'm calling lt_dlopen and getting a generic file not found error (translated errno text). How can I get more information about what is actually failing, as the file is definitely there.
This is a C++ program loading a C++ library. Otherwhere in the same program I use the same command to open other libraries without a problem, thus I fear it might be something specific to this library. I've used ldd and all those dependencies of the library are met.
I stumbled across something that kind of works:
export LD_DEBUG=all
And then proceed to sift throught the extreme mass of output. In this case I found a "lookup error" and one of the symbols could not be resolved. I'm not sure why, but that is perhaps not relevant to this question.
Recompile libtool with "-DLT_DEBUG_LOADERS" in $CFLAGS. Adjust LD_LIBRARY_PATH so that your program will find this debug libltdl.so instead of the system one. That debug version of ltdl will print explicit errors for each loader's attempt to open the target with much less verbosity than LD_DEBUG=all.
From http://www.delorie.com/gnu/docs/libtool/libtool_46.html :
Function: lt_dlhandle lt_dlopen (const char *filename)
[...] If lt_dlopen fails for any reason, it returns NULL.
Function: const char * lt_dlerror (void)
Return a human readable string describing the most recent error that
occurred from any of libltdl's functions. Return NULL if no errors
have occurred since initialization or since it was last called.
I have search & searched MSDN to find the definition of the HRESULT error with the value 80041318 but I cannot find it.
I am working in C++ Win32 attempting to schedule a task that will execute when the current user logs in. The function RegisterTaskDefinition() fails & returns this value.
Does anyone know what this error means & if possible does anyone know of the MSDN link to ALL the HRESULT ERRORS? I can find one link that has definitions of 7 errors.
The Microsoft Exchange Server Error Code Look-up tool can be used to look up error codes. Don't let the name fool you—it's not just for Exchange, it's useful for program that generates Win32 error codes or HRESULTs. It searches all of the system header files for potential matches.
To look up error code 80041318, just run it from the command line like so:
C:\> err 80041318
In this case, a quick search yields this MSDN page, which says that error 80041318 is SCHED_E_INVALIDVALUE: "The task XML contains a value which is incorrectly formatted or out of range."
Using the error lookup tool that comes with VC++ (errlook.exe, or "Error Lookup" on the Tools menu in the IDE), the error message for 0x80041318 is "The task XML contains a value which is incorrectly formatted or out of range."
In the case of Task Scheduler 1.0, the error codes used are in WinError.h (search for SCHED_E_). I'm not sure if all the error used by TS 2.0 are there or not, though.
It means that you are passing incorrect argument to pLogonTrigger