0

When I run the project on my Mac everything is fine. The same project run on Windows 64 I crash upon start.

Both use NDK8e. How can I find out what is the difference?

Windows 64

05-09 04:25:51.310: D/dalvikvm(16908): Shared lib '/data/data/com.evotegra.aCoDriver/lib/libjsqlite.so' already loaded in same CL 0x4219e688
05-09 04:25:51.335: A/libc(16908): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 16908 (tegra.aCoDriver)

Mac

05-09 04:49:09.070: D/dalvikvm(307): Shared lib '/data/data/com.evotegra.aCoDriver/lib/libjsqlite.so' already loaded in same CL 0x4219d5f8
05-09 04:49:40.735: V/SoundPoolThread(27591): beginThread
tmanthey
  • 4,547
  • 6
  • 35
  • 42

1 Answers1

1

I this case I had checked in a an old lib with the wrong architecture in the projects libs folder. As long as the lib was there and the source not changed, the compiler does not replace it, and hence it crashes all the time. Remove the obj folder, and check the architecture of all libraries in the libs folder

tmanthey
  • 4,547
  • 6
  • 35
  • 42
  • Really thanks for the answer! I had been facing same problem for few weeks! You deserve +1. – dg_no_9 Dec 23 '13 at 07:12
  • Hi there, I thought I've fixed the problem, but it's still happening! My case is just opposite to that of question(works in windows, not in mac). Do you have any idea about which lib files and how to check architecture of all libraries? – dg_no_9 Dec 23 '13 at 09:02
  • Try to delete all the shared libs in the libs Folder. – tmanthey Dec 24 '13 at 09:16
  • try using ndk_stack. Example here http://stackoverflow.com/questions/18436383/how-to-check-crash-log-using-android-ndk-in-cocos2d-x – tmanthey Dec 27 '13 at 05:50
  • I've tried ndk-stack as well, and found trace on cocos2dx class's destructors, removeAllChildren() function and this one: /mnt/asec/com..../lib/***.so: Routine std::basic_string, std::allocator >::basic_string(std::string const&) at libgcc2.c: ? Any idea on this one? – dg_no_9 Dec 27 '13 at 07:32
  • Check if you are trying to access memory you dynamically allocated with (m/c)alloc after you called free. That would cause a perfect perfect SIGSEV aka segmentation fault. – tmanthey Dec 28 '13 at 09:19