I've been using Haxe for a while and I'm debuging with the Windows target (OpenFL).
When I put a try/catch somewhere it just says for example "Null object reference" - it doesn't say the line number and the class, so I have to keep putting traces to find in which line it has thrown the error.
Can someone help me?
You might need to enable stack traces by adding the following define to your project.xml file if you're compiling in release mode:
<haxedef name="HXCPP_STACK_LINE" />
Also, you won't be able to catch null reference exceptions or get stack traces for them unless the following is defined (for performance reasons):
<haxedef name="HXCPP_CHECK_POINTER" />
With these two, you should see a stack trace in FlashDevelop's Output panel.
You can find some good info on these flags and hxcpp debugging in general here. You might also want to check out the crashdumper library.
Related
I got this message when I am to run the debugger on Softconsole. Is there any specific setting I should set to avoid this error message? Thanks in advance.
You should set a breakpoint at the beginning of your program, and step through until you can narrow down what function(s) or data is causing the break.
If you will use the recommended "workspace.examples" or base your workspace on a copy of the "workspace.empty" (depending on the version of SoftConsole this can happen automatically), then you will not see the issue.
I encounter some errors when running a dpdk-based application. I find the error occurs when invoking rte_eth_dev_configure() function provided by dpdk library. The error code is -22. However, I want the application to show more debug information so that I can quickly focus on the error part.
I did RTFM and modified $RTE_SDK/build/.config. I turned RTE_LIBRTE_ETHDEV_DEBUG to be y. But It didn't work. Where does rte_vlog() function put log messages?
Would you like to help me? Any suggestion is appreciated!
You should also change the default log level, otherwise all the debug messages will be compiled out during the compilation, i.e.:
RTE_LOG_LEVEL=RTE_LOG_DEBUG
RTE_LIBRTE_ETHDEV_DEBUG=y
Please also have a look at EXTRA_CFLAGS. You might also want to add the debug symbols and disable optimizations, i.e.:
make EXTRA_CFLAGS="-O0 -g" ...
I add CONFIG_ RTE_LIBRTE_ETHDEV_DEBUG=y to the ${RTE_SDK}/config/defconfig_{RTE_TARGET} config file and rebuild the target. It works.
I'm writing C code and was initially using the gcc checker. Errors were reported in the C file. Lots of errors that didn't matter were being reported due to, for instance, no include directory switches on the gcc command line in the checker. Because we're using icc and it feels unwieldy to setup all of the parameters that are already setup in our makefile, I decided to switch over to using the make checker.
Upon switching to the make checker, I did not get any results. Looking at the makeprg command in make.vim, it is make -sk. I realized that our makefile was not setup to do syntax checking, so I created a new target called syntax_check that added the -fsyntax-only and -c flags. I then changed the make.vim makeprg command to make -sk clean syntax-check so that the appropriate target is run.
When I save the file I watched top in another window and saw that the build is occuring. However, I'm still getting no errors. By this, I mean I don't see the green sidebar indicating lines that did not have errors. Running :Errors does not bring up the location list.
Any ideas? And is my understanding of how to look at the generated errors in syntastic wrong (which it may very well be)?
As a side note for the question here, I've also got this question in on the Syntastic github page here.
It turns out that the errorformat was wrong for handling icc. This, of course, makes total sense.
The errorformat for icc that I've got so far is:
let errorformat = '%W%f(%l): %tarning #%n: %m,%E%f(%l): %trror: %m'
I will add more to this as I find errors that aren't covered by this format or find that I need different formatting.
i found some error on my app and show some regarded information :
(trunk:29564): Gtk-CRITICAL **: IA__gtk_tree_store_clear: assertion `GTK_IS_TREE_STORE (tree_store)' failed
my question is :
what is 29564 ?, is that offset of stack in code segment in the application, or in stack of memory ? or where is it exactly ?
how could i debug it ? on which language it(debugging) would be ( C or asm ) ?
Use gdb.
This errors in gtk+ application.
You must pass function parameters not foo(tree_store, ... ) you must as foo(GTK_IS_TREE_STORE(tree_store), ...)
As Ancide said we need more information. The completely blind, but sometimes effective, approach is to try grep -r on your source tree for various strings in the error message. Probably you are looking for a function called IA__gtk_tree_store_clear, but then you need to find out who is calling it with something that's not a tree store...
If you actually want to debug the exectuable, figure out how to enable debug info in the build (get a -g flag passed to gcc for example) and then run use gdb progname arguments to launch the program. When it fails, use things like the back trace command (ct) to look at the call stack and figure out the chain of events that lead up to the failure.
EDIT: looks like you'll need to put a breakpoint in to keep the program from actually aborting, otherwise you won't have a call stack to examine. So you'll need to find the line of code on which the assert is checked. You can use a conditional expression in the breakpoint to make gdb only stop the program when the assertion would fail.
I'm attempting to build Firefox on my Windows Vista Ultimate machine. I keep getting the following error:
nsinstall: Bad file number
I've read that this error is caused because of UAC in Vista. Here are the two articles that lead me to this conclusion. https://wiki.mozilla.org/Penelope_Developer_Page#Windows_Vista and http://www.kevinbrosnan.net/mozilla-build-error-nsinstall-bad-file-number
Using the standard "Run as Administrator", I've attempted to redo my build but I get the exact same error. I also started a normal command prompt as admin and then went to the batch file in mozilla-build (start-msvc8.bat) and ran it. Still, same error at the same point.
Any other insights on how I might either get around this error or perhaps something else is causing the error?
Note: I also posted something here in the hopes to get topic-specific help but I've not heard a peep... After I posted that I found the info on nsinstall. Anyway, I prefer SO so I thought I'd try here...
Update: I've attempted to completly disable UAC to correct the problem as is suggested by cnemelkasr. I've received the exact same error. This new knowledge is making me think that a file or folder is missing... Does anyone who has experience with NSInstall know what the given error -- Bad file number -- might mean? I figure it might be referring to a file handle...
If it really is a UAC error, you can try turning off UAC altogether. I've had to do this for several packages. There are numerous places on the web to get the instructions for doing that.
http://www.petri.co.il/disable_uac_in_windows_vista.htm is one of them.
I found the answer to my question. I'm posting the answer here to share the answer with others and to close this question.
After disabling the UAC, it was suggested that the directory depth was interfering with NSInstall. I moved the folder from c:/Users/Frank/Documents/hg-repos/firefox-src-hgRepo/mozilla-fv-expirement/ to C:/mozilla-fv-expirement/. Cleaned all previous build attempts and finally redid my build (with UAC off) and I received a working debug binary.
The suggestion was posted at: mozilla.dev.builds
The "Bad file number" message in the cases I have seen, is caused by too many arguments passed to execvp (command, argv) (or similar) function. But only from some programs. An old bash, sh or a Borland/Watcom program in your PATH is an likely candidate.
So when you shorten the name of the build directory, the total size of the command line (that eventually gets passed to CreateProcess()) gets shorter. I don't think UAC has anything to do with this since I've seen this on Win-XP too. But it's a bit strange Mozilla would not use relative paths while building. I guess it uses some directory prefix value in it's makefiles (I've never tried building it).
If you look at the documentation for _execvp():
http://msdn.microsoft.com/en-us/library/3xw6zy53.aspx
E2BIG is one of the possible errno values:
The space required for the arguments and environment settings exceeds 32 KB.
Now, here is the strange part.
Fact 1:
On Visual-C/MingW (any version), strerror(EBADF) doesn't return "Bad file number" .
(it return "Bad file descriptor").
Fact 2:
On Borland's CBuilder 5.6 and Watcom 1.9 (these do not use the MSVC runtime), strerror(EBADF) does indeed return "Bad file number".
Theory:
Is possible that Borland, Watcom (and other CRTs too?) mixes up the meaning of E2BIG and EBADF. Did that make any sense? Someone please correct me if you have a better theory.
I'm a bit confused myself...
Conclusion: Either shorten the size of your environment (easiest) or shorten the command-line (not always easy).
--gv