I'm currently changing Simulink Ext Mode to xcp. Now i'm running into the Issue DWARF Parser internal error: Parser::describeSymbol xcpDummyDoubleVariable is not a global variable. According to this post, the issue should have been fixed but it still doesn't work.
https://de.mathworks.com/matlabcentral/answers/703597-dwarf-parser-internal-error-parser-describesymbol-xcpdummydoublevariable-is-not-a-global-variable
I also tried the first approach (the second one is already active in version 22b) but the Error still occurs.
Have u got any suggestions why the error still occurs?
Related
I am working on a model in Dymola and use the Dymola S-block in Simulink to compile the model and then run the model in Simulink. After a few compilations, the interface stops working with the error in the Matlab workspace as
Error using ddereq
The first argument 'channel' is not valid.
Error in newDymolaGuiJava
Error in newDymolaGuiJava
Error in newDymolaGui Error while evaluating UIControl Callback.
I have to restart Matlab every time I encounter this to make it work. And it happens very frequently. I'm not sure what the problem is.
Using mosek in cvxpy, I'm getting the error that the solver failed. Is there a way to recover the error code from Mosek? Cvxpy doesn't seem to provide it.
Cvxpy ignores it. However, you can hack it by changing the line in mosek_coinf.py that does task.optimize and retrieving the response code according to https://docs.mosek.com/8.1/pythonapi/optimizer-task.html#mosek.task.optimize
Moreover, if you enable logging (verbose=True) then you should see from the solver log what happened.
I have a wxWidgets/GTK based application that works well - except for one installation on an Debian Squeeze ARM system. There it crashes when the user just activates the main window of it. To find the reason for that I added a signal handler to the application and use libunwind out of that signal handler to find the source for the crash. During a test that worked fine, when the software writes e.g. to address 0x0 libunwind correctly points me to the function where that happens.
But the results for the system where the crash appears unexpectedly are a bit strange, they seem to happen outside of my application. One crash comes from a function with no name (here libunwind returns an empty string), and one is caused by "malloc_usable_size", a system function which should never die this way.
So...what to do next? All ideas, suggestions or any other hints are welcome since I'm not sure how to contunue with that problem...
Check for buffer overrun or overwriting some memory unexpectedly for any structures, pointers, memory locations for items returned by library functions.
Check for invalid pointer frees in your code for the library allocated pointers that you are using.
May be using valgrind would also help.
I have created a standalone application in Matlab, actually it works, it displays the desired output but it closes immediately, not even enough time to examine the output and read the error message on DOS (standalone mode) that says:
MATLAB:TooManyOutputs
Warning: 1 visible figure(s) exist at MCR Termination
If your application has terminated unexpectedly, please note that
applications generated by the MATLAB Compiler terminate when there are no
visible figure windows. See the documentation for WaitForFiguresToDie and
WAITFORCALLBACKS for more information.
Any help would be appreciated.
Looking at the first line of your message, TooManyOutputs suggests that you have an assignment somewhere of the form
[a b] = somefunction(parameters)
so you want the outputs of somefunction to be put in a and b, but somefunction only returns one parameter. This bug causes your program to terminate, and then MCR realizes the program exits without closing your figure window, causing the later error messages.
If I'm right about TooManyOutputs, you should already have that error message when running your code directly in Matlab; have you tried that before creating a standalone application?
If this doesn't help, you should probably post some of your code to make it clearer where the problem could come from.
I have a matlab script, that every now and them produces the message:
Caught std::exception Exception message is:
bad allocation
Unexpected error status flag encountered. Resetting to proper state.
What could be causing this?
This is a bug in MATLAB, in which some part of MATLAB is not handling a std::bad_alloc exception correctly (std::bad_alloc is an out-of-memory exception thrown from the C++ runtime library).
The "Unexpected error status flag encountered. Resetting to proper state." is an internal diagnostic - you shouldn't see it unless MATLAB has gotten into a bad state, which in this case is happening because it's encountering the bad_alloc someplace where it was not expected. Recent versions of MATLAB have fixed most of these issues, except in extremely low-memory situations (like, there's less than 1 kilobyte of free memory left). What version are you using?
My best guess is that your script is trying to allocate some memory and failing. The occurrence of such an error will depend on the availability of memory on your computer at the time allocation is attempted. The available memory will vary according to what is going on at the time in other programs, the operating system, even the state of your Matlab session.
For a more accurate diagnosis, you'll have to tell us more, maybe even post your script.
It was happening to me, and it turned out I had too many files open. fclose('all') set everything back to normal, and I made sure that all my fopen were followed by fclose.