Re: [Flightgear-devel] EXC_BAD_ACCESS in modified FGFS (on mac os x)
Quoth Darrell Walisser: Is there a way to increase the size of the stack given to fgfs in Mac OS X? I heard of a ulimit command but my machine (10.2.4) doesn't seem to have this. Unsure if stack growing into the heap or vice versa is the problem here. I don't have this either (I used it once on a solaris box). Unless there is infinite recursion, you probably won't overflow the stack. I think you can adjust the underlying thread's stack size though (see man pthread). ulimit is a shell (bash and probably others) builtin, just run ulimit -a Read the bash man page for more information. Regards, David K. Drum [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] EXC_BAD_ACCESS in modified FGFS (on mac os x)
On Monday, February 24, 2003, at 07:28 AM, [EMAIL PROTECTED] wrote: Message: 6 Date: Sun, 23 Feb 2003 22:16:32 -0500 From: Ima Sudonim [EMAIL PROTECTED] To: flightgear flightgear [EMAIL PROTECTED] Subject: [Flightgear-devel] EXC_BAD_ACCESS in modified FGFS (on mac os x) Reply-To: [EMAIL PROTECTED] Are there any ways to test MALLOC/NEW within flightgear looking for bad pointer manipulation or allocation problems? (NOT in CVS but local modifications) MallocDebug is the program/tool you want. It overrides malloc and free (and hence new) to detect memory allocation errors. Is there a way to increase the size of the stack given to fgfs in Mac OS X? I heard of a ulimit command but my machine (10.2.4) doesn't seem to have this. Unsure if stack growing into the heap or vice versa is the problem here. I don't have this either (I used it once on a solaris box). Unless there is infinite recursion, you probably won't overflow the stack. I think you can adjust the underlying thread's stack size though (see man pthread). This is a modified version of flightgear of a friend with a mixture of C++ and C pointer manipulation. Any suggestions on how to begin debugging this? They're currently doing the cout/asm (trap) route. The problem seems specific to memory allocation, some local (stack), some via new. He swears that he isn't deleting anything twice. Problem usually occurs soon after the procedure is called and returns (in a call or object allocation immediately following this proc). The pointer work steps through a buffer got from handleBufferRead() (netBufferChannel) It's probably got a memory smasher. MallocDebug will help you find it (make sure to read MallocDebug's help docs). You can use MallocDebug within GDB, and there are directions on how to do that. I've used MallocDebug to find many memory-related errors, so feel free to email me off-list for further help. HTH, Darrell ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] EXC_BAD_ACCESS in modified FGFS (on mac os x)
Are there any ways to test MALLOC/NEW within flightgear looking for bad pointer manipulation or allocation problems? (NOT in CVS but local modifications) Is there a way to increase the size of the stack given to fgfs in Mac OS X? I heard of a ulimit command but my machine (10.2.4) doesn't seem to have this. Unsure if stack growing into the heap or vice versa is the problem here. This is a modified version of flightgear of a friend with a mixture of C++ and C pointer manipulation. Any suggestions on how to begin debugging this? They're currently doing the cout/asm (trap) route. The problem seems specific to memory allocation, some local (stack), some via new. He swears that he isn't deleting anything twice. Problem usually occurs soon after the procedure is called and returns (in a call or object allocation immediately following this proc). The pointer work steps through a buffer got from handleBufferRead() (netBufferChannel) I want to stress again the problem is not in cvs code. With the changes commented out, fg comes up fine. Thanks, Ima Program received signal EXC_BAD_ACCESS, Could not access memory. 0x900042c8 in free_list_remove_ptr () (gdb) bt #0 0x900042c8 in free_list_remove_ptr () #1 0x90004cec in szone_malloc () #2 0x90004a64 in malloc_zone_malloc () #3 0x0038ad10 in __builtin_new () #4 0x002ce230 in SGPropertyNode::getChild (this=0xd02b050, name=0xdab0b40 wind-speed-kt, index=0, create=218281072) at props.cxx:871 #5 0x002cce18 in find_node (current=0xd02b050, [EMAIL PROTECTED], position=2, create=true) at props.cxx:305 #6 0x002cce28 in find_node (current=0xb9f1d40, [EMAIL PROTECTED], position=1, create=true) at props.cxx:306 #7 0x002d15ac in SGPropertyNode::getNode (this=0xb9f1d40, relative_path=0x3a9ad8 /environment/wind-speed-kt, create=true) at props.cxx:1725 #8 0x002d1d90 in SGPropertyNode::tie (this=0x4318010, relative_path=0xdf34ae0 , [EMAIL PROTECTED], useDefault=true) at props.cxx:1993 #9 0x002a19dc in FGEnvironmentMgr::bind (this=0x4355100) at ../../src/Main/fg_props.hxx:498 #10 0x000225a8 in fgInitSubsystems () at fg_init.cxx:1595 #11 0x5f38 in fgIdleFunction () at main.cxx:1316 #12 0x94fc13c0 in -[GLUTApplication run] () #13 0x94fd9830 in glutMainLoop () #14 0x8b08 in fgMainInit (argc=2, argv=0xb008) at main.cxx:1725 #15 0x8c80 in main (argc=2, argv=0xb158) at main.cxx:1817 #16 0x1f7c in _start (argc=2, argv=0xb158, envp=0xb164) at /SourceCache/Csu/Csu-45/crt.c:267 #17 0x1dfc in start () ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
