Ubuntu 12.04, Mono 2.10.8.1-5
I have built the "hello world" console app that MonoDevelop creates as a default. It runs as expected. When I add the trace option (directed into a file, or not), I get stuff like this:
[0x7f24da6eb740: 0.00000 0] ENTER: (wrapper runtime-invoke) <Module>:runtime_invoke_void__this___object (object,intptr,intptr,intptr)([System.OutOfMemoryException:0x7f24da52af60], 0x7fff953e6510, (nil), 0x40e79a70, )
[0x7f24da6eb740: 0.00012 1] ENTER: System.OutOfMemoryException:.ctor (string)(this:0x7f24da52af60[System.OutOfMemoryException monotracetest.exe], [STRING:0x7f24da551e70:Out of memory], )
[0x7f24da6eb740: 0.00021 2] ENTER: System.SystemException:.ctor (string)(this:0x7f24da52af60[System.OutOfMemoryException monotracetest.exe], [STRING:0x7f24da551e70:Out of memory], )
[0x7f24da6eb740: 0.00030 3] ENTER: System.Exception:.ctor (string)(this:0x7f24da52af60[System.OutOfMemoryException monotracetest.exe], [STRING:0x7f24da551e70:Out of memory], )
[0x7f24da6eb740: 0.00031 3] LEAVE: System.Exception:.ctor (string)
..going on for nearly 900 lines about stack overflows, out of memory, and more innocent looking things.
I've not found any documentation on the trace option beyond '--help-trace'. What should I be expecting? Is this actually reporting problems? When I wrap the 'console.writeline("hello world")' in a try catch block, no exception is thrown. (Of course, presumably an unhandled exception would have crashed the program.)
My original program was to test calling a library of native code, and I reduced it to this to see where it failed.
How do I separate the wheat from the chaff?
That is the expected output: there is no exception thrown, but the runtime needs to build some objects at startup (for example the OutOfMemory exception object: when the condition happens there may be no memory anymore to allocate it!).
As for reducing the output, what is not clear in --help-trace?
For example, if you want to get traces only of classes and methods in the System.IO namespace, you will issue:
mono --trace=N:System.IO program.exe
Related
I'm trying to debug a program in WinDbg. However, WinDbg won't run it after I launch it; after loading the binary, when I attempt to continue the program I get this error:
0:002> g
^ No runnable debuggees error in 'g'
Some relevant facts:
I'm using Windows 10.
The program in question is written in C and was built with MinGW.
The program is loaded, as I see it in the Task Manager. It just won't go beyond ntdll!NtWaitForWorkViaWorkerFactory.
There is no error in the program at this point; I'm just trying to get the thing running before I move on to my real problem (which is beyond the scope of this post).
I can attach to a running instance of this program just fine, I just can't launch new ones.
I can launch notepad.exe with WinDbg just fine.
i'm using 2 functions simultaneously, one that takes input with getChar and other that draws some characters con the terminal, however, i'm using ansi-terminal to move the cursor on the screen
the problem is that when i compile throws the next error
user error (pattern match failure in do expression at libraries\Win32\System\Win32\Types.hsc
this only happens when i set "+RTS --io-manager=native" flag, but that is necesary 'cause getChar doesn's work properly without it
This has been fixed in version 2.12.0.1 of Win32. See this issue.
If you're using cabal I think you can make a cabal.project file with these contents:
packages: .
constraints: Win32 >= 2.12.0.1
Or if you use stack I believe you can add Win32-2.12.0.1 to your extra-deps in your stack.yaml.
How do I build a standalone executable in SBCL? I've tried
; SLIME 2.20
CL-USER> (defun hullo ()
(format t "hullo"))
HULLO
CL-USER> (sb-ext:save-lisp-and-die "hullo" :toplevel #'hullo :executable t)
but that just produces the following error.
Cannot save core with multiple threads running.
Interactive thread (of current session):
#<THREAD "main thread" RUNNING {10019563F3}>
Other threads:
#<THREAD "Swank Sentinel" RUNNING {100329E073}>,
#<THREAD "control-thread" RUNNING {1003423A13}>,
#<THREAD "reader-thread" RUNNING {1003428043}>,
#<THREAD "swank-indentation-cache-thread" RUNNING
{1003428153}>,
#<THREAD "auto-flush-thread" RUNNING {1004047DA3}>,
#<THREAD "repl-thread" RUNNING {1004047FA3}>
[Condition of type SB-IMPL::SAVE-WITH-MULTIPLE-THREADS-ERROR]
What am I doing wrong?
What you are doing wrong is trying to save an image while multiple threads are running. Unlike many errors in Lisp the error message explains exactly what the problem is.
If you look up the function in the sbcl manual here then you find that indeed one may not save an image with multiple threads running. The extra threads come from swank (the CL half of SLIME). The manual says that you may add functions to *save-hooks* which destroy excess threads and functions to *init-hooks* to restore threads.
One way around all this is to not save the image when it is running through slime but instead to start sbcl directly at a terminal (note: no readline support), load your program and save from there.
Working with slime is different. In theory there is a SWANK-BACKEND:SAVE-IMAGE function but I’m not sure if that works. Also as saving an image kills the process you may want to fork (SB-POSIX:FORK) first, unless you are on Windows. But forking causes problems due to not being well specified and file descriptor issues (i.e. if you try fork->close swank connection->save and die then you may find that the connection in the parent process is closed (or worse, corrupted by appearing open but being closed at some lower level)). One can read about such things online. Note that due to the way sbcl threads are implemented, forking clones only the thread that forks and the other threads are not cloned. Thus forking and then saving should work but may cause problems when running the executable due to partial slime state.
You may be interested in buildapp.
If you want to be able to use slime with your saved application you can load swank and start listening on a socket or port (maybe with some command line argument) and then in Emacs you may connect to that swank backend with slime.
You have to run save-lisp-and-die from a new sbcl, not from Slime. Dan Robertson explains more.
It is cumbersome the first time, but you can put it in a Makefile and re-use it. Don't forget to load your dependencies.
build:
sbcl --load cl-torrents.asd \
--eval '(ql:quickload :torrents)' \
--eval '(use-package :torrents)' \ # not mandatory
--eval "(sb-ext:save-lisp-and-die #p\"torrents\" :toplevel #'main :executable t)"
The quickload implies Quicklisp is already loaded, which may be the case if you installed Quicklisp on your machine, because then your ~/.sbclr contains quicklisp loading script ((load quicklisp-init)).
However sb-ext is not portable across implementations. asdf:make is the cross-platform equivalent. Add this in your .asd system definition:
:build-operation "program-op" ;; leave as is
:build-pathname "<binary-name>"
:entry-point "<my-package:main-function>"
and then call asdf:make to build the executable.
You can have a look at buildapp (mentioned above), a still popular app to do just that, for SBCL and CCL. It is in Debian. http://lisp-lang.org/wiki/article/buildapp An example usage looks like
buildapp --output myapp \
--asdf-path . \
--asdf-tree ~/quicklisp/dists \
--load-system my-app \
--entry my-app:main
But see also Roswell, a more general purpose tool, also supposed to build executables, but it is less documented. https://roswell.github.io/
If you want to build an executable on a CI system (like Gitlab CI), you may appreciate a lisp Docker image which has already SBCL, others lisps and Quicklisp installed, and if you want to parse command line arguments, see https://lispcookbook.github.io/cl-cookbook/testing.html#gitlab-ci and (my) tutorial: https://vindarel.github.io/cl-torrents/tutorial.html#org8567d07
I have been following this tutorial for reference:
http://valgrind.org/docs/manual/ms-manual.html
When I am using it to profile my Application Using the command:
valgrind --tool=massif --time-unit=B ./run.o
It finishes but does not produce any output file.
Here is the log while running it using the mentioned command.
https://www.dropbox.com/s/yae78rm9wmdbph1/ValGring_massif_Log?dl=0
Kindly suggest why it won't produce a massif.out.xxxxx file ?
If you look in your log file you will see that Valgrind has
crashed, and it explains why, and what you should do to fix it.
valgrind: m_mallocfree.c:304 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
valgrind: Heap block lo/hi size mismatch: lo = 91849568, hi = 1425748016.
This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata. If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away. Please try that before reporting this as a bug.
Use Valgrind's memcheck to fix
your program and try again.
I am currently trying to debug my Crash-Handler, it is an external executable that gets called when my program finds an unhandled structured exception. I recompiled the crash-handler executable, and when I tested, I got a message: "Program too big to fit in memory".
After digging around for a bit, I found that this was being caused by the CreateProcess call within my unhandled exception filter. I found this post that says that this error message indicates that the executable is corrupted, however if I invoke the CrashHandler.exe from the command line, I get no such error.
Other Information:
I have tried rebuilding my
application and the crash-handler
multiple times in both debug and
release mode.
I have tried giving the running thread 2 orders of magnitude more stack space.
I tested the same CrashHandler.exe in another application that was already using it, and there were no problems.
I tried using a previous version of the exe that worked before, but with the same result.
Restarting the system.
My Call to CreateProcess:
//Fire off the Handler
//HandlerArgs = "CrashHandler.exe arg1 arg2 arg3 etc..."
if(CreateProcess(NULL, HandlerArgs, NULL, NULL, TRUE, CREATE_PRESERVE_CODE_AUTHZ_LEVEL | CREATE_SUSPENDED,
NULL, NULL, &StartupInfo, &NewProcessHandle))
Turns out that one of my post-build hooks was copying over the exe from The source control repository, and the file I had in the source control repository was actually the pdb. While testing I was copying directly to my running folder, and then the hook would copy the "corrupted" exe over again.