I'm going over a very basic erlang book while using yaws. I'm editing a single yaws file and refreshing the browser. Often (3rd time now) the process will just start to show this error. and i look and look for a syntax error or anything, and eventually i just restart the process and everything works. without any change to the source file.
right now this is the source file that triggered the error this last time
<erl>
out(Arg) ->
{ehtml,
{table, [{width, "100%"}],
{tr,[],
[{td, [{width, "50%"}], "hello world!"},
{td, [{width, "50%"}], "hi again."}]
}
}
}.
</erl>
I tried searching the error, but where all the search results have a meaningful context like "no access" all i get is "<<>>"
=ERROR REPORT==== 26-Nov-2013::20:17:32 ===
Yaws process died: {{badmatch,<<>>},
[{yaws_server,skip_data,2,
[{file,"yaws_server.erl"},{line,2951}]},
{yaws_server,deliver_dyn_file,6,
[{file,"yaws_server.erl"},{line,2717}]},
{yaws_server,aloop,4,
[{file,"yaws_server.erl"},{line,1152}]},
{yaws_server,acceptor0,2,
[{file,"yaws_server.erl"},{line,1013}]},
{proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,227}]}]}
Some version info:
Yaws 1.94
Debian GNU/Linux 7.2 (wheezy)
Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:4:4] [async-threads:0] [hipe] [kernel-poll:false]
Any ideas what this is telling me?
Also, any suggestions for debuggers that are good for beginners is very welcome.
For debugging, I think using Erlang tracing will be helpful. We want to figure out why the yaws_server:skip_data/2 function would be getting a badmatch exception, and specifically why it's getting an empty binary passed to it as that's the only way it could encounter that error. So we need to trace that condition. Try these steps (and don't forget the trailing period on each Erlang shell command):
Run yaws in interactive mode: yaws -i
Once yaws comes up, hit enter to get an Erlang shell prompt.
Create a tracing function for dbg so we get a reasonably formatted backtrace from the trace data: F = fun({trace,_,_,_,Dump},[]) -> io:format("~s~n", [binary_to_list(Dump)]), [] end.
Turn on tracing with this command: dbg:tracer(process, {F, []}).
Trace calls in all processes: dbg:p(all, call).
Now trace the condition of yaws_server:skip_data/2 getting an empty binary as a first argument, and when it does, get a backtrace:
dbg:tpl(yaws_server,skip_data,dbg:fun2ms(fun([<<>>, _]) -> message(process_dump()) end)).
With this in place, start hitting your .yaws page until you provoke the condition, at which point a backtrace will be displayed in your Erlang shell. If you get that backtrace, please copy it into a gist or pastebin and post a link to it as a follow-up here.
If I am correct the output of the out function is supposed to be a list. I didn't check your whole code but the following should work:
<erl>
out(Arg) ->
[{ehtml,
{table, [{width, "100%"}],
{tr,[],
[{td, [{width, "50%"}], "hello world!"},
{td, [{width, "50%"}], "hi again."}]
}
}
}].
</erl>
Related
Starting 2020-12-09, VSCode's Rust Analyzer extension no longer loads for me. On launch, it prints out this error message:
Cannot activate rust-analyzer: bootstrap error. See the logs in "OUTPUT > Rust Analyzer Client" (should open automatically). To enable verbose logs use { "rust-analyzer.trace.extension": true }
Enabling extension tracing produces the following diagnostic just before failing:
INFO [12/10/2020, 10:03:22 AM]: Using server binary at c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe
DEBUG [12/10/2020, 10:03:22 AM]: Checking availability of a binary at c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe
DEBUG [12/10/2020, 10:03:22 AM]: c:\Users\<user>\AppData\Roaming\Code\User\globalStorage\matklad.rust-analyzer\rust-analyzer-windows.exe --version: {
status: 3221225506,
signal: null,
output: [ null, '', '' ],
pid: 1648,
stdout: '',
stderr: ''
}
where <user> is the name of the user account I use to log into the system1.
The status value reported in the error diagnostic (3221225506) translates to 0xC0000022 (STATUS_ACCESS_DENIED). Navigating to the binary from within VSCode's integrated terminal and trying to execute rust-analyzer-windows.exe --version doesn't produce any output, which seems to reinstate that running this executable from VSCode is somehow blocked.
It appears that something changed with respect to access rights executing the server binary from within VSCode. In between Rust Analyzer working and Rust Analyzer no longer working I didn't update Rust, nor rustup, nor VSCode, nor any extensions.
I did install 2020-12 Cumulative Update for Windows 10 Version 20H2 for x64-based Systems (KB4592438), though, and the time Rust Analyzer started failing coincides with the time the update got installed. That could literally just be a coincidence.
What additional steps can I take to get to the root cause of the issue, and how do I get Rust Analyzer working again?
Version information:
Rust Analyzer (stable): v0.2.408
Windows 10 Pro: Version 10.0.19042 Build 19042
VSCode: 1.51.1 (user setup)
1 This is also the user account VSCode runs under, including all of its spawned processes. Navigating to the path from a command prompt running under this account reveals that rust-analyzer-windows.exe is present, and executing rust-analyzer-windows.exe --version prints a version identifier, as expected.
Unfortunately, I didn't quite get to investigate the root cause of this.
A system reboot that was forced upon me appears to have restored World Peace.
Clearing proxy config works for me.
I'm not sure this covered all situation, but it might be related to the network.
I'm new to NS3. I studied vanet-routing-compair.cc script. I tried to run it by these commands (vanet-routing-compare.cc is in scratch folder).
./waf --run scratch/vanet-routing-compare
./waf --run "vanet-routing-compare --scenario=1 --saveconfig=scenario1.txt"
But I'm getting confused with the results. I get following error messages.
msg="Could not connect callback to /NodeList/*/DeviceList/*/ns3::WifiNetDevice/Phy/PhyTxDrop", file=../src/core/model/config.cc, line=920 terminate called without an active exception
Command ['/home/azra/Desktop/ns-allinone-3.31/ns-3.31/build/scratch/vanet-routing-compare'] terminated with signal SIGIOT. Run it under a debugger to get more information (./waf --run <program> --gdb").
And by using the gdb debugger, I see this message.
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/azra/Desktop/ns-allinone-3.31/ns-3.31/build/scratch/vanet-routing- compare --scenario=1 --saveconfig=scenario1.txt
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
msg="Could not connect callback to /NodeList/*/DeviceList/*/ns3::WifiNetDevice /Phy/PhyTxDrop", file=../src/core/model/config.cc, line=920
terminate called without an active exception
Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 }
I appreciate who can help me understand why this is happening and how I can solve it.
I got the same error in version 3.31, but the version 3.30 is ok. Maybe you can also try version 3.30.
I believe since version 3.31 the names changed from ns3:: to $ns3::
https://groups.google.com/g/ns-3-users/c/VWTV9ZdY7fs/m/MxRdIoLoAAAJ[Here][1]
The workaround I use is to copy the entire file from here:gitlab of ns3 development branch
As you can see, there were few (more than a few) changes in the code.
I've installed GnuCOBOL 2.2 on my Ubuntu 17.04 system. I've written a basic hello world program to test the compiler.
1 IDENTIFICATION DIVISION.
2 PROGRAM-ID. HELLO-WORLD.
3 *---------------------------
4 DATA DIVISION.
5 *---------------------------
6 PROCEDURE DIVISION.
7 DISPLAY 'Hello, world!'.
8 STOP RUN.
This program is entitled HelloWorld.cbl. When I compile the program with the command
cobc HelloWorld.cbl
HelloWorld.so is produced. When I attempt to run the compiled program using
cobcrun HelloWorld
I receive the following error:
libcob: entry point 'HelloWorld' not found
Can anyone explain to me what an entry point is in GnuCOBOL, and perhaps suggest a way to fix the problem and successfully execute this COBOL program?
According to the official manual of GNUCOBOL, you should compile your code with:
cobc -x HelloWorld.cbl
then run it with
./HelloWorld
You can also read GNUCOBOL wiki page which contains some exmaples for further information.
P.S. As Simon Sobisch said, If you change your file name to HELLO-WORLD.cbl to match the program ID, the same commands that you have used will be ok:
cobc HELLO-WORLD.cbl
cobcrun HELLO-WORLD
Can anyone explain to me what an entry point is in GnuCOBOL, and perhaps suggest a way to fix the problem and successfully execute this COBOL program?
An entry point is a point where you may enter a shared object (this is actually more C then COBOL).
GnuCOBOL generates entry points for each PROGRAM-ID, FUNCTION-ID and ENTRY. Therefore your entry point is HELLO-WORLD (which likely gets a conversion as - is no valid identifier in ANSI C - you won't have to think about this when CALLing a program as the conversion will be done internal).
Using cobcrun internally does:
search for a shared object (in your case HelloWord), as this is found (because you've generated it) it will be loaded
search for an entry point in all loaded modules - which isn't found
There are three possible options to get this working:
As mentioned in Ho1's answer: use cobc -x, the reason that this works is because you don't generate a shared object at all but a C main which is called directly (= the entry point doesn't apply at all)
preload the shared object and calling the program by its PROGRAM-ID (entry point), either manually with COB_PRE_LOAD=HelloWorld cobcrun HELLO-WORLD or through cobcrun (option available since GnuCOBOL 2.x) cobcrun -M HelloWorld HELLO-WORLD
change the PROGRAM-ID to match the source name (either rename or change the source, I'd do the second: PROGRAM-ID. HelloWorld.)
I'm trying to serve a big number of small files with G-WAN (version 4.3.14, started with sudo on 64-bit Ubuntu 14.04.3). I start hammering it with requests over a single connection using wget to provide base URL and a file with a list of the URL suffixes. At some point, which is different for different runs, the gwan executable silently exits. There's no trace in the gwan log or in the site error log (I did change '_log' to 'log' to enable logging). The exit status code is 139. What does it mean? When I stop it with Ctrl-C the exit code is 130.
Is there a reference for the exit status codes? I cannot find any with Google.
First, Ubuntu 14.04.3 is very recent while G-WAN v4.3.14 is very old. Almost every new OS release introduces cincompatibilities that require patches and this is why we have to issue more recent releases for registered users. This explains the 'silent exits' that you are experiencing.
Second, process exits codes can be found this way:
./gwan -h
echo $?
0
Zero means no error, and any other value is an error (mixing system flags to be as informative as possible). That's why Ctrl+C returns 130: Control-C is fatal error signal 2, (130 = 128 + 2).
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.