I have a testing utility that uses linux aio_write and aio_read.
This testing utility wraps my static library and test it. This library is multi-threaded black box.
Up until now, it worked fine. But now we made a big change into the this black-box which causes the testing utility to fail as soon as it commits the first IO.
This IO returns with errno 22 == EINVAL.
Based on the aio_write man pages, this error is issued in case one of the following fields is invalid --> aio_offset, aio_reqprio, aio_nbytes.
I run it inside gdb and tested their values as long as with all other values inside the struct aiocb * input parameter.
My conclusion is that the input parameters are all valid.
I suspect something has changed in the way threads are working inside the black-box. This is what i suspect causing this issue (i can not find any other explanation).
What I really try to understand is: Which scenarios causes aio_write() to return a EINVAL error code???
Just to clarify, when I replace the black-box to an older version, using the same testing utility it works fine.... (i also tested the input arguments here as saw they are matching to the bad version input arguments).
You can take a look at the aio implementation in the linux source code at the folder linux-kernel-source/fs/aio.c
Sadly there are a lot of points where -EINVAL is returned. As #myaut mentioned in his comment, I recommend you to use strace. Another solution would be to modify the code, compile it and check where it fails.
Related
I'm using Rcpp to run C++ code using RGui (version 3.4.1) as a user interface. Quite often I make changes to the C++ code which compile correctly but cause errors (e.g. searching beyond the end of an array) when I run the relevant program in RGui, causing RGui to crash. This is aggravating because I have to re-open RGui, re-open my R script (sometimes with unsaved changes lost), set the working directory again, etc. before I can re-compile the C++ code and run the program in such a way as to find the problem or test amendments. Sometimes it promptly crashes again because I haven't fixed or bypassed the problem.
Is there some way to change the way Rcpp runs such that RGui returns an error message instead of crashing in these sorts of situations?
Briefly:
It is spelled Rcpp. Capital R, lowercase cpp.
Yes, don't have bugs :)
In general, 2. is the only viable answer. If you need a managed language, use R.
If the code takes your environment down, test outside the environment. Seriously. That is for example why I (co-)wrote littler and test "raw code" on the command-line: it can only take the command-line app down.
We do have a feature in eg RcppArmadillo to test for "out of bounds" vector access: use x.at(i,j) which will warn. See http://arma.sourceforge.net/docs.html#element_access
I don't actually know of a way to prevent this apart from more careful programming, and saving before execution. But having done this a few times I have discovered a way to get back at unsaved changes, (at least in windows).
When you get the pop-up that tells you to restart R, you don't do it. You open up task manager and right-click on the process and select 'Create Dump File'. Find this file in explorer and open it with some text editor.
They are very big, and full of all sorts of stuff, but if you use find function to search for some string you know to be in your script, then you can find all the unsaved work. You can then copy and paste this into another file to save.
If you use R-studio instead of R-GUI, it usually manages to look after your unsaved work better.
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.
Question Intro
I'm running an opencv project in Visual Studios 2010 and have implemented cuda support (refer to my previous question for precise info on my set-up). All cuda-functionalities are working fine - to the best of my knowledge - and are indeed improving speed on the image processing.
However, I now also wanted to attemp to speed up the video-writing function in this project by replacing the current cv::VideoWriter with the gpu::VideoWriter_GPU function. The reason for this is that the cv::VideoWriter seems to somehow cause processes running outside of the scope in which the VideoWriter is called to be slowed down, resulting in images available at the DirectShow driver being dropped by the VideoCapture-function, hence messing up an algorithm I've implemented.
Problem
To attempt to solve this issue, I've now replaced the VideoWriter-calls with VideoWriter_GPU-functionality (and corresponding syntax), but when I run my project (Compile & Run in Debug-mode), I get the following error-message (directly originating atthe calling of gpu::VideoWriter_GPU):
OpenCv Error: The function/feature is not implemented (The called functionality
is disabled for current build or platform) in unknown function, file
c:slave\builds\wininstallermegapack\opencv\modules\gpu\src\precomp.hpp, line 131.
and the program then ends with
code -529697949 (0xe06d7363)
I've purposely currently not included any of my code because the error-message originates so clearly from the call to the gpu::VideoWriter_GPU, which is making me think it's not a coding or syntax problem. (Please comment if you feel my code is necessary for answering this question.
My steps so far
I miss the natural gift of understanding what precisely this message means or how to interpret it. Does my opencv v2.4.4 simply not support what I want...? Does this function simply not work on my windows 7, 64bit system...?
I've checked out as many available google-hits I could find (relating to this error message and combinations of searchterms like "opencv, gpu, VideoWriter_GPU, disabled for current build") but have not understood what the problem is or how to solve it.
Corresponding header-file and error message can also be found here.
This post and this post suggest the error message is trying to tell me that opencv simply does not provide the option of using the function or functionality I am aiming to use. Or maybe even that cuda is not at all supported.. But that's all against my experience as every single opencv gpu-function I've tried to use has seemed to work fine.
Question
Could someone please explain to me why this is not working for me, and more importantly share with me what I should do to make the VideoWriter_GPU work?
Many thanks!
Maybe this link can give you a little idea of what the problem is: VideoReader_GPU not available, but built with NVCUVID?.
It seems to be that the problem is the CUDA_DISABLER var.
I know that in a DOS/Windows application, you can issue system commands from code using lines like:
system("pause");
or
system("myProgram.exe");
...from stdlib.h. Is there a similar Linux command, and if so which header file would I find it in?
Also, is this considered bad programming practice? I am considering trying to get a list of loaded kernal modules using the lsmod command. Is that a good idea or bad idea? I found some websites that seemed to view system calls (at least system("pause");) in a negative light.
system is a bad idea for several reasons:
Your program is suspended until the command finishes.
It runs the command through a shell, which means you have to worry about making sure the string you pass is safe for the shell to evaluate.
If you try to run a backgrounded command with &, it ends up being a grandchild process and gets orphaned and taken in by the init process (pid 1), and you have no way of checking its status after that.
There's no way to read the command's output back into your program.
For the first and final issues, popen is one solution, but it doesn't address the other issues. You should really use fork and exec (or posix_spawn) yourself for running any external command/program.
Not surprisingly, the command is still
system("whatever");
and the header is still stdlib.h. That header file's name means "standard library", which means it's on every standard platform that supports C.
And yes, calling system() is often a bad idea. There are usually more programmatic ways of doing things.
If you want to see how lsmod works, you can always look-up its source code and see what the major system calls are that it makes. Then use those calls yourself.
A quick Google search turns up this link, which indicates that lsmod is reading the contents of /proc/modules.
Well, lsmod does it by parsing the /proc/modules file. That would be my preferred method.
I think what you are looking for are fork and exec.
I am trying to develop an IThumbnailProvider for use in Windows 7. Since this particular thumbnail would also be dependant on some other files in the same directory, I need to use something other than IInitializeWithStream to a path to work with, this being IInitializeWithItem. (Alternatively, I could use IInitializeWithFile, but that is even more frowned upon apparently.)
No matter what I do, I cannot get it to work. I have Microsoft's FileTypeVerifier.exe tool which gives the green light on using IInitializeWithItem, but when explorer calls it, it only seems to try IInitializeWithStream, ever. (This was tested by temporarily implementing said interface, and Beep()ing away in its Initialize()) Did I forget to configure something?
In short: how do I get this to work?
Okay, I finally found out what is the matter. To quote the Building Thumbnail Providers link on the MSDN website:
There are cases where initialization with streams is not possible. In scenarios where your thumbnail provider does not implement IInitializeWithStream, it must opt out of running in the isolated process where the system indexer places it by default when there is a change to the stream. To opt out of the process isolation feature, set the following registry value.
HKEY_CLASSES_ROOT
CLSID
{66742402-F9B9-11D1-A202-0000F81FEDEE}
DisableProcessIsolation = 1
I knew I was running out of process since I read elsewhere that thumbnailproviders ALWAYS ran out of process. But since that particular snippet is on almost -all- shell extension handlers, I interpreted it to be a overly happy copy-paste job, since it was -required- to run in-process the way I understood it.
And I was wrong. I hope this will help someone else in the near future. :)