Help: Segmentation fault - Linux

This is a discussion on Help: Segmentation fault - Linux ; 1. run the application agent: Segmentation fault cal:/home/allen # ./agent Segmentation fault 2. debug using gdb cal:/home/allen # gdb ./agent GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Help: Segmentation fault

  1. Help: Segmentation fault

    1. run the application agent: Segmentation fault

    cal:/home/allen # ./agent

    Segmentation fault

    2. debug using gdb

    cal:/home/allen # gdb ./agent
    GNU gdb 6.5
    Copyright (C) 2006 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 "i586-suse-linux"...Using host libthread_db
    library "/lib/libthread_db.so.1".

    (gdb) r
    Starting program: /home/allen/iec61850v2/bin/x86/agent
    Failed to read a valid object file image from memory.
    [Thread debugging using libthread_db enabled]
    [New Thread -1212356912 (LWP 9639)]


    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread -1212356912 (LWP 9639)]
    0xb7c34c92 in ptmalloc_init () from /lib/libc.so.6
    (gdb)

    Please help me. Thank you.

    Allen

  2. Re: Help: Segmentation fault

    Allen wrote on Fri, 14 Dec 2007 20:08:27 -0800:

    > 1. run the application agent: Segmentation fault
    >
    > cal:/home/allen # ./agent


    How can we run this application which seems to be homemade or some such?
    I for one don't have an executable agent in my home directory.

    > Segmentation fault
    >
    > 2. debug using gdb
    >
    > cal:/home/allen # gdb ./agent
    > GNU gdb 6.5
    > Copyright (C) 2006 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 "i586-suse-linux"...Using host libthread_db
    > library "/lib/libthread_db.so.1".
    >
    > (gdb) r
    > Starting program: /home/allen/iec61850v2/bin/x86/agent Failed to read a
    > valid object file image from memory. [Thread debugging using
    > libthread_db enabled] [New Thread -1212356912 (LWP 9639)]
    >


    This line says that gdb failed to read a _valid_ object file image from
    memory using the file in /home/allen/iec61850v2/bin/x86/agent. That looks
    to me like the file /home/allen/.../agent isn't an executable for your
    platform.

    >
    > Program received signal SIGSEGV, Segmentation fault. [Switching to
    > Thread -1212356912 (LWP 9639)] 0xb7c34c92 in ptmalloc_init () from
    > /lib/libc.so.6 (gdb)
    >
    > Please help me. Thank you.
    >


    How can I help, if I (i) don't know the application your trying to run
    and (ii) you don't supply source code or a link to the application so I
    can get it?

    --
    Simon Gerber
    simugerber@student.ethz.ch

  3. Re: Help: Segmentation fault

    Allen writes:

    > Program received signal SIGSEGV, Segmentation fault.
    > [Switching to Thread -1212356912 (LWP 9639)]
    > 0xb7c34c92 in ptmalloc_init () from /lib/libc.so.6
    > (gdb)


    Here are some gdb commands that you should have executed:

    where
    info shared

    Also, knowing how you linked 'agent' may provide clues.

    Finally, any crash inside malloc (which is what appears to be
    happening here) is with 99.9% probability a result of heap
    corruption. Run your app under Valgrind; it will likely tell you
    exactly where your problem is.

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

  4. Re: Help: Segmentation fault

    On 12月16日, 上午12时20分, Paul Pluzhnikov
    wrote:
    > Allen writes:
    > > Program received signal SIGSEGV, Segmentation fault.
    > > [Switching to Thread -1212356912 (LWP 9639)]
    > > 0xb7c34c92 in ptmalloc_init () from /lib/libc.so.6
    > > (gdb)

    >
    > Here are some gdb commands that you should have executed:
    >
    > where
    > info shared
    >
    > Also, knowing how you linked 'agent' may provide clues.
    >
    > Finally, any crash inside malloc (which is what appears to be
    > happening here) is with 99.9% probability a result of heap
    > corruption. Run your app under Valgrind; it will likely tell you
    > exactly where your problem is.
    >
    > Cheers,
    > --
    > In order to understand recursion you must first understand recursion.
    > Remove /-nsp/ for email.


    Thank you Paul!

    I will detect the bug using Valgrind. Because the crash occurs at the
    calling function coded by another person provided with a shared
    library, I am really doubted he compiled the error version for me.

    The most strange thing is that I can compile the source code and then
    run it under Eclipse IDE, but can not run in the terminal.
    I really wonder why.

    Thank you again.

  5. Re: Help: Segmentation fault

    On 12月16日, 上午1时25分, Allen wrote:
    > On 12月16日, 上午12时20分, Paul Pluzhnikov
    > wrote:
    >
    >
    >
    > > Allen writes:
    > > > Program received signal SIGSEGV, Segmentation fault.
    > > > [Switching to Thread -1212356912 (LWP 9639)]
    > > > 0xb7c34c92 in ptmalloc_init () from /lib/libc.so.6
    > > > (gdb)

    >
    > > Here are some gdb commands that you should have executed:

    >
    > > where
    > > info shared

    >
    > > Also, knowing how you linked 'agent' may provide clues.

    >
    > > Finally, any crash inside malloc (which is what appears to be
    > > happening here) is with 99.9% probability a result of heap
    > > corruption. Run your app under Valgrind; it will likely tell you
    > > exactly where your problem is.

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

    >
    > Thank you Paul!
    >
    > I will detect the bug using Valgrind. Because the crash occurs at the
    > calling function coded by another person provided with a shared
    > library, I am really doubted he compiled the error version for me.
    >
    > The most strange thing is that I can compile the source code and then
    > run it under Eclipse IDE, but can not run in the terminal.
    > I really wonder why.
    >
    > Thank you again.


    Valgrind is wonderful.
    Today I can run agent in the shell, not login X window. Very strange.
    Maybe it has something wrong with VmWare?

    The following is valgrind log info.

    ==13294== Memcheck, a memory error detector.
    ==13294== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et
    al.
    ==13294== Using LibVEX rev 1804, a library for dynamic binary
    translation.
    ==13294== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
    ==13294== Using valgrind-3.3.0, a dynamic binary instrumentation
    framework.
    ==13294== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et
    al.
    ==13294== For more details, rerun with: -v
    ==13294==
    ==13294== My PID = 13294, parent PID = 3266. Prog and args are:
    ==13294== ./agent
    ==13294==
    ==13294== Syscall param semctl(arg) points to uninitialised byte(s)
    ==13294== at 0x4306E6E: semctl@@GLIBC_2.2 (in /lib/libc-2.5.so)
    ==13294== by 0x406B554: CSemLock::Close() (semlock.cpp:88)
    ==13294== by 0x406A983: CMapFile::Close() (mapfile.cpp:130)
    ==13294== by 0x406AE83: CMapFile::~CMapFile() (mapfile.cpp:34)
    ==13294== by 0x412D236: CRdbNode::~CRdbNode() (rdbnode.cpp:45)
    ==13294== by 0x8056C74: CRdbAdapter::Open() (RdbAdapter.cpp:442)
    ==13294== by 0x8082FC2: ServerInit (SSServer.cpp:459)
    ==13294== by 0x8082EFD: StartServer (SSServer.cpp:568)
    ==13294== by 0x808D9E7: main (main_posix.cpp:54)
    ==13294== Address 0xbef2ee38 is on thread 1's stack
    ==13294==
    ==13294== Thread 7:
    ==13294== Invalid read of size 4
    ==13294== at 0x40A50AA: mvl_end_acse (mvl_acse.c:670)
    ==13294== by 0x40A8331: srv_clear (server.c:333)
    ==13294== by 0x40A1DFA: SSAcsi_Clear (acsi.c:220)
    ==13294== by 0x8083A61: AcsiThread (SSServer.cpp:280)
    ==13294== by 0x808DEBF: WinThreadFunc(void*) (vxworks_posix.cpp:74)
    ==13294== by 0x4056111: start_thread (in /lib/libpthread-2.5.so)
    ==13294== by 0x43052ED: clone (in /lib/libc-2.5.so)
    ==13294== Address 0x4e90130 is 112 bytes inside a block of size 232
    free'd
    ==13294== at 0x40233FC: free (vg_replace_malloc.c:323)
    ==13294== by 0x40BBB4B: x_chk_free (mem_chks.c:1164)
    ==13294== by 0x40A504D: mvl_end_acse (mvl_acse.c:667)
    ==13294== by 0x40A8331: srv_clear (server.c:333)
    ==13294== by 0x40A1DFA: SSAcsi_Clear (acsi.c:220)
    ==13294== by 0x8083A61: AcsiThread (SSServer.cpp:280)
    ==13294== by 0x808DEBF: WinThreadFunc(void*) (vxworks_posix.cpp:74)
    ==13294== by 0x4056111: start_thread (in /lib/libpthread-2.5.so)
    ==13294== by 0x43052ED: clone (in /lib/libc-2.5.so)
    ==13294==
    ==13294== Invalid read of size 4
    ==13294== at 0x40A505F: mvl_end_acse (mvl_acse.c:672)
    ==13294== by 0x40A8331: srv_clear (server.c:333)
    ==13294== by 0x40A1DFA: SSAcsi_Clear (acsi.c:220)
    ==13294== by 0x8083A61: AcsiThread (SSServer.cpp:280)
    ==13294== by 0x808DEBF: WinThreadFunc(void*) (vxworks_posix.cpp:74)
    ==13294== by 0x4056111: start_thread (in /lib/libpthread-2.5.so)
    ==13294== by 0x43052ED: clone (in /lib/libc-2.5.so)
    ==13294== Address 0x4e90134 is 116 bytes inside a block of size 232
    free'd
    ==13294== at 0x40233FC: free (vg_replace_malloc.c:323)
    ==13294== by 0x40BBB4B: x_chk_free (mem_chks.c:1164)
    ==13294== by 0x40A504D: mvl_end_acse (mvl_acse.c:667)
    ==13294== by 0x40A8331: srv_clear (server.c:333)
    ==13294== by 0x40A1DFA: SSAcsi_Clear (acsi.c:220)
    ==13294== by 0x8083A61: AcsiThread (SSServer.cpp:280)
    ==13294== by 0x808DEBF: WinThreadFunc(void*) (vxworks_posix.cpp:74)
    ==13294== by 0x4056111: start_thread (in /lib/libpthread-2.5.so)
    ==13294== by 0x43052ED: clone (in /lib/libc-2.5.so)
    ==13294==
    ==13294== Invalid read of size 4
    ==13294== at 0x40A5071: mvl_end_acse (mvl_acse.c:674)
    ==13294== by 0x40A8331: srv_clear (server.c:333)
    ==13294== by 0x40A1DFA: SSAcsi_Clear (acsi.c:220)
    ==13294== by 0x8083A61: AcsiThread (SSServer.cpp:280)
    ==13294== by 0x808DEBF: WinThreadFunc(void*) (vxworks_posix.cpp:74)
    ==13294== by 0x4056111: start_thread (in /lib/libpthread-2.5.so)
    ==13294== by 0x43052ED: clone (in /lib/libc-2.5.so)
    ==13294== Address 0x4e90194 is 212 bytes inside a block of size 232
    free'd
    ==13294== at 0x40233FC: free (vg_replace_malloc.c:323)
    ==13294== by 0x40BBB4B: x_chk_free (mem_chks.c:1164)
    ==13294== by 0x40A504D: mvl_end_acse (mvl_acse.c:667)
    ==13294== by 0x40A8331: srv_clear (server.c:333)
    ==13294== by 0x40A1DFA: SSAcsi_Clear (acsi.c:220)
    ==13294== by 0x8083A61: AcsiThread (SSServer.cpp:280)
    ==13294== by 0x808DEBF: WinThreadFunc(void*) (vxworks_posix.cpp:74)
    ==13294== by 0x4056111: start_thread (in /lib/libpthread-2.5.so)
    ==13294== by 0x43052ED: clone (in /lib/libc-2.5.so)
    ==13294==
    ==13294== Invalid read of size 4
    ==13294== at 0x40A507B: mvl_end_acse (mvl_acse.c:675)
    ==13294== by 0x40A8331: srv_clear (server.c:333)
    ==13294== by 0x40A1DFA: SSAcsi_Clear (acsi.c:220)
    ==13294== by 0x8083A61: AcsiThread (SSServer.cpp:280)
    ==13294== by 0x808DEBF: WinThreadFunc(void*) (vxworks_posix.cpp:74)
    ==13294== by 0x4056111: start_thread (in /lib/libpthread-2.5.so)
    ==13294== by 0x43052ED: clone (in /lib/libc-2.5.so)
    ==13294== Address 0x4e90194 is 212 bytes inside a block of size 232
    free'd
    ==13294== at 0x40233FC: free (vg_replace_malloc.c:323)
    ==13294== by 0x40BBB4B: x_chk_free (mem_chks.c:1164)
    ==13294== by 0x40A504D: mvl_end_acse (mvl_acse.c:667)
    ==13294== by 0x40A8331: srv_clear (server.c:333)
    ==13294== by 0x40A1DFA: SSAcsi_Clear (acsi.c:220)
    ==13294== by 0x8083A61: AcsiThread (SSServer.cpp:280)
    ==13294== by 0x808DEBF: WinThreadFunc(void*) (vxworks_posix.cpp:74)
    ==13294== by 0x4056111: start_thread (in /lib/libpthread-2.5.so)
    ==13294== by 0x43052ED: clone (in /lib/libc-2.5.so)
    ==13294==
    ==13294== Invalid read of size 4
    ==13294== at 0x40A5089: mvl_end_acse (mvl_acse.c:676)
    ==13294== by 0x40A8331: srv_clear (server.c:333)
    ==13294== by 0x40A1DFA: SSAcsi_Clear (acsi.c:220)
    ==13294== by 0x8083A61: AcsiThread (SSServer.cpp:280)
    ==13294== by 0x808DEBF: WinThreadFunc(void*) (vxworks_posix.cpp:74)
    ==13294== by 0x4056111: start_thread (in /lib/libpthread-2.5.so)
    ==13294== by 0x43052ED: clone (in /lib/libc-2.5.so)
    ==13294== Address 0x4e90198 is 216 bytes inside a block of size 232
    free'd
    ==13294== at 0x40233FC: free (vg_replace_malloc.c:323)
    ==13294== by 0x40BBB4B: x_chk_free (mem_chks.c:1164)
    ==13294== by 0x40A504D: mvl_end_acse (mvl_acse.c:667)
    ==13294== by 0x40A8331: srv_clear (server.c:333)
    ==13294== by 0x40A1DFA: SSAcsi_Clear (acsi.c:220)
    ==13294== by 0x8083A61: AcsiThread (SSServer.cpp:280)
    ==13294== by 0x808DEBF: WinThreadFunc(void*) (vxworks_posix.cpp:74)
    ==13294== by 0x4056111: start_thread (in /lib/libpthread-2.5.so)
    ==13294== by 0x43052ED: clone (in /lib/libc-2.5.so)
    ==13294== Warning: client switching stacks? SP change: 0xBEF2F1C8 -->
    0xFFFFFFFB
    ==13294== to suppress, use: --max-stackframe=1091374643 or
    greater
    ==13294==
    ==13294== Thread 1:
    ==13294== Invalid read of size 4
    ==13294== at 0x808DA3D: main (main_posix.cpp:65)
    ==13294== Address 0xfffffffb is not stack'd, malloc'd or (recently)
    free'd
    ==13294==
    ==13294== Process terminating with default action of signal 11
    (SIGSEGV)
    ==13294== Access not within mapped region at address 0xFFFFFFFB
    ==13294== at 0x808DA3D: main (main_posix.cpp:65)
    ==13294==
    ==13294== ERROR SUMMARY: 13 errors from 7 contexts (suppressed: 5 from
    1)
    ==13294== malloc/free: in use at exit: 312,788 bytes in 40 blocks.
    ==13294== malloc/free: 26,191 allocs, 26,151 frees, 16,435,066 bytes
    allocated.
    ==13294== For counts of detected errors, rerun with: -v
    ==13294== searching for pointers to 40 not-freed blocks.
    ==13294== checked 51,316,616 bytes.
    ==13294==
    ==13294==
    ==13294== 256 bytes in 1 blocks are definitely lost in loss record 3
    of 12
    ==13294== at 0x4023CB4: operator new[](unsigned)
    (vg_replace_malloc.c:268)
    ==13294== by 0x8083859: AcsiThread (SSServer.cpp:226)
    ==13294== by 0x808DEBF: WinThreadFunc(void*) (vxworks_posix.cpp:74)
    ==13294== by 0x4056111: start_thread (in /lib/libpthread-2.5.so)
    ==13294== by 0x43052ED: clone (in /lib/libc-2.5.so)
    ==13294==
    ==13294==
    ==13294== 864 bytes in 6 blocks are possibly lost in loss record 6 of
    12
    ==13294== at 0x402297E: calloc (vg_replace_malloc.c:397)
    ==13294== by 0x4011037: allocate_dtv (in /lib/ld-2.5.so)
    ==13294== by 0x40110FB: _dl_allocate_tls (in /lib/ld-2.5.so)
    ==13294== by 0x405690F: pthread_create@@GLIBC_2.1 (in /lib/
    libpthread-2.5.so)
    ==13294== by 0x808E652: taskSpawn (vxworks_posix.cpp:112)
    ==13294== by 0x8082C56: StartServer (SSServer.cpp:520)
    ==13294== by 0x808D9E7: main (main_posix.cpp:54)
    ==13294==
    ==13294==
    ==13294== 3,972 bytes in 1 blocks are possibly lost in loss record 8
    of 12
    ==13294== at 0x4023CB4: operator new[](unsigned)
    (vg_replace_malloc.c:268)
    ==13294== by 0x807E8ED: CReport::Init() (SSReport.cpp:1617)
    ==13294== by 0x8083632: ServiceThread (SSServer.cpp:301)
    ==13294== by 0x808DEBF: WinThreadFunc(void*) (vxworks_posix.cpp:74)
    ==13294== by 0x4056111: start_thread (in /lib/libpthread-2.5.so)
    ==13294== by 0x43052ED: clone (in /lib/libc-2.5.so)
    ==13294==
    ==13294==
    ==13294== 7,940 bytes in 1 blocks are possibly lost in loss record 9
    of 12
    ==13294== at 0x4023CB4: operator new[](unsigned)
    (vg_replace_malloc.c:268)
    ==13294== by 0x807E7E3: CReport::Init() (SSReport.cpp:1607)
    ==13294== by 0x8083632: ServiceThread (SSServer.cpp:301)
    ==13294== by 0x808DEBF: WinThreadFunc(void*) (vxworks_posix.cpp:74)
    ==13294== by 0x4056111: start_thread (in /lib/libpthread-2.5.so)
    ==13294== by 0x43052ED: clone (in /lib/libc-2.5.so)
    ==13294==
    ==13294==
    ==13294== 132,852 bytes in 1 blocks are possibly lost in loss record
    11 of 12
    ==13294== at 0x4023CB4: operator new[](unsigned)
    (vg_replace_malloc.c:268)
    ==13294== by 0x807E406: CReport::Init() (SSReport.cpp:1567)
    ==13294== by 0x8083632: ServiceThread (SSServer.cpp:301)
    ==13294== by 0x808DEBF: WinThreadFunc(void*) (vxworks_posix.cpp:74)
    ==13294== by 0x4056111: start_thread (in /lib/libpthread-2.5.so)
    ==13294== by 0x43052ED: clone (in /lib/libc-2.5.so)
    ==13294==
    ==13294== LEAK SUMMARY:
    ==13294== definitely lost: 256 bytes in 1 blocks.
    ==13294== possibly lost: 145,628 bytes in 9 blocks.
    ==13294== still reachable: 166,904 bytes in 30 blocks.
    ==13294== suppressed: 0 bytes in 0 blocks.
    ==13294== Reachable blocks (those to which a pointer was found) are
    not shown.
    ==13294== To see them, rerun with: --leak-check=full --show-
    reachable=yes

  6. Re: Help: Segmentation fault

    Allen writes:

    > Valgrind is wonderful.


    Yes, it's very good (at some things).

    > Today I can run agent in the shell, not login X window. Very strange.
    > Maybe it has something wrong with VmWare?


    What's VmWare got to do with anything?

    You have a couple of very severe bugs: reading dangling memory
    (which could result in *any* value being read).

    Eventually, you also trash your stack, restore stack frame to
    0xFFFFFFFB and crash (your stack pointer is not pointing to a
    readable page).

    You should definitely fix your 'read dangling' errors.
    This may or may not cure the stack trashing problem.

    If it doesn't, Valgrind isn't going to help you much -- it does
    almost no checking of stack overflows. Your next steps would then be
    '-fmudflap' (available in gcc-4.x), or Insure++ (www.parasoft.com).

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

  7. Re: Help: Segmentation fault

    On 12月16日, 下午2时42分, Paul Pluzhnikov wrote:
    > Allen writes:
    > > Valgrind is wonderful.

    >
    > Yes, it's very good (at some things).
    >
    > > Today I can run agent in the shell, not login X window. Very strange.
    > > Maybe it has something wrong with VmWare?

    >
    > What's VmWare got to do with anything?
    >
    > You have a couple of very severe bugs: reading dangling memory
    > (which could result in *any* value being read).
    >
    > Eventually, you also trash your stack, restore stack frame to
    > 0xFFFFFFFB and crash (your stack pointer is not pointing to a
    > readable page).
    >
    > You should definitely fix your 'read dangling' errors.
    > This may or may not cure the stack trashing problem.
    >
    > If it doesn't, Valgrind isn't going to help you much -- it does
    > almost no checking of stack overflows. Your next steps would then be
    > '-fmudflap' (available in gcc-4.x), or Insure++ (www.parasoft.com).
    >
    > Cheers,
    > --
    > In order to understand recursion you must first understand recursion.
    > Remove /-nsp/ for email.


    Thank you.

    The bug is really difficult to find. Because I compile the project
    linked with so many shared libraries.
    Thank to Valgrind, it gives me some clues to detect the errors.
    If all the source files coded by myself, it is much easy to fix the
    bugs.
    Any way, I learn a lot from you.

    The only thing I am sure now is that there is something wrong with map
    file.

    Thank you very much.

  8. Re: Help: Segmentation fault

    Allen writes:

    > The bug is really difficult to find.


    No, it isn't: valgrind told you *exactly* where the bug is. The bug
    (well, at least one bug) is staring you straight in the eyes. It is
    *not* difficult to find.

    > Because I compile the project linked with so many shared libraries.


    How does that make anything difficult?
    You know how to find mvl_acse.c, don't you?

    The dangling bug is that file: on line 667 it calls x_chk_free()
    on something, then on line 670 it uses the thing it just free()d.

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

  9. Re: Help: Segmentation fault

    On 12月17日, 上午12时03分, Paul Pluzhnikov
    wrote:
    > Allen writes:
    > > The bug is really difficult to find.

    >
    > No, it isn't: valgrind told you *exactly* where the bug is. The bug
    > (well, at least one bug) is staring you straight in the eyes. It is
    > *not* difficult to find.
    >
    > > Because I compile the project linked with so many shared libraries.

    >
    > How does that make anything difficult?
    > You know how to find mvl_acse.c, don't you?
    >
    > The dangling bug is that file: on line 667 it calls x_chk_free()
    > on something, then on line 670 it uses the thing it just free()d.
    >
    > Cheers,
    > --
    > In order to understand recursion you must first understand recursion.
    > Remove /-nsp/ for email.


    I find the error.

    int RdbAdapter::Open()
    {
    CRdbNode rdb;
    rdb.loadFile();
    ...
    }

    Now I change it to be
    int RdbAdapter::Open()
    {
    static CRdbNode rdb;
    rdb.loadFile();
    ...
    }

    It is Ok now. I think the upper version causes stack overflow. Maybe
    different environment has different stack size. Therefore I can run
    under Eclipse IDE, XScale_be linux, but can not run in the terminal
    under X window of OpenSuse 10.2.

  10. Re: Help: Segmentation fault

    Allen writes:

    > I find the error.


    No, you didn't.

    What you did was "program by coincidence":
    http://www.pragprog.com/the-pragmati...ts/coincidence

    If you have any aspirations to becoming a professional programmer,
    you should stop right there, and actually find the bug (perhaps
    asking a local guru for help).

    > int RdbAdapter::Open()
    > {
    > CRdbNode rdb;
    > rdb.loadFile();
    > ...
    > }


    There is *nothing* wrong with the code above. The bug is elsewhere.

    > Now I change it to be
    > int RdbAdapter::Open()
    > {
    > static CRdbNode rdb;
    > rdb.loadFile();
    > ...
    > }


    Now you've likely made your code thread-unsafe. Since you are
    actually using threads, you've replaced an easy-to-find bug that
    Valgrind told you about, with one that might be much more difficult
    to find

    > It is Ok now. I think the upper version causes stack overflow. Maybe
    > different environment has different stack size. Therefore I can run
    > under Eclipse IDE, XScale_be linux, but can not run in the terminal
    > under X window of OpenSuse 10.2.


    You don't understand what you are talking about

    You also appear to ignore what I am telling you, so I'll just
    shut up.

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

+ Reply to Thread