I am having trouble with this error I am receiving whenever I run my application. The error is:
loop or previous error loading module 'socket'.
The code that is causing this error is:
socket = require("socket").
This error occurs during the first lua_pcall. Here is the function that calls that:
void startTerminal(int port, char host[80])
{
lua_State *L = lua_open();
/* Open Lua Library */
luaL_openlibs(L);
/* Choose the lua file that will run */
if(luaL_loadfile(L, "socket.lua")) {
lfatal(L, "luaL_loadfile() failed");
}
/* Start lua file */
if(lua_pcall(L, 0, 0, 0)) {
lfatal(L, "lua_pcall()");
}
/* Get connect function */
lua_getglobal(L, "connect");
if(!lua_isfunction(L, -1)) {
lua_pop(L, 1);
lfatal(L, "lua_isfunction() failed");
}
/* Setup arguments */
lua_pushnumber(L, port);
lua_pushstring(L, host);
/* Call the lua function */
if(lua_pcall(L, 2, 2, 0)) {
lfatal(L, "lua_pcall() failed");
}
/* Print out results */
printf("%s", lua_tostring(L, -1));
printf("%s", lua_tostring(L, -1));
lua_close(L);
}
Here is how I am compiling the code:
gcc -Wall -o terminal attacker.c -I/usr/include/lua5.1 -llua5.1 -lm
Am I missing any switches during compile or am I missing library?
NOTE:
The compiler does not throw any errors and compiles cleanly.
In other Lua applications that does not include C, I don't have any problem with require("socket").
Thanks
luaL_loadfile(L, "socket.lua")
This is suspect. Very suspect.
Using the standard Lua loaders, when you issue require("MODULE_NAME"), the very first thing it will look for (after checking to see if MODULE_NAME was already loaded) will be "MODULE_NAME.lua". In the current directory. Which certainly exists. It's called socket.lua, the very file you've loaded and are trying to execute. Therefore, it's going to try to load socket.lua as a module.
And since socket.lua has require("socket") in it, it will load itself again. And again. And again.
Well, it won't because Lua's package loader system is smart enough to detect loops and issue an error. Which is exactly what it did.
So don't name a file MODULE_NAME.lua if you actually are going to require a module with that name.
Related
I have a C program which invokes the TCL interpreter thru Tcl_EvalFile(). I am checking the status return by Tcl_EvalFile and know when it produces something different from TCL_OK. However I am not getting any traceback reporting in my program like I would if I used tclsh.
I know about embedding C functions into TCL but that won't work in my case. I am actually calling TCL from a C function that a Lua program is calling. The example code shown is a simplified version.
Here is the call to Tcl_EvalFile():
if ((status = Tcl_EvalFile(interp, script)) != TCL_OK)
{
/* I would like to handle the error here before Tcl_Exit()*/
Tcl_Exit(status);
return TCL_ERROR;
}
Is there a TCL function that I can call which will produce the traceback message similar to what tclsh produces?
The single most important thing you can do to handle an error is to print the error message out! The second most important thing is to print the stack trace. Tcl puts the error message in the interpreter result, and the stack trace in a special global variable, errorInfo.
if ((status = Tcl_EvalFile(interp, script)) != TCL_OK) {
// Get the error message out of the way *right now*
fprintf(stderr, "ERROR when reading file %s: %s\n", script,
Tcl_GetStringResult(interp));
// Most convenient access for this is to run a tiny Tcl script.
Tcl_Eval(interp, "puts {STACK TRACE:}; puts $errorInfo; flush stdout;");
Tcl_Exit(status);
return TCL_ERROR; // This should be unreachable; Tcl_Exit doesn't return...
}
I know there have been questions asked before about this problem but none seem to shine a light on my problem which is, I am trying to compile a C application and want to access SQLite from within the code (as per test app below) using Eclips as a compile and debugging environment.
I know the .h files are being accessed. the code has as many lines commented out to do with iostream as I have tried to compile this as a C++ app as well.
I get errors one for each of 2 the SQL API.
The real question is do I have to set and How do I set a dependency in Eclipse to allow the api to resolve. Thanks
the code
#include <sqlite3.h>
int main()
{
int RetVal;
RetVal = OpenDB();
return RetVal;
}
int OpenDB()
{
sqlite3 *db; // database connection
int rc; // return code
char *errmsg; // pointer to an error string
/*
* open SQLite database file test.db
* use ":memory:" to use an in-memory database
*/
rc = sqlite3_open(":memory:", &db); //fails on this line
if (rc != SQLITE_OK)
{
goto out;
}
/* use the database... */
out:
/*
* close SQLite database
*/
sqlite3_close(db); //fails on this line
return 0;
}
You need to link the sqlite3 library along with your program:
gcc main.c -lsqlite3
I have have a working project like with the following code , running on Visual Studio 2013, windows 7 N.
I tried to replace luaL_loadfile() with luaL_loadbuffer(L,s,strlen(s),name), so that I could put the script as a string together in the main instead, because in my other project with IAR, I have problem with opening file in the project, but I managed to call a lua script directly with putting the script as a string in the main(). My question would be: how does this luaL_loadbuffer() work? I mean, if I understand this function correctly, luaL_loadbuffer(L,s,strlen(s),name), the "s" means a string. I tried to debug with luaL_loadbuffer(), but could not passing the debug, always got error status= 2. Besides I also see somebody else used luaL_loadbuffer() to load the script file, so I am confused now. Can anyone help me?
-- last.lua
function f ()
print("Hello from Lua")
end
#include <lua.h>
#include <lauxlib.h>
#include <stdlib.h>
#include <stdio.h>
int main()
{
double z;
int error;
lua_State *L = luaL_newstate();
luaL_openlibs(L);
if (luaL_loadfile(L, "last.lua") || lua_pcall(L, 0, 0, 0))
{
printf("error: %s", lua_tostring(L, -1));
return -1;
}
lua_getglobal(L, "f");
if (!lua_isfunction(L, -1))
{
lua_pop(L, 1);
return -1;
}
if (lua_pcall(L, 0, 0, 0) != 0)
{
printf("error running function `f': %s\n", lua_tostring(L, -1));
return -1;
}
lua_close(L);
return 0;
}
Yes, you should be able to do this, assuming you load the file as one chunk (and not try to process it by line or by some other chunk as this will probably make those parts invalid Lua code). There is an example in "Programming Lua" that shows how loadbuffer can be used.
Two additional suggestions: (1) don't remove new lines from the file you read and pass it exactly as is to loadbuffer (otherwise --comment\ncode will turn code into comment), (2) make name look like #name as it will make name to be recognized as the file name (for example, in errors thrown from that code). See description under "source" in 4.9.
I am a newbie at C programming and new on Stackoverflow as well.
I have some c code that compiles and runs in Eclipse Kepler (Java EE IDE); I installed the C/C++ plugin and Cygwin Gcc compiler for c.
Everything runs ok in Eclipse IDE; however, when my friend tries to run the same code on his Codeblocks IDE, he doesn't get any output. At some point, he got some segmentation error, which we later learned was due to our program accessing memory space that didn't belong to our program.
Codeblocks IDE is using Gcc compiler not cygwin gcc, but I don't think they're that different to cause this sort of problem.
I am aware that C is extremely primitive and non-standardized, but why would my code run in eclipse with cygwin-gcc compiler but not run in Codeblocks IDE with gcc compiler?
Please help, it's important for our class project.
Thanks to all.
[EDIT] Our code is a little large to paste in here but here's a sample code of what would RUN SUCCESSFULLY in eclipse but FAIL in codeblocks, try it yourself if you have codeblocks please:
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <string.h>
int main(void) {
char *traceEntry1;
FILE *ifp;
traceEntry1 = malloc(200*sizeof(char));
ifp = fopen("./program.txt", "r");
while (fgets(traceEntry1, 75, ifp))
printf("String input is %s \n", traceEntry1);
fclose(ifp);
}
It simply doesn't give any outputs in codeblocks, sometimes just results in a segmentation fault error.
I have no idea what the problem is.
We need your help please, thanks in advance.
Always and ever test the results of all (revelant) calls. "relevant" at least are those call which return results which are unusable if the call failed.
In the case of the OP's code they are:
malloc()
fopen()
fclose()
A save version of the OP's code could look like this:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int result = EXIT_SUCCESS; /* Be optimistic. */
char * traceEntry1 = NULL; /* Always initialise your variables, you might remove this during the optimisation phase later (if ever) */
FILE * ifp = NULL; /* Always initialise your variables, you might remove this during the optimisation phase later (if ever) */
traceEntry1 = malloc(200 * sizeof(*traceEntry1)); /* sizeof(char) is always 1.
Using the dereferenced target (traceEntry1) on the other hand makes this
line of code robust against modifications of the target's type declaration. */
if (NULL == traceEntry1)
{
perror("malloc() failed"); /* Log error. Never ignore useful and even free informaton. */
result = EXIT_FAILURE; /* Flag error and ... */
goto lblExit; /* ... leave via the one and only exit point. */
}
ifp = fopen("./program.txt", "r");
if (NULL == ifp)
{
perror("fopen() failed"); /* Log error. Never ignore useful and even free informaton. */
result = EXIT_FAILURE; /* Flag error ... */
goto lblExit; /* ... and leave via the one and only exit point. */
}
while (fgets(traceEntry1, 75, ifp)) /* Why 75? Why not 200 * sizeof(*traceEntry1)
as that's what was allocated to traceEntr1? */
{
printf("String input is %s \n", traceEntry1);
}
if (EOF == fclose(ifp))
{
perror("fclose() failed");
/* Be tolerant as no poisened results are returned. So do not flag error. It's logged however. */
}
lblExit: /* Only have one exit point. So there is no need to code the clean-up twice. */
free(traceEntry1); /* Always clean up, free what you allocated. */
return result; /* Return the outcome of this exercise. */
}
I am working on system that loads all *.so modules library automatically by call a script.
I tried to update one of the modules to support XML-RPC. I used the library ibxmlrpc-c3-dev on Ubuntu 10.10. The problem that dlopen() fails after my changes and dlerror() returns NULL. The compilation does not return any error.
How can I debug and fix this issue? Below is the code:
#include "stdlib.h"
#include "stdio.h"
#ifndef WIN32
#include "unistd.h"
#endif
#include "xmlrpc-c/base.h"
#include "xmlrpc-c/server.h"
#include "xmlrpc-c/server_abyss.h"
#include "config.h" /* information about this build environment */
And, I added this function , most of the lines are commented out ,even though dlopen() fails:
int RPC_Server(int const port) {
// xmlrpc_server_abyss_parms serverparm;
//xmlrpc_registry * registryP;
xmlrpc_env env;
xmlrpc_env_init(&env);
//registryP = xmlrpc_registry_new(&env);
// xmlrpc_registry_add_method(
// &env, registryP, NULL, "sample.add", &sample_add, NULL);
/* In the modern form of the Abyss API, we supply parameters in memory
like a normal API. We select the modern form by setting
config_file_name to NULL:
*/
// serverparm.config_file_name = NULint
RPC_Server(int const port) {
// xmlrpc_server_abyss_parms serverparm;
//xmlrpc_registry * registryP;
xmlrpc_env env;
xmlrpc_env_init(&env);
//registryP = xmlrpc_registry_new(&env);
// xmlrpc_registry_add_method(
// &env, registryP, NULL, "sample.add", &sample_add, NULL);
/* In the modern form of the Abyss API, we supply parameters in memory
like a normal API. We select the modern form by setting
config_file_name to NULL:
*/
// serverparm.config_file_name = NULL;
// serverparm.registryP = registryP;
// serverparm.port_number = port;
// serverparm.log_file_name = "/tmp/xmlrpc_log";
// printf("Running XML-RPC server...\n");
// xmlrpc_server_abyss(&env, &serverparm, XMLRPC_APSIZE(log_file_name));
/* xmlrpc_server_abyss() never returns */
return 0;
}L;
// serverparm.registryP = registryP;
// serverparm.port_number = port;
// serverparm.log_file_name = "/tmp/xmlrpc_log";
// printf("Running XML-RPC server...\n");
// xmlrpc_server_abyss(&env, &serverparm, XMLRPC_APSIZE(log_file_name));
/* xmlrpc_server_abyss() never returns */
return 0;
}
and this is the code the is used to load modules
#ifndef RTLD_NOW
#define RTLD_NOW DL_LAZY
#endif
void* handle;
char* error;
handle=dlopen(mod->binary_file, RTLD_NOW);
if (!handle){
LOG( " could not open file [%s]: %s\n",
mod_cfg->binary_file, dlerror() );
return 0;
}
In this code:
handle=dlopen(mod->binary_file, RTLD_NOW);
if (!handle) {
LOG( " could not open file [%s]: %s\n",
mod_cfg->binary_file, dlerror() );
the most likely way I can think of for the dlerror() to return NULL here is if LOG itself calls one of the dl* routines (which would clear the error state that dlerror returns).
So,
show us what LOG macro (if indeed it is a macro) expands to, and
run the program under GDB, set breakpoints on dlopen, dlmopen, dlsym and dlvsym, and observe that one of them is called after your call to dlopen above and before your call to dlerror.
I would use a debugger like gdb.
If you cannot use it, try to use strace or ltrace on the process doing the dlopen
Also, clear errno before calling dlopen and display it (or print it under the debugger) just after the failing dlopen.
Check with file, objdump, and nm -D that your dlopen-ed *.so file has all the required properties (e.g. symbols).
Perhaps the memory address space of the process doing the dlopen is so full (or has reached some resource limits) that some internal malloc inside libdl.so fails (e.g. the one used by dlerror).
handle=dlopen(mod->binary_file, RTLD_NOW);
if (!handle){
string errmsg = string(dlerror());
LOG( " could not open file [%s]: %s\n",
mod_cfg->binary_file, errmsg.c_str() );
return 0;
}
I come across the same problem when using BoostLog, and above is my solution.
I suppose LOG affects dlerror().
I had this problem with VirtualBox and Qt5 on an Ubuntu system; Qt5 couldn't dynamically load libqxcb.so, and after some debugging it turned out that both dlopen() and dlerror() were returning NULL.
The cause turned out to be because VirtualBox is a setuid binary and can't dlopen libraries in directories that aren't owned by root. In my case, the solution was as simple as running:
sudo chown root:root /usr/lib/x86_64-linux-gnu
My non-root user (with UID 1000) owned /usr/lib/x86_64-linux-gnu somehow, likely some error on my part. But after returning ownership to root, VirtualBox—and by extension Qt—could load libraries just fine.
I suspect this may have something to do with AppArmor, but I've no experience with it so I can't say for sure.
Above all, you should definitely use dlerror.