I am developing one application for my client with IBM Streams v4.2
While compiling, I am getting the following error:
/opt/ibm/InfoSphere_Streams/4.2.0.0/system/impl/bin/spl-code-gen-driver:
CDISP0139E ERROR: The execution of the code generator failed. The
error is: fork() failed.
Can anyone help as to where can I look for the actual error?
fork() failing generally means the system is overloaded and out of resources. Try terminating processes that you don't need, and if that doesn't work could you try increasig the memory for the VM and then or restarting the OS?
My problem is resolved now. fork() is due to too many processes running.Since I could not make out which process to kill, I restarted the system and immediately compiled the code after it was started.My code was compiled successfully.
For a permanent solution, I reduced the number of parallel threads/chain in the code so that the system does not run out of resources.It worked !!!
Related
Sometimes when I compile C++ code using nmake, the build process gets stuck at the manifest tool mt.exe (see the bottom of this screenshot - http://i.stack.imgur.com/pgyzT.png). It just never finishes, but if I cancel the build process and start again, it may run past the last point but get stuck again at another seemingly random mt.exe process. This makes building big software very cumbersome, as I need to "monitor" the build process to know when to cancel and start again from the beginning.
I'm clueless as to what could be the reason to this behavior. Has anybody encountered this problem before?
Edit: I'm using Windows 8 x64, the mt.exe comes from Windows SDK 6.0A.
I had similar problems with msbuild getting stuck at random points. Never found out what caused it, but a workaround that worked for me was to disable parallel building of projects.
Trying disabling your anti-virus on-demand scanning when building. I have seen some anti-virus software block access to a file using mt.exe, though usually you get an error instead of a hang.
I have created a program which runs 2 threads synchronized using events (SetEvent(), WaitForSingleObject(), WaitForMultipleObjects()) in Visual Studio 2010. The following happens:
when I run this program using the debugger it runs for a certain time and then crashes
when I run this program without debugging (.exe file) it crashes directly
when I run this program in another computer using the debugger it crashes immediately and via .exe file it crashes after some time
The following error has been reported when debugging:
Unhandled exception at 0x5eafcaf7 (msvcr100d.dll) in test.exe: 0xC0000005: Access violation reading location 0x0036f000.
Could somebody bring some light to this topic as I don't know where to start searching? Which is the difference between running the code in the debugger or without? (Which kind of code is added?) Why do the different computers have different behaviours when running the same code?
In both computers there is exactly the same operating system (Windows 7) and I assume the same libraries and patches.
Thank you for your help!
EDIT 11.12.2012
I have installed Application Verifier and get in Visual Studio some errors displayed as this:
===========================================================
VERIFIER STOP 0000000000000013: pid 0x1E18: first chance access violation for
current stack trace
000000000874F000 : Invalid address being accessed
000000005201CAF7 : Code performing invalid access
000000000009E440 : Exception record. Use .exr to display it.
000000000009DF50 : Context record. Use .cxr to display it.
===========================================================
Does somebody know how I can see which address belongs to which line of code to know exactly where the exception occurs? I have also read in the Help of the program that using the command "!heap p -a ACCESS_ADDRESS" should give details about the nature of the error and what heap block is overrun. Where should I place this command using Visual Studio?
When working in a multi-threaded environment, things can happen at different speeds on different threads. Trying to identify the possible cause without the relevant code is quite difficult.
The error is a general memory access violation error. This usually occurs when a variable being returned from a function is bigger than expected, or different type.
Can we see the code please?
I am running in a very odd problem and I understand that it may be hard to diagnose from afar. But any hints would be helpful.
Having said this, here's my problem:
When I run valgrind to execute my program, an exception is thrown. However, when I call the program directly from the shell, it runs fine.
I have tried to use valgrind's vgdb to look into why this exception occurs. But this only allows me to investigate the variables after the exception occurred since I haven't found a good way to start gdb after I attached it to valgrind (without using continue) and step through the code.
I have already tried to recreate just the code segment where the exception is thrown but using the same variable content, I do not trigger the exception.
I should add that I'm doing this on a VMWare Workstation 8.0.1 virtual machine with with Ubuntu 11.10 and gcc 4.6.1, valgrind 3.7.0, gdb 7.3.
Any help is appreciated!
Just a few ideas:
a missing command line-parameter when you invoke your program via valgrind - maybe there's a special way to pass such parameter to your program
a different runtime behaviour of your program when it's executed in valgrind. valgrind is a kind of debugger, so maybe threads are scheduled in a different order and parts of your code might run slower. Maybe that triggers a bug like a race condition.
Is it possible to post some of the code here - especially around the location that exception is raised?
There is unix-socket server written on PHP (but I don't think it has something to with it). Client side is written on c++ and based on boost::asio library. When I launch program normally - everything works fine, except one (not related to socket communication) bug that I obviously want to debug. But when I start step-by-step debugging it I immediately receive 'Broken Pipe' error on the steps which perform write operations on sockets. If breakpoint is set up after socket write operation - everything work fine until the next attempt to step over the write func.
Spent whole day trying to solve this problem, but unsuccessfully...
Had anyone met the same trouble?
using GDB bundled with xCode 3.2.5 (64-bit) under OS X 10.6.7
GDB uses signals aggressively. If you want to install signal handlers, check out the following example:
https://github.com/sean-/Boost.Examples/blob/master/asio/timer/timer.cc#L106
I'm debugging plugins on Windows 7 and of course the plugin host (Cubase5.exe) occasionally crashes because of errors in the plugin. On XP or Vista, I could always restart it immediately and continue working. But on Windows 7, even though Cubase appears to close, it is still visible in Task Manager and I cannot kill it by any means. After a minute or two, it disappears by itself. In the mean time, I can't work because the plugin DLL is still locked by the process.
Does anyone know why this happens on Windows 7? I've already tried disabling Automatic Error Reporting but that didn't help. I've tried attaching cdb to Cubase, but I get:
Cannot debug pid 5252, NTSTATUS 0xC0000001
"{Operation Failed} The requested operation was unsuccessful."
Debuggee initialization failed, NTSTATUS 0xC0000001
"{Operation Failed} The requested operation was unsuccessful."
I tried following the instructions here but it appears this is only possible if I connect a second machine to my computer to debug it remotely.
I finally found the solution, using this article:
http://blogs.technet.com/b/markrussinovich/archive/2005/08/17/unkillable-processes.aspx
This required installing the Windows Debugging Tools for Windows (nice name) and LiveKd, but by following the steps outlined I was able to track which driver was causing the process to hang: it turned out to be the 64-bit driver for the M-Audio Oxygen 8 V2 controller I'm using. Unfortunately no driver update is available.
Anyway, if anyone encounters a similar problem, this is the way to solve it.
Have you tried Process Explorer by Mark Russinovich? It is really useful for "killing":)
If you have error reporting enabled, it's possible that werfault.exe has Cubase open to write a minidump for crash reporting purposes.
This is just a stab in the dark but it might be your problem.
One thing you can try is to check with Process Monitor what Cubase is doing. Set a filter so that everything with a process name containing "cubase" will be recorded. It could be that you are facing some timeout issue when Cubase wants to exit.
you can end the process the service is running under. You can find this process by going to the Services tab of the Task Manager, right-clicking, and selecting Go To Process(you need to click the Show processes from all users button.). Note that one process may host multiple services (especially if it's svchost.exe), and ending the process will kill all those services. Also, this is an unclean exit, and may cause data corruption depending on what the service(s) was doing when you killed it.
Depending on which specific service you are trying to stop, there may be a cleaner way to simulate failure.