Error while printing in octave - octave

When i am trying to print variables or even for 'help < topic >' commands, I am getting this error in octave.
octave-3.6.4.exe:66> help minimize
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x60E90000, RegionSize 0x170000, State 0x10000
C:\Software\Octave-3.6.4\bin\less.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0
I am not sure what is causing this error. I removed cygwin from my windows registry. Is that the reason? In any case, how to get rid of this error?

I had the exact same problem. Just uninstall Octave, then reboot, then reinstall it. This did the trick for me.

Related

Fedora 33 openjdk 8 error showing on terminal

I am getting below error whenever I open the terminal. This began happening after upgrading Fedora Workstation 32 to 33.
ERROR: ld.so: object '/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64/jre/lib/amd64/libzip.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
I still have OpenJDK 8 installed and even when uninstalled, above error keeps popping up making my terminal untidy
The answer here helped me to get a solution. I had the below the line in .bash_profile
./home/admin/Adempiere/postgresql/8.1.5/PGSQL.env
. I simply commented it out as below and my issue was solved. Read the above answer for the details of why this caused me issues. In my case, the program "Adempiere" had been uninstalled but it didn't remove this path which no longer existed.
#./home/admin/Adempiere/postgresql/8.1.5/PGSQL.env
If you get any error related to the above, review paths set in your .bash_profile
or /.bashrc , if you have a missing path; definitely this will throw this error

Symbol lookup error on Fedora 22 while trying to run Quartus II

I've been trying to start Quartus II on my system (which is a DELL running Fedora 22 64-bit). Now I try to run the binary file in command line and I get hit with this weird error as follow:
[kuma0629#eecad47 bin]$ ./quartus
quartus: symbol lookup error: /lib/libXext.so.6: undefined symbol: _XGetRequest
Now, I googled this problem and seems like libX11 needs to be upgraded. But I'm not sure how to do this for Fedora in particular because there's not much support online.
How do I go about fixing this problem?

clang++ Error when compiling the Minko engine SDK for HTML 5

I have followed all steps mentioned in Compiling the SDK for HTML5 to compile the Minko framework to HTML5.
When I run the batch file build_html5.bat, i have this error
000000000000000), RtlUserThreadStart() + 0x21 bytes(s)
clang++.exe: error: clang frontend command failed with exit code 255 (use -v to see invocation)
ERROR root: compiler frontend failed to generate LLVM bitcode, halting
mingw32-make1: *** [obj/html5/release/Picking.o] Error 1
mingw32-make: *** [minko-framework] Error 2
Here is my Emscripten conf :
LLVM_ROOT='C:/Program Files/Emscripten/clang/e1.30.0_64bit'
EMSCRIPTEN_NATIVE_OPTIMIZER='C:/Program
Files/Emscripten/clang/e1.30.0_64bit/optimizer.exe'
NODE_JS='C:/Program Files/Emscripten/node/0.12.2_64bit/node.exe'
PYTHON='C:/Program Files/Emscripten/python/2.7.5.3_64bit/python.exe'
EMSCRIPTEN_ROOT='C:/Program Files/Emscripten/emscripten/1.30.0'
MINGW_ROOT='C:/Program Files/Emscripten/mingw/4.6.2_32bit'
JAVA='C:/Program Files/Emscripten/java/7.45_64bit/bin/java.exe'
Im on windows 7 64 bit.
Anyone know what causes this error and how can I resolve it?
This is a known problem with Emscripten 1.30, it should be resolved in future versions. For the moment, stick to Emscripten 1.29.

Error log for Octave "panic: Illegal instruction -- stopping myself"

Is there an error log where I can figure out the error message and line of code in my file which makes the Octave interpreter post the following messages in Emacs?
panic: Illegal instruction -- stopping myself...
panic: attempted clean up apparently failed -- aborting...
Process Inferior Octave aborted (core dumped)
You must use the Octave debugger (take a look at the Debugging section of the Octave manual).
If this was an error message, you could activate debug_on_error. Since it is not, it's a proper crash, you must start on debug mode (enter the keyboard command) and step line by line (enter the command dbstep) until you find which one causes the issue.

MySQL restart causes double free or corruption using MySQL C API

I have a c program that maintains a persistent MySQL connection, version 5.1.46. If I restart mysql while the program is running I get a double free or corruption error as such:
# /etc/init.d/mysql restart
Shutting down MySQL........ [ OK ]
Starting MySQL.*** glibc detected *** /home/user/a.out: double free or corruption (!prev): 0x000000000b64dd00 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3739471634]
I am expecting the connection to automatically reconnect since I have set the MYSQL_OPT_RECONNECT option and have not explicitly closed this connection yet. In addition, the query I am executing is not a char* that I have accidentally set to NULL or deallocated, it is a constant, double quoted string.
Here are a few lines from the resulting core file in gdb
#11 0x000000000044ed71 in mysql_send_query (mysql=0x41966aa0, query=0x41966100 "SELECT count (*) from TableA", length=27) at client.c:2894
#12 0x000000000044edd9 in mysql_real_query (mysql=0x602a, query=0x602d <Address 0x602d out of bounds>, length=6) at client.c:2905
#13 0x000000000042b42f in do_query (conn=0x41966aa0, msg=0x41966100 "SELECT count(*) from TableA") at dosql.cpp:20
Any ideas why this might be occurring?
Any ideas why this might be occurring?
Because of a bug in MySQL.
You can try to update to later package, and see if the problem disappears.
Alternatively, run your client program under Valgrind, and it will report the bug in a way that is usable for fixing it. In particular, it will report
stack trace where the memory was allocated
stack trace where it has been freed
stack trace where double-free is happening (should be same as your GDB stack trace)
Given that info, you could report the bug to MySQL developers, and hope it will eventually be fixed.