I'm using the latest code checked out from GitHub. (0.13.0 beta)
I'm developing for Android with Eclipse. I did added *COCOS2D_DEBUG* in Android.mk. I checked and made sure that COCOS2D_DEBUG was indeed defined with the value of 1.
Problem: CCLog won't print anything to the LogCat. In the meantime, CCMessageBox works well.
(I then tested the same set of code on iOS, both CCLog and CCMessageBox work well.)
What am I missing here?
Just wondering two thing:
1. are you using CCLog or CCLOG (all big case)?
did you put
#define COCOS2D_DEBUG 1
at the really top (higher than any #include) in the cpp file that you wanna debug?
Use CCLOG("Test String"), all upper case, it will work. CCLog("Hello") don ´t work in eclipse log cat.
If you want to use "CCLog()" then there is need not to be set #define COCOS2D_DEBUG 1
If you want to use CCLOG() then you have to set #define COCOS2D_DEBUG 1
ex for CCLog
CClog("Hi this is CCLog");
Sample code for CCLOG
CCLOG ("Characters: %c %c \n", 'a', 65);
CCLOG ("Decimals: %d %ld\n", 1977, 650000L);
CCLOG ("Preceding with blanks: %10d \n", 1977);
CCLOG ("Preceding with zeros: %010d \n", 1977);
CCLOG ("Some different radixes: %d %x %o %#x %#o \n", 100, 100, 100, 100, 100);
CCLOG ("floats: %4.2f %+.0e %E \n", 3.1416, 3.1416, 3.1416);
CCLOG ("Width trick: %*d \n", 5, 10);
CCLOG ("%s \n", "A string");
My own experience on how to use CCLOG to print info in Eclipse's LogCat:
in Eclipse, your project open jni folder, add -DCCOCOS2D_DEBUG=1 in Application.mk file like this:
APP_CPPFLAGS := -frtti -DCC_ENABLE_CHIPMUNK_INTEGRATION=1 -std=c++1 -fsigned-char -DCCOCOS2D_DEBUG=1
Somewhere in your project cpp files write CCLOG function:
All of these functions CCLOG CCLog log, works, so use just the main one CCLOG...
Eclipse's LogCat is a Terrible tool in my experience, I hate it so much.. Very annoying thing that keeps happening is that after 3-6 builds LogCat stops working, new lines stop appearing, and so I have to restart Eclipse and then LogCat continues working... When I press Clear Log button in LogCat then all the logs disappears and new ones doesn't appear...
Anyways, to see the logs add a filter first, name doesn't matter, and in tag line write: debug info
, then the CCLOGs will show up:
Notes:
I have commented
//#define COCOS2D_DEBUG 1
in my project, made sure that there is no such other line and I still get my CCLOG printed
out in visual studio 2013, and Eclipse's Logcat on windows 7:
I add the same problem : logcat was not showing my cocos2dx logs. Then I understood that my application was always built in release mode.
Make sure to activate debug mode in Eclipse for your project:
- Right-click your project
- Choose "Build Configurations" \ "Set Active" \ "Debug"
No need to modify your application.mk, since a directive is already set there for debugging or for running a release version...
After that to get logs in logcat window,
- Create a new LogCat's filter and in the "by log tag" type
"cocos2d-x debug info" (without quotes)
When running your application, choose your filter in LogCat to view everything.
BTW: use the CCLOG macro when using cocos2dx logs:
CCLOG("Year is %d",2015); // don't use CCLog
As of cocos2dx version 3 at least in Application.mk COCOS2D_DEBUG is set conditionally based on standard NDK flag NDK_DEBUG=1. So just invoke your builds passing
ndk-build NDK_DEBUG=1
This also insures that the appropriate symbols are generated for a debug build. You will want to use the macro "CCLOG" and not the deprecated function call CCLog as the former will expand to nothing in release mode and not incur any performance overhead when building for release.
Related
I am working with a pwn question, and I want to debug v8 using gdb.
But in release version, I can not use job command.
And in a debug version, I will got abort when I called the function which is the main function in this pwn question.
And I have tried to change some #define code, but I failed.
And I tried to pass some compile args, I failed too.
So, how can I solve it?
For Release mode:
The job GDB macro should be functional if you add v8_enable_object_print = true to your args.gn (using gn args out/x64.release). Obviously, debugging a Release-mode binary will be a somewhat "interesting" experience.
For Debug mode:
Bypassing a DCHECK is easy: just comment it out and recompile.
And of course, if you find any bugs, please report them at crbug.com/v8/new :-)
I want to use cmake to compile CUDA with '-arch=sm_12', but cmake/make behave strangely.
I have following CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(test)
FIND_PACKAGE(CUDA REQUIRED)
CUDA_ADD_EXECUTABLE(test prog.cu)
SET(CUDA_NVCC_FLAGS "-arch=sm_12")
SET(CUDA_NVCC_FLAGS ${CUDA_NVCC_FLAGS} CACHE STRING "Forced" FORCE)
but 'cmake ../src && make' leads to a executable for sm_20.
The flag seems to be ignored.
EDIT: If I call 'make' again (without any modification in CMakeListss.txt) it uses the Flag. - But only if I force the flag to cache (last line)
Am I doing anything wrong?
EDIT: After checking again: I have to call 'make' twice to work correctly. Does anybody know this behaviour?
inJeans was right:
FindCUDA-docs https://cmake.org/cmake/help/v3.3/module/FindCUDA.html
This is the essential information:
"Note that any of these flags can be changed multiple times in the same directory before calling CUDA_ADD_EXECUTABLE, CUDA_ADD_LIBRARY, CUDA_COMPILE, CUDA_COMPILE_PTX, CUDA_COMPILE_FATBIN, CUDA_COMPILE_CUBIN or CUDA_WRAP_SRCS:"
I tried messing around with Win32 binaries lately (this is for a big project of mine).
So after some weeks of research, I now have a solid understanding of how Assembly works, how it is converted into binary code and how x86/x64 opcodes work.
The last piece to the puzzle is figuring out how to properly call Win32 API methods.
I actually asked a question on here in relation to this, and the answer I got was, I should try and compile an Assembly or C program that does this. So I went ahead and tried this in Assembly (I'm using FASM by the way):
format PE console
entry start
section '.idata' import data readable writable
include 'win32a.inc'
library kernel,'kernel32.dll'
import kernel,\
GetStdHandle,'GetStdHandle',\
WriteConsoleA,'WriteConsoleA'
section '.data' data readable writable
string db 'Hello!', 0h
output dd ?
section '.code' code readable executable
start: push -11
call GetStdHandle
pushd 0
pushd output
pushd 7
pushd string
pushd eax
call WriteConsoleA
This is one of the many versions of this code actually. The main problem is, when I call methods like "ExitProcess", generally other functions from the kernel32.dll library, things seem to work out. It's the IO functions that bug me...
I don't understand what's wrong with this code, I don't get any compile-time errors, though when I run it, it just crashes.
So my next idea was, since this didn't work, to try the same in C.
I'm using Cygwin as a compiler and linker...
#include <windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
MessageBox(NULL, "Hello, world!", "Test", MB_OK);
return 0;
}
This code yielded the same result, the application crashed.
Now, I am not looking for any C/C++ code. My original question of interest was to know how calling extern library function looks like in x86/x64 binary (assembled) code. But I would be very thankful for any resources regarding this topic.
Thank you in advance.
-Tom S.
Your problem is that you need to call ExitProcess at the end to properly end the process. Since you are not doing that, the code currently will continue executing and eventually segfaults because it attempts to execute junk bytes.
I have a nice fully functioning module (wrtten using tcl/cpp) it works fine.
I want to use ramdebugger to debug scripts using that module
When I enter
load mylib.so
command1_from_lib xx
command2_from lib yy
If (say) command2 returns an error then ramdebugger dies
[paul#paul-es5 ramdebugger7.7.1]$ ./ramdebugger
alloc: invalid block: 0x999c058: 0 0
Aborted
It dies here in libtcl / ResetObjResult
if ((objResultPtr->bytes != NULL)
&& (objResultPtr->bytes != tclEmptyStringRep)) {
ckfree((char *) objResultPtr->bytes);
}
My suspicion is there is confusion over the global tclEmptyStringRep. I think the starkitted(?) ramdebugger has one and the dynamically loaded libtcl has a different one - the bytes pointer should logically be pointing to an empty string but the value there does not match what gdb shows for the global
I am a tcl noob and need any help I can get. Alternatively a suggestion for a different debugger would work
edit: fixed
Use tclStub to defer the link between the extension and the tcl runtime.
This sounds very much like a bug to me, as opposed to a question which this site can answer. You should contact the ramdebugger people to see if they can help.
However, for general Tcl debugging you could also see if the tools produced by ActiveState help; IIRC you can get a free trial to see if they can make any headway. (Myself, I'm of the put-lots-of-printf-calls in school of debugging, so I'm nobody's poster child.)
I have a (rather large) application that I have written in C++ and until recently it has been running fine outside of visual studio from the release build. However, now, whenever I run it it says "Unhandled exception at 0x77cf205b in myprog.exe: 0xC0000005: Access violation writing location 0x45000200.", and leads me to "crtexe.c" at line 582 ("mainret = main(argc, argv, envp);") if I attempt to debug it. Note that this problem never shows if I run my debug executable outside of visual studio, or if I run my debug or release build within visual studio. It only happens when running the release build outside of visual studio.
I have been through and put plenty of printfs and a couple of while(1)s in it to see when it actually crashed, and found that the access violation occurs at exactly the point that the value is returned from the function (I'm returning a pointer to an object). I don't fully understand why I would get an access violation at the point it returns, and it doesn't seem to matter what I'm returning as it still occurs when I return 0.
The point it started crashing was when I added a function which does a lot of reading from a file using ifstream. I am opening the stream every time I attempt to read a new file and close it when I finish reading it.
If I keep attempting to run it, it will run once in about 20 tries. It seems a lot more reliable if I run it off my pen drive (it seems to crash the first 3 or 4 times then run fine after that - maybe it's due to its slower read speed).
Thanks for your help, and if I've missed anything let me know.
EDIT: New info
Well I removed the entirity of the function and replaced it with:
IndexedMesh * loadObj(char * objName)
{
ifstream fp_in;
fp_in.open("lol.bmp", ios::in);
fp_in.clear();
fp_in.close();
IndexedMesh * mesh = new IndexedMesh();
printf("finished");
return mesh;
}
I also tried it with "return 0" and "return new IndexedMesh()". It's all fine until you put the ifstream stuff in. I do have 2 other ifstreams open in different functions (accessing completely different files). Could this be the problem?
It actually errors on the return mesh line, (I got the debugger working with the separate release file). It completely nulls the mesh object when it attempts to return it.
The point it started crashing was when I added a function which does a lot of reading from a file using ifstream. I am opening the stream every time I attempt to read a new file and close it when I finish reading it.
Given your description of the code only failing in release mode outside the debugger I'd examine this function for any unset variables. Compiling debug sets variables (or at least it used to) as did running release code in the debugger.
You are probably running over something stored deep in the stack.
I'll bet that if you were to put this at near the top of your code:
int my_main(int argc, char * argv[], char * envp[]);
int main(int argc, char * argv[], char * envp) {
char ** a;
char ** e;
a = malloc(argc+1); // note: you should test the results for NULL
e = malloc(1+count(envp) ) ;// I'm not writing code to count it, but it's easy
int i = 0;
while (argv[i++]) {
a[i] = strdup(argv[i]);
}
a[i] = argv[i]; // argv[i] is NULL and already in a register
// do the same thing for envp
return my_main(argc, a, e);
}
#define main my_main
then whatever it is that is smashing your stack would instead end up smashing this duplicated environment. It's not garenteed, and it is no fix for your problem, but not that difficult.
Thanks very much for your help, I haven't exactly solved the problem but I have managed to evade it. Basically, if I even mentioned an ifsteam (in that function and that function only), the program crashed.
I actually went as far as altering the function to simply declare an ifstream then return 0. I "fixed" it by declaring the ifstreams as pointers and new-ing them. If I deleted the pointer it crashed out again so I had to set it to 0 (leeeeak).
If anyone could enlighten me as to why this occurs, that would be great. While I'm just happy it works now, I'd rather know why..