Re: Anyone could help me with this memeory problem...

[Paul Pluzhnikov]

Zhou Lei <dark_eaglet@hotmail.com> writes:

> Thanks for your reply, and yes it is not a good style without checking
> the excptions. In this program, the ntree() will return 0 to the
> calling statement if this==0, so "p->lchild=lchild->ntree()" has the
> same meaning with "p->lchild=(lchild ? lchild->nree() : 0) that you
> wrote. 

Calling member function on NULL pointer invokes undefined behavior;
don't do this.

> And I am confused why "new" failed to allocate memory on my
> machine 

It didn't. 

> just crash and say "segmentation fault").

Your program crashed for a totally different reason.
Here is a clue from Insure++:

[junk.cpp:80] **READ_DANGLING**
>>      lchild->cleanup();

  Reading from a dangling pointer: this, while accessing field "lchild"

  Pointer : 0x0804fab0
  In block: 0x0804fab0 thru 0x0804fabf (16 bytes)
                  p, allocated at junk.cpp, 46
                    ptree::ntree()  pc: 0x08049b7e  junk.cpp, 46
                    ptree::ntree()  pc: 0x08049bd5  junk.cpp, 47
                    ptree::ptree()  pc: 0x08049772  junk.cpp, 31
                            main()  pc: 0x0804a59d  junk.cpp, 94

stack trace where memory was freed:
                            free()  pc: 0x4004cc79  (interface)
                __builtin_delete()  pc: 0x4021714e
                   ptree::~ptree()  pc: 0x0804b282  junk.cpp, 23
                  ptree::cleanup()  pc: 0x0804a1fe  junk.cpp, 82
                  ptree::cleanup()  pc: 0x0804a16e  junk.cpp, 80
                   ptree::~ptree()  pc: 0x0804b1f3  junk.cpp, 21
                            main()  pc: 0x0804ab01  junk.cpp, 109

  Stack trace where the error occurred:
                  ptree::cleanup()  pc: 0x0804a142  junk.cpp, 80
                   ptree::~ptree()  pc: 0x0804b1f3  junk.cpp, 21
                  ptree::cleanup()  pc: 0x0804a1fe  junk.cpp, 82
                   ptree::~ptree()  pc: 0x0804b1f3  junk.cpp, 21
                            main()  pc: 0x0804ab01  junk.cpp, 109

... more errors follow ...

Another (free) tool that can detect these kinds of problems on
Linux/x86 is Valgrind (I advise you to use it regularly). Its message
is slightly more cryptic, but it is telling you about the exact
same problem:

==2136== Invalid read of size 4
==2136==    at 0x8048915: ptree::cleanup(void) (junk.cpp:80)
==2136==    by 0x8048E03: ptree::~ptree(void) (junk.cpp:21)
==2136==    by 0x8048938: ptree::cleanup(void) (junk.cpp:82)
==2136==    by 0x8048E03: ptree::~ptree(void) (junk.cpp:21)
==2136==    by 0x8048C20: main (junk.cpp:109)
==2136==    by 0x402919CA: __libc_start_main (in /lib/libc-2.1.3.so)
==2136==    Address 0x40F9E26C is 8 bytes inside a block of size 16 free'd
==2136==    at 0x40166C20: __builtin_delete (vg_clientfuncs.c:199)
==2136==    by 0x8048E21: ptree::~ptree(void) (junk.cpp:22)
==2136==    by 0x8048938: ptree::cleanup(void) (junk.cpp:82)
==2136==    by 0x804891D: ptree::cleanup(void) (junk.cpp:80)
==2136==    by 0x8048E03: ptree::~ptree(void) (junk.cpp:21)
==2136==    by 0x8048C20: main (junk.cpp:109)
==2136==    by 0x402919CA: __libc_start_main (in /lib/libc-2.1.3.so)

If you still do not understand what the bug in your program is,
say so and it will be revealed to you.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.