Forums › Project › Development v
libODE and GIMPACT vs OPCODE (car jumps around? look here)

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Modes
libODE and GIMPACT vs OPCODE (car jumps around? look here)
09-18-2007, 03:35 PM,
#16
xTs Offline
Member
***
 		Posts: 150
Threads: 8
Joined: Oct 2006
 
ok, i used gdb and then valgrind, but i couldn't figure out where the bug is.

It might be in gim_copy_buffers (gim_memory.cpp:864), but i cant find out what could be wrong there.

Or somewhere in gim_alloc... who knows...


Output of valgrind:
Code:
==24257== Invalid write of size 1
==24257==    at 0x4C23833: memcpy (mc_replace_strmem.c:406)
==24257==    by 0x58F162D: gim_copy_buffers(GBUFFER_ID*, unsigned, GBUFFER_ID*, unsigned, unsigned) (gim_memory.cpp:864)
==24257==    by 0x58F3A86: gim_trimesh_create_from_arrays(GIM_TRIMESH*, GBUFFER_ARRAY*, GBUFFER_ARRAY*, char) (gim_trimesh.cpp:56)
==24257==    by 0x58F3C1E: gim_trimesh_create_from_data(GIM_TRIMESH*, float (*) [3], unsigned, char, unsigned*, unsigned, char, char) (gim_trimesh.cpp:118)
==24257==    by 0x58E3EC1: dxTriMesh::dxTriMesh(dxSpace*, dxTriMeshData*) (collision_trimesh_gimpact.cpp:316)
==24257==    by 0x58E422B: dCreateTriMesh (collision_trimesh_gimpact.cpp:371)
==24257==    by 0x4C7A56: PHYSICSOBJECT::InitTrimesh(void const*, int, int, void const*, int, int, void const*, PHYSICSOBJECTSETTINGS const&) (physics.cpp:73)
==24257==    by 0x44A1C8: OBJECTNODE::RegisterWithCollisionSystem() (objects.cpp:405)
==24257==    by 0x44B15F: OBJECTS::Add(VERTEX, float, std::string, std::string, bool, bool, bool, bool, bool, bool, JOEPACK*, float, float, float, float, float, float, SCENENODE*) (objects.cpp:144)
==24257==    by 0x44BE03: OBJECTS::LoadObjectsFromFolder(std::string) (objects.cpp:300)
==24257==    by 0x41EB4F: GAME::LoadWorld() (game.cpp:515)
==24257==    by 0x529273: VGUI::Gui::ProcessAction(std::string) (gui.cpp:994)
==24257==  Address 0x98BD904 is 4 bytes before a block of size 588 alloc'd
==24257==    at 0x4C21C16: malloc (vg_replace_malloc.c:149)
==24257==    by 0x58F14D8: gim_alloc(unsigned long) (gim_memory.cpp:124)
==24257==    by 0x58F2157: _system_buffer_alloc_function(unsigned, int) (gim_memory.cpp:258)
==24257==    by 0x58F1E0C: gim_create_buffer(unsigned, unsigned, int, GBUFFER_ID*) (gim_memory.cpp:502)
==24257==    by 0x58F1EC3: gim_buffer_array_copy_value(GBUFFER_ARRAY*, GBUFFER_ARRAY*, unsigned, int) (gim_memory.cpp:927)
==24257==    by 0x58F3A86: gim_trimesh_create_from_arrays(GIM_TRIMESH*, GBUFFER_ARRAY*, GBUFFER_ARRAY*, char) (gim_trimesh.cpp:56)
==24257==    by 0x58F3C1E: gim_trimesh_create_from_data(GIM_TRIMESH*, float (*) [3], unsigned, char, unsigned*, unsigned, char, char) (gim_trimesh.cpp:118)
==24257==    by 0x58E3EC1: dxTriMesh::dxTriMesh(dxSpace*, dxTriMeshData*) (collision_trimesh_gimpact.cpp:316)
==24257==    by 0x58E422B: dCreateTriMesh (collision_trimesh_gimpact.cpp:371)
==24257==    by 0x4C7A9D: PHYSICSOBJECT::InitTrimesh(void const*, int, int, void const*, int, int, void const*, PHYSICSOBJECTSETTINGS const&) (physics.cpp:75)
==24257==    by 0x4CEA97: BEZIERNODE::RegisterCollisionData() (track.cpp:406)
==24257==    by 0x4D0538: ROADSTRIP::GenerateCollisionData() (track.cpp:353)
--24257-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--24257-- si_code=1;  Faulting address: 0x400BE2646A;  sp: 0x4032AAD60

valgrind: the 'impossible' happened:
   Killed by fatal signal
==24257==    at 0x380209E9: vgPlain_arena_malloc (m_mallocfree.c:190)
==24257==    by 0x38035847: vgPlain_cli_malloc (replacemalloc_core.c:101)
==24257==    by 0x38002305: vgMemCheck_malloc (mc_malloc_wrappers.c:182)
==24257==    by 0x38035ED7: do_client_request (scheduler.c:1158)
==24257==    by 0x380375C2: vgPlain_scheduler (scheduler.c:869)
==24257==    by 0x38052F1E: run_a_thread_NORETURN (syswrap-linux.c:87)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==24257==    at 0x4C21C16: malloc (vg_replace_malloc.c:149)
==24257==    by 0x58F14D8: gim_alloc(unsigned long) (gim_memory.cpp:124)
==24257==    by 0x58F2157: _system_buffer_alloc_function(unsigned, int) (gim_memory.cpp:258)
==24257==    by 0x58F1E0C: gim_create_buffer(unsigned, unsigned, int, GBUFFER_ID*) (gim_memory.cpp:502)
==24257==    by 0x58F1EC3: gim_buffer_array_copy_value(GBUFFER_ARRAY*, GBUFFER_ARRAY*, unsigned, int) (gim_memory.cpp:927)
==24257==    by 0x58F3A86: gim_trimesh_create_from_arrays(GIM_TRIMESH*, GBUFFER_ARRAY*, GBUFFER_ARRAY*, char) (gim_trimesh.cpp:56)
==24257==    by 0x58F3C1E: gim_trimesh_create_from_data(GIM_TRIMESH*, float (*) [3], unsigned, char, unsigned*, unsigned, char, char) (gim_trimesh.cpp:118)
==24257==    by 0x58E3EC1: dxTriMesh::dxTriMesh(dxSpace*, dxTriMeshData*) (collision_trimesh_gimpact.cpp:316)
==24257==    by 0x58E422B: dCreateTriMesh (collision_trimesh_gimpact.cpp:371)
==24257==    by 0x4C7A56: PHYSICSOBJECT::InitTrimesh(void const*, int, int, void const*, int, int, void const*, PHYSICSOBJECTSETTINGS const&) (physics.cpp:73)
==24257==    by 0x44A1C8: OBJECTNODE::RegisterWithCollisionSystem() (objects.cpp:405)
==24257==    by 0x44B15F: OBJECTS::Add(VERTEX, float, std::string, std::string, bool, bool, bool, bool, bool, bool, JOEPACK*, float, float, float, float, float, float, SCENENODE*) (objects.cpp:144)
==24257==    by 0x44BE03: OBJECTS::LoadObjectsFromFolder(std::string) (objects.cpp:300)
==24257==    by 0x41EB4F: GAME::LoadWorld() (game.cpp:515)
==24257==    by 0x529273: VGUI::Gui::ProcessAction(std::string) (gui.cpp:994)
==24257==    by 0x52BBE8: VGUI::Gui::MouseRelease() (gui.cpp:329)
==24257==    by 0x42218F: GAME::Start(std::list<std::string, std::allocator<std> >&) (game.cpp:1619)
==24257==    by 0x40A0A0: main (main.cpp:26)

Thread 2: status = VgTs_Runnable
==24257==    at 0x65775D7: ioctl (in /lib/libc-2.6.1.so)
==24257==    by 0x685FB31: (within /usr/lib/libasound.so.2.0.0)
==24257==    by 0x688451C: (within /usr/lib/libasound.so.2.0.0)
==24257==    by 0x688545C: (within /usr/lib/libasound.so.2.0.0)
==24257==    by 0x686E939: (within /usr/lib/libasound.so.2.0.0)
==24257==    by 0x685A1F6: snd_pcm_write_areas (in /usr/lib/libasound.so.2.0.0)
==24257==    by 0x68630D1: snd_pcm_mmap_writei (in /usr/lib/libasound.so.2.0.0)
==24257==    by 0x4E5918B: (within /usr/lib/libSDL-1.2.so.0.11.0)
==24257==    by 0x4E2EBA3: (within /usr/lib/libSDL-1.2.so.0.11.0)
==24257==    by 0x4E368E6: (within /usr/lib/libSDL-1.2.so.0.11.0)
==24257==    by 0x4E79A48: (within /usr/lib/libSDL-1.2.so.0.11.0)
==24257==    by 0x74C8316: start_thread (in /lib/libpthread-2.6.1.so)
==24257==    by 0x657EC6C: clone (in /lib/libc-2.6.1.so)
Find
Reply
10-12-2007, 11:51 AM,
#17
abs1nth Offline
Senior Member
****
 		Posts: 358
Threads: 5
Joined: Sep 2005
 
btw. ODE 0.9 is out
Find
Reply
10-12-2007, 12:37 PM,
#18
alex25 Offline
Senior Member
****
 		Posts: 531
Threads: 42
Joined: Jun 2006
 
abs1nth Wrote:btw. ODE 0.9 is out

but it doesn't work for me on my i386 laptop with gimpact. i had to stay with r1222.

--alex--
Find
Reply
10-12-2007, 12:50 PM,
#19
xTs Offline
Member
***
 		Posts: 150
Threads: 8
Joined: Oct 2006
 
the problem here is the old version of GIMPACT ode ships.


(and i still think we shoud switch completly to bullet. Joe knows why Wink
Find
Reply
10-12-2007, 01:07 PM,
#20
alex25 Offline
Senior Member
****
 		Posts: 531
Threads: 42
Joined: Jun 2006
 
xTs Wrote:(and i still think we shoud switch completly to bullet. Joe knows why Wink

what is bullet?

--alex--
Find
Reply
10-12-2007, 01:30 PM,
#21
alex25 Offline
Senior Member
****
 		Posts: 531
Threads: 42
Joined: Jun 2006
 
alex25 Wrote:\what is bullet?

i think i found it at http://www.continuousphysics.com/Bullet/. is that it?

--alex--
Find
Reply
10-12-2007, 03:27 PM,
#22
xTs Offline
Member
***
 		Posts: 150
Threads: 8
Joined: Oct 2006
 
Yes, and it supports more than one core... means: more performance for those with multicore cpus.

(I think its clever to use such a lib, because the number of cores will increase further in the near future)

But its Joes choice.
Find
Reply
10-12-2007, 09:12 PM,
#23
cotharyus Offline
Senior Member
****
 		Posts: 332
Threads: 17
Joined: Oct 2006
 
Personally, I'm all for it. I've been running nothing but multi-core (or multi-CPU) systems since about '96. Currently, it might help things out on my mac book, and it would certainly help things out on my current desktop (Athlon 64x2) and my next desktop (at least a 4 core mac pro). Multi-core development is the way of the future.
Find
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)