I need add some log informations with souce file name, function name,
line number etc...
I have check the official docs, but not found...
so, how to do for it ?
This is usually done via GLib logging.
For example try this Vala application:
int main (string[] args) {
// info () is not shown by default, set G_MESSAGES_DEBUG=all in your shell to see them
info ("Hello World");
warning ("Hello World");
//assert_true (false);
// error () terminates the program
error ("Hello World");
return 0;
}
The output is:
$ G_MESSAGES_DEBUG=all src/glib_logging_test
** INFO: glib_logging_test.vala:4: Hello World
** (process:10129): WARNING **: glib_logging_test.vala:5: Hello World
** (process:10129): ERROR **: glib_logging_test.vala:9: Hello World
Trace/Breakpoint ausgelöst
You can also set G_DEBUG in addition to G_MESSAGES_DEBUG, see running GLib applications.
You can install a custom handler with Log.set_handler () as well.
There is also Log.FILE, Log.LINE, Log.METHOD for the raw information equivalent to the C macros.
Related
I'm looking for something gdb --core equivalent on webassembly.
Take this example:
//crash.cpp
#include <iostream>
int main() {
std::cout << "crashing soon..." << std::endl;
int *a = 0;
*a = 1;
}
I compile this with:
$ em++ -g4 crash.cpp -o crash.html --source-map-base http://localhost:8080/
And start the server:
$ emrun --no_browser --port 8080 crash.html
So how can I get a stack trace of this core dump/crash? The console on both chrome/firefox when visiting page just shows a js stacktrace and that won't help me. Looking at Sources => Call stack on chrome console just shows "Not paused", after the crash.
This is on debian 11, emscripten 2.0.12~dfsg-2, clang-11.
The reason is that what you're doing is not an error in WebAssembly. Like on many embedded platforms, writing to or reading from zero pointer is a perfectly valid operation in WebAssembly memory model.
However, Emscripten tries to help you catch this as for C/C++ it's a common mistake, so what it does instead is checks the value at the address zero after the program has finished execution and throws a helpful assertion if that value happened to be overwritten. For this reason you're getting a stacktrace with only JavaScript bits in it - because the check is done by JavaScript when Wasm stack has already been exited.
If you tried a different operation that does cause immediate abort, for example, assert(false), then you would see WebAssembly and/or C/C++ on the stack as expected.
I'd like to compile the following C++ snippet using threads with Emscripten
#include <cstdio>
#include <thread>
void foo() { puts("foo\n"); }
void bar(int x) { printf("bar %d\n", x); }
int main(int argc, char* argv[]) {
std::thread first(foo);
std::thread second(bar, 123);
puts("main, foo and bar now execute concurrently...\n");
first.join();
second.join();
puts("foo and bar completed.\n");
}
To get Emscripten to use threads I pass the "-s USE_PTHREADS=1" option during compilation and linking
target_compile_options(
Emscripten PRIVATE -v "SHELL:-s USE_PTHREADS=1 -s PTHREAD_POOL_SIZE=8")
target_link_options(
Emscripten PRIVATE -v --emrun
"SHELL:-s MINIFY_HTML=0 -s USE_PTHREADS=1 -s PTHREAD_POOL_SIZE=8")
I also change the suffix of the compilation output to .html which leads to Emscripten directly producing a .html page
set(CMAKE_EXECUTABLE_SUFFIX ".html")
So far so good. The snippet compiles as expected and I can see the toolchain passing some pthread arguments on the command line.
In order to test the output I fire up a webserver with python and open the .html page with Firefox. The Firefox option javascript.options.shared_memory was enabled by default in my version (78.0.1) so I thought that my code should work out of the box. Sadly this isn't the case and I'm getting Uncaught ReferenceError: SharedArrayBuffer is not defined exceptions thrown at me through the console.
Testing the code with node works though:
$ node --experimental-wasm-threads --experimental-wasm-bulk-memory Emscripten.js
main, foo and bar now execute concurrently...
foo
bar 123
foo and bar completed.
/edit
Ok, seems like SharedArrayBuffer still undergoes some standardization process...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes
I'm absolutely new to firefox add-on development and I can't understand why does the simplest example from the tutorial not work.
I accurately followed all the steps from here: https://developer.mozilla.org/en-US/Add-ons/SDK/Tutorials/Getting_started
and I can't find the add-on button anywhere in the browser window. Standard buttons only:
add-on sdk seems to be set up properly, cfx works fine. Here is the console output of cfx run:
(addon-sdk-1.17)[12:40:05]sergey#linuxmain:my-addon> cfx run
Using binary at '/usr/bin/firefox'.
(process:10986): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Using profile at '/tmp/tmpPxd9iD.mozrunner'.
(process:10996): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
(process:11006): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
[10996] WARNING: Attempt to add property GnomeProgram::sm-connect after class was initialised: 'glib warning', file /home/abuild/rpmbuild/BUILD/mozilla/toolkit/xre/nsSigHandlers.cpp, line 140
(firefox:10996): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised
[10996] WARNING: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised: 'glib warning', file /home/abuild/rpmbuild/BUILD/mozilla/toolkit/xre/nsSigHandlers.cpp, line 140
(firefox:10996): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised
[10996] WARNING: Attempt to add property GnomeProgram::display after class was initialised: 'glib warning', file /home/abuild/rpmbuild/BUILD/mozilla/toolkit/xre/nsSigHandlers.cpp, line 140
(firefox:10996): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised
[10996] WARNING: Attempt to add property GnomeProgram::default-icon after class was initialised: 'glib warning', file /home/abuild/rpmbuild/BUILD/mozilla/toolkit/xre/nsSigHandlers.cpp, line 140
(firefox:10996): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
JavaScript error: resource://app/components/nsBrowserGlue.js, line 1610: NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIPrefBranch.getComplexValue]
What the last line of this output is about? Maybe it is the reason?
Add-on files and Python version:
(addon-sdk-1.17)[12:46:06]sergey#linuxmain:my-addon> ls data/
icon-16.png icon-32.png icon-64.png
(addon-sdk-1.17)[12:46:10]sergey#linuxmain:my-addon> cat lib/main.js
var buttons = require('sdk/ui/button/action');
var tabs = require("sdk/tabs");
var button = buttons.ActionButton({
id: "mozilla-link",
label: "Visit Mozilla",
icon: {
"16": "./icon-16.png",
"32": "./icon-32.png",
"64": "./icon-64.png"
},
onClick: handleClick
});
function handleClick(state) {
tabs.open("https://www.mozilla.org/");
}
(addon-sdk-1.17)[12:46:15]sergey#linuxmain:my-addon> python --version
Python 2.7.6
I run Firefox version 36.0. The add-on itself is present:
So what am I missing? How to bring add-on button to the panel?
Upd:
If I disable the addon, open & clear browser console and then re-enable addon, then I get the following console output:
Warning: attempting to write 4867 bytes to preference extensions.bootstrappedAddons. This is bad for general performance and memory usage. Such an amount of data should rather be written to an external file.
Warning: attempting to write 4670 bytes to preference extensions.xpiState. This is bad for general performance and memory usage. Such an amount of data should rather be written to an external file.
So there are no red-colored errors.
This question is with reference to the question in the link:
"** exception error: undefined function add:addfunc/0 in Erlang "
I'm trying to execute a simple erlang program of adding two numbers. I'm trying to do this in Eclipse on Ubuntu 10.04 LTS.
When I execute this program, I'm getting the error as shown below:
-module(add).
-export([addfunc/0]).
addfunc() ->
6 + 5.
" ** exception error: undefined function add:addfunc/0 "
This program when executed in the erlang shell is working fine. But when it comes to eclipse it's giving me this error. Not this, any program for that matter is giving me the similar error. Guess I would be missing something about the eclipse configuration.
I haven't tested your code, but this very basic code should work.
The message says that your function does not exist.
Make sure that you have no errors at compile time.
Check whether your function is exported with:
add:module_info().
the result should look alike this:
[{module,add},
{exports,[{addfunc,0},
.....
I am running Lua with a C++ library via swig. When a swig runtime error occurs I would like to know the line which caused the problem. The error message I receive does not have this information.
How can I find which line in the Lua code triggered the error?
For example suppose I have a swig function "swigstringcount" and it takes a string:
local n=4
local m=swigstringcount(n)
print (m,n)
This (obviously wrong) code produces an error on line two. Currently all I get is
error:SWIG_RuntimeError: swigstringcount requires a string
I want it to tell me that line 2 produced the error, like standard Lua error messages.
Based on this method for getting debug info from the Lua C API I've put together a (slightly messy) example of how you can integrate that into a SWIG interface:
%module test
%{
#undef SWIG_fail_arg
#define SWIG_fail_arg(func_name,argnum,type) \
{lua_Debug ar;\
lua_getstack(L, 1, &ar);\
lua_getinfo(L, "nSl", &ar);\
lua_pushfstring(L,"Error (%s:%d) in %s (arg %d), expected '%s' got '%s'",\
ar.source,ar.currentline,func_name,argnum,type,SWIG_Lua_typename(L,argnum));\
goto fail;}
%}
%include <std_string.i>
%inline %{
void func(const std::string& str) {}
%}
This basically replaces the default SWIG_fail_arg macro with a modified one that gets and prints some debug info.
I tested it with the latest SWIG trunk (I think you might be using an older version since the text I see didn't quite match), but I was able to do:
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> require('test')
> local n=4
> test.func(n)
Error (=stdin:1) in func (arg 1), expected 'std::string const &' got 'nil'
stack traceback:
[C]: in function 'func'
stdin:1: in main chunk
[C]: ?
I seem to have more debug info (i.e. a full stack trace) there already though.