Programming Forums > Application Development > C++

rwm · Jun 28th, 2007, 6:20 AM

actually i just found the reason no core dump was happening, i hadnt reloaded my shell, so the environment variables werent being registered properly...

ive managed to get core dump now, so im gonna look through gdb and try find the location of crash...

rwm · Jun 28th, 2007, 6:59 AM

it doesnt appear to be showing the location of the crash???

(Toggle Plain Text)

gdb test core.7612
GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xed4000
Core was generated by `./test /usr/local/massive/Library/loco_agents_set-1.0.3/cdl/loco_casual_agent-1'.
Program terminated with signal 6, Aborted.

warning: svr4_current_sos: Can't read pathname for load map: Input/output error

Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/aw/maya7.0/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/aw/maya/lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x00ed4402 in __kernel_vsyscall ()
(gdb)

i forced a seg fault in the code, and sure enough it shows the location of the crash:

(Toggle Plain Text)

gdb test core.8100
GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xf99000
Core was generated by `./test /usr/local/massive/Library/loco_agents_set-1.0.3/cdl/loco_casual_agent-1'.
Program terminated with signal 11, Segmentation fault.

warning: svr4_current_sos: Can't read pathname for load map: Input/output error

Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/aw/maya7.0/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/aw/maya/lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
[b]#0 0x08065497 in MassiveToolkit::CDLParser::Parse (this=0xb7517008,
f=0xbff2f507 "/usr/local/massive/Library/loco_agents_set-1.0.3/cdl/loco_casual_agent-1.0.3.cdl") at CDLParser.cpp:96
96 *p = 101;

ive googled for linux signals and found

SIGABRT 6 Core Abort signal from abort(3)

so what does signal 6 mean exactly? if its an invalid pointer what is causing the abort call? free? coz its an invalid pointer? im getting closer to the bug, but how would one start to try locate the bug?

looking forward to a response!

rwm · Jun 28th, 2007, 7:11 AM

ok i found the bug, it was a pointer that i forgot to set to NULL...

could someone suggest what tools/stuff i need to know for debugging (cross-platform, preferably linux tho). i really havent had much experience with this, so that would be very helpful!

thanks!

lectricpharaoh · Jun 28th, 2007, 2:31 PM

Quote:

Originally Posted by rwm

ok i found the bug, it was a pointer that i forgot to set to NULL...

could someone suggest what tools/stuff i need to know for debugging (cross-platform, preferably linux tho). i really havent had much experience with this, so that would be very helpful!

thanks!

Set your poitners to NULL whenever you create them (unless you also initialize in the same step), and set them to NULL immediately after a call to delete or free(). In fact, I've often thought it would be a good idea if free() and delete did this as part of their operation; you could overload delete to accomplish this.

grumpy · Jun 28th, 2007, 6:03 PM

Quote:

Originally Posted by rwm

ok i found the bug, it was a pointer that i forgot to set to NULL...

Yep; as I said in another thread ..... pointer molestation. You dereferenced an invalid pointer (eg an uninitialised pointer, a dangling reference, ....).

Quote:

Originally Posted by lectricpharaoh

Set your poitners to NULL whenever you create them (unless you also initialize in the same step), and set them to NULL immediately after a call to delete or free().

This isn't always necessary, and adds an unnecessary performance overhead for some applications. There is also the fact you have to check if a pointer is non-NULL before using it, or the tactic you describe will not work.

As a matter of fact, I've never used such a tactic in production code. I only use it with small code snippets that I hack up to verify something specific, and I never use those snippets again.

The real issue with pointers is that it is easy to make mistakes with them, unless you use a disciplined design approach ..... when you declare a pointer, you need an explicit notion of when it will be initialised, what it will point to, and what you do if the life of the pointer exceeds the life of the object it points to. Very few people do that. Essentially your coding practice needs to involve "think/analyse, design, code", and most people do the approach of "hack code, test, find it doesn't work right, hack again, get in trouble, think a bit, hack again, and .... eventually, but sometimes never ... find cause, try to get code working right, cross fingers and pray when you deliver to customer".

Quote:

Originally Posted by lectricpharaoh

In fact, I've often thought it would be a good idea if free() and delete did this as part of their operation; you could overload delete to accomplish this.

Even if I agreed this was a good idea, which I don't, it wouldn't matter. It is not possible to fiddle with free() and operator delete() in this way.

To make free() do this it would be necessary to change it's basic behaviour (eg so it accepts a pointer to a pointer).

To get operator delete() functions to do this, it would be necessary to specify an operator delete() that accepts a reference to a pointer. The compiler would then complain about ambiguity: when deleting an object both the default form ::operator delete(void *) [which is implicitly declared, as far as the compiler is concerned, in all source files] and the overloaded version ::operator delete (void *&x) would be candidates to be invoked.

rwm · Jun 29th, 2007, 3:05 AM

ok thanks guys!

lectricpharaoh · Jun 29th, 2007, 4:56 AM

Quote:

Originally Posted by grumpy

This isn't always necessary, and adds an unnecessary performance overhead for some applications. There is also the fact you have to check if a pointer is non-NULL before using it, or the tactic you describe will not work.

My reasoning is not that the programmer should remember to check a pointer before use- though this is certainly a good idea when a pointer is returned from many library functions- but instead to limit the amount of damage that access through an uninitialized or released pointer may cause. Rather than the program exhibiting some potentially subtle bug somewhere down the road, access through a NULL pointer should cause immediate (and obvious) failure. It should then be comparatively simple to track down where things went wrong.

Quote:

Originally Posted by grumpy

To make free() do this it would be necessary to change it's basic behaviour (eg so it accepts a pointer to a pointer).

To get operator delete() functions to do this, it would be necessary to specify an operator delete() that accepts a reference to a pointer. The compiler would then complain about ambiguity: when deleting an object both the default form ::operator delete(void *) [which is implicitly declared, as far as the compiler is concerned, in all source files] and the overloaded version ::operator delete (void *&x) would be candidates to be invoked.

Yeah, I didn't think it through before I spoke. <pulls foot from mouth>

grumpy · Jun 29th, 2007, 9:28 AM

Quote:

Originally Posted by lectricpharaoh

My reasoning is not that the programmer should remember to check a pointer before use- though this is certainly a good idea when a pointer is returned from many library functions- but instead to limit the amount of damage that access through an uninitialized or released pointer may cause. Rather than the program exhibiting some potentially subtle bug somewhere down the road, access through a NULL pointer should cause immediate (and obvious) failure. It should then be comparatively simple to track down where things went wrong.

If that was true, life would be much easier. However, dereferencing a NULL (like any form of pointer molestation) causes undefined behaviour -- which means anything is allowed to happen. It just so happens that dereferencing NULL causes a simple program crash on some operating systems with some behaviours by an applications. There is no theoretical guarantee of what you say and, unfortunately, it is not always true in practice either.

I can give you a few horror stories involving strange dereferencing of a NULL pointer, that were a bit hard to find. The worst case (in my younger days, before I was taken to task by someone more experienced) was a program that exhibited a crash when compiled with optimisation, but would reformat the hard drive (an MS-DOS machine) when the program was compiled without optimisation and stepped through with a debugger. The need to rebuild the hard drive (fortunately it was backed up regularly) made the debugging process rather protracted. The root cause turned out to be a nested loop that was triple dereferencing a NULL pointer. That experience is one of the many reasons I'm an advocate of disciplined design and coding practices to prevent such things happening in the first place. Hacking may seem easier, but actually wastes time in the long run.

rwm · Jul 2nd, 2007, 2:44 AM

that makes sense... no use hacking away, planning is key i suppose!

Jun 28th, 2007, 6:59 AM	#22
rwm Professional Programmer Join Date: Jan 2007 Location: Cape Town Posts: 291 Rep Power: 2	it doesnt appear to be showing the location of the crash??? (Toggle Plain Text) gdb test core.7612 GNU gdb Red Hat Linux (6.3.0.0-1.21rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xed4000 Core was generated by `./test /usr/local/massive/Library/loco_agents_set-1.0.3/cdl/loco_casual_agent-1'. Program terminated with signal 6, Aborted. warning: svr4_current_sos: Can't read pathname for load map: Input/output error Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/aw/maya7.0/lib/libgcc_s.so.1...done. Loaded symbols for /usr/aw/maya/lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x00ed4402 in __kernel_vsyscall () (gdb) gdb test core.7612 GNU gdb Red Hat Linux (6.3.0.0-1.21rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xed4000 Core was generated by `./test /usr/local/massive/Library/loco_agents_set-1.0.3/cdl/loco_casual_agent-1'. Program terminated with signal 6, Aborted. warning: svr4_current_sos: Can't read pathname for load map: Input/output error Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/aw/maya7.0/lib/libgcc_s.so.1...done. Loaded symbols for /usr/aw/maya/lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x00ed4402 in __kernel_vsyscall () (gdb) i forced a seg fault in the code, and sure enough it shows the location of the crash: (Toggle Plain Text) gdb test core.8100 GNU gdb Red Hat Linux (6.3.0.0-1.21rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xf99000 Core was generated by `./test /usr/local/massive/Library/loco_agents_set-1.0.3/cdl/loco_casual_agent-1'. Program terminated with signal 11, Segmentation fault. warning: svr4_current_sos: Can't read pathname for load map: Input/output error Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/aw/maya7.0/lib/libgcc_s.so.1...done. Loaded symbols for /usr/aw/maya/lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 [b]#0 0x08065497 in MassiveToolkit::CDLParser::Parse (this=0xb7517008, f=0xbff2f507 "/usr/local/massive/Library/loco_agents_set-1.0.3/cdl/loco_casual_agent-1.0.3.cdl") at CDLParser.cpp:96 96 p = 101; gdb test core.8100 GNU gdb Red Hat Linux (6.3.0.0-1.21rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xf99000 Core was generated by `./test /usr/local/massive/Library/loco_agents_set-1.0.3/cdl/loco_casual_agent-1'. Program terminated with signal 11, Segmentation fault. warning: svr4_current_sos: Can't read pathname for load map: Input/output error Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/aw/maya7.0/lib/libgcc_s.so.1...done. Loaded symbols for /usr/aw/maya/lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 [b]#0 0x08065497 in MassiveToolkit::CDLParser::Parse (this=0xb7517008, f=0xbff2f507 "/usr/local/massive/Library/loco_agents_set-1.0.3/cdl/loco_casual_agent-1.0.3.cdl") at CDLParser.cpp:96 96 p = 101; ive googled for linux signals and found SIGABRT 6 Core Abort signal from abort(3) so what does signal 6 mean exactly? if its an invalid pointer what is causing the abort call? free? coz its an invalid pointer? im getting closer to the bug, but how would one start to try locate the bug? looking forward to a response!

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Overloading >> and +	fhslacrosse13	C++	3	Nov 3rd, 2006 7:18 AM
C++ Global Variables question	Ricky205	C++	7	May 21st, 2005 10:12 AM
Overloading	jon182	C++	0	Mar 12th, 2005 9:09 PM
my Calculator	layer	Other Scripting Languages	4	Mar 9th, 2005 7:09 PM
global variables	uman	C++	2	Feb 20th, 2005 10:39 PM

Jun 28th, 2007, 6:20 AM	#21
rwm Professional Programmer Join Date: Jan 2007 Location: Cape Town Posts: 291 Rep Power: 2	actually i just found the reason no core dump was happening, i hadnt reloaded my shell, so the environment variables werent being registered properly... ive managed to get core dump now, so im gonna look through gdb and try find the location of crash...

Jun 28th, 2007, 7:11 AM	#23
rwm Professional Programmer Join Date: Jan 2007 Location: Cape Town Posts: 291 Rep Power: 2	ok i found the bug, it was a pointer that i forgot to set to NULL... could someone suggest what tools/stuff i need to know for debugging (cross-platform, preferably linux tho). i really havent had much experience with this, so that would be very helpful! thanks!

Jun 29th, 2007, 3:05 AM	#26
rwm Professional Programmer Join Date: Jan 2007 Location: Cape Town Posts: 291 Rep Power: 2	ok thanks guys!

Jul 2nd, 2007, 2:44 AM	#29
rwm Professional Programmer Join Date: Jan 2007 Location: Cape Town Posts: 291 Rep Power: 2	that makes sense... no use hacking away, planning is key i suppose!

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Programming Forums > Application Development > C++

overloading global new/delete