I just solved a problem which took me way too much time so I thought I share the solution here in case anyone else is biting bricks because of this.
what happened?
I run Pentaho Data Integration 5.2 on CentOS 6.6.
It worked like a charme until I ran yum update the last time.
Now when I was using the graphical interface spoon crashes immediately when I would open an element (e.g. table input) and try to select the query text.
Sometimes it leaves a crash message sometimes not.
Here is the error message:
java: cairo-misc.c:380: _cairo_operator_bounded_by_source: Assertion `NOT_REACHED' failed.
./spoon.sh: line 206: 8922 Aborted (core dumped) "$_PENTAHO_JAVA" $OPT -jar "$STARTUP" -lib $LIBPATH "${1+$#}"
A colleague of mine remembered a quite similar problem he had with his Eclipse and found the solution for me which was to add the following line into spoon.sh into OPT variable:
-Dorg.eclipse.swt.internal.gtk.cairoGraphics=false
It now looks like:
OPT="$OPT $PENTAHO_DI_JAVA_OPTIONS -Djava.library.path=$LIBPATH -DKETTLE_HOME=$KETTLE_HOME -DKETTLE_REPOSITORY=$KETTLE_REPOSITORY -DKETTLE_USER=$KETTLE_USER -DKETTLE_PASSWORD=$KETTLE_PASSWORD -DKETTLE_PLUGIN_PACKAGES=$KETTLE_PLUGIN_PACKAGES -DKETTLE_LOG_SIZE_LIMIT=$KETTLE_LOG_SIZE_LIMIT -DKETTLE_JNDI_ROOT=$KETTLE_JNDI_ROOT -Dorg.eclipse.swt.internal.gtk.cairoGraphics=false"
Now it works again.
Apparently the problem was with the cairo graphics package.
I really love it when stuff doesn't work anymore after updating..
Related
I am running opencv 3.0's sample code hog.cpp (from the folder \samples\gpu\hog.cpp) for people detection, using the GPU. (the CPU part crashes for me). The code compiles, but when I run it, it crashes at the line:
gpu_hog->detectMultiScale(gpu_img, found);
Unhandled exception at 0x000007FEDE717A28 (opencv_core300.dll) in
Hog3StandAlone.exe: 0xC0000005: Access violation reading location
0x000002380000013C.
I am using visual studio 2012, Windows 7 Pro 64 bit.
There are quite a few things that can cause such a problem.
The code itself seems "fine".
What I suggest is that you compile the program in Debug mode. Then, run it from Visual Studio. The IDE's debug session should stop at the exact place in which the "access violation" happened. From there, you can have a more precise idea on the origin of the problem.
For example, I got similar problem at line #341
vc >> frame;
because the VideoCapture vc object returned corrupted frames.
Your problem might be similar (or completely different. That's why you should run a debug session in Visual Studio)
I've tried the same sample before and worked without any problems as far as I remember. On the other hand, this access violation is probably due to the fact that your input "gpu_img" is empty or corrupted. Make it sure that you read the frames correctly (you can use imshow function to visually examine) and also you upload it into gpu_img as well. I don't see any other possible explanation.
I rename a VB.NET 2010 project and the IDE crash over and over.
I open another project and same result, after a few seconds or if I open Form1.vb the IDE crash.
And the worst part is there's no info about on the Error window.
The only that I can see as an error code is 0xC0000005
Is the only program crashing on my PC so I have my doubts about a hardware issue.
How can I figure out what is happening?
Can somebody give any clue?
Thanks.
First off, take a look at this question where the answer does a good job of explaining the OXC0000005 error, and all that it encompasses.
Second, look at what has changed on your system since the last time you were able to successfully run Visual Studio. I have seen a few cases where a bad windows update was the cause of a user receiving this error. If you have installed updates since the last time you were able to run VS without error, you may want to uninstall those updates and try VS again. If VS works, begin to re-install the updates 1-by-1, testing VS between every update, to determine which update caused the issue.
I've come across the below error. This error persists even if I try to use my code on another machine with same version of Xcode 4.2 final. Can any one help?
Console Output
error while killing target (killing anyway): warning: error on line 2184 of "/SourceCache/gdb/gdb-1708/src/gdb/macosx/macosx-nat-inferior.c" in
function "void macosx_kill_inferior_safe()":
(os/kern) failure (0x5x) quit
The debugger is crashing. Crashing debuggers are a world of pain.
Looks like you are using gdb. Try moving to lldb and see if that works around it.
If that doesn't, try nuking your derived data directory as it may be that you have a corrupt symbol that is causing the debugger to crash.
I have no idea what the error is, but googling for the file produces macosx-nat-inferior.c which describes itself as being a part of GDB. So assuming it is the same file as on your computer, then diving in to it may help solve your issue. However that message appears on line 1981 of the file I found .. so I doubt it is the same one as on your computer. But issues with GDB sound weird.
Welcome to Spring Roo. For assistance press CTRL+SPACE or type "hint" then hit ENTER.
roo> Lexical error at line 21, column 39. Encountered: "\u2013" (8211), after : ""
How to restore the index?
now, when I upgrade to Roo 1.2.1 the error message is gone but I get roo> null with the same effect: no *.aj sources are generated and woven.
The code is fine, I've checked it out on two other different machines where all .aj were generated, no error message.
Hypothesis 1: it has to do with windos/ linux character interpetation. On Linux it worked, under Windows error
Solved the mystery.
In one of the tests I declare a german constant with 'umlaute': รถ is the culprit not en-dash.
So the parser for aspect generation reads this and can't cope with it. It's a bug IMHO, especially I hate the fact that the exception can't tell which sequence of characters is surounding the culprit. That would really kill debugging time.
Interestingly on Linux no problems.
I'm getting a "Compilation exited with code 134" when attempting to use the "LLVM Optimizing Compiler" switch for release iPhone builds, using MonoTouch 4.0.1.
I don't get much information from build output window at all - just:
"Compilation exited with code 134, command:"
MONO_PATH=(snip)/bin/iPhone/Release/LSiOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --llvm --aot=mtriple=armv7-darwin,nimt-trampolines=2048,full,static,asmonly,nodebug,llvm-path=/Developer/MonoTouch/LLVM/bin/,outfile=/var/folders/03/033pAAGuHgGkIy4CorbVV++++TI/-Tmp-/tmp38107451.tmp/Newtonsoft.Json.MonoTouch.dll.7.s "(snip)/bin/iPhone/Release/LSiOS.app/Newtonsoft.Json.MonoTouch.dll"
Mono Ahead of Time compiler - compiling assembly (snip)/mscorlib.dll
What is odd is that in earlier command lines, there is a correlation between the DLL mentioned in the arm-darwin-mono command line and what is the compiling, but in this case it says "mscorlib.dll".
Any thoughts?
I have found a few cases (googling and from bugzilla.xamarin.com) where the error code 134 is related to Mono.Linker being too aggressive (removing something that's needed).
This is easy to confirm by turning off the linker, i.e. "Don't link" in Linker Options. If the build works then you can try isolating the assembly where the linker makes a mistake.
E.g. add a "--linkskip=mscorlib" to the mtouch extra parameters and re-enable linking. This will link everything (Link All) or all SDK (Link SDK assemblies) except the assembly you selected (mscorlib in the example). That's only a workaround and a bug report should be filled so the issue can be fixed properly (and get you all the linker advantages).
However be warned that there are other issues sharing the same error code, like:
http://ios.xamarin.com/Documentation/Troubleshoot#Error_134.3a_mtouch_failed_with_the_following_message.3a
YMMV
mtouch does its native builds in parallel so the logs can be confusing, e.g. you can see a bit of assembly X output followed by some assembly Y output.
Reading the full log might help you (or us) to pinpoint the issue.
I was having the exact same problem Scolestock. My app would build fine until I enabled llvm, then it was "Compilation exited with code 134, command" when trying to build the 7s for the app itself.
I'm elated to say that after 2 days of painstakingly whittling my app down to the core problem, I was able to isolate the issue to the usage of embedded dictionaries such as:
Dictionary<enum, Dictionary<enum, value>>
I was able to fix this by defining a class for the embedded dictionary and using that instead:
public class MyDefinition : Dictionary<enum, value>
{
}
...
public Dictionary<enum, MyDefinition>
Not sure if this will help you, but hopefully it'll help some poor soul who decides to use embedded dictionaries and runs into my same problem.