> Yes, after I wrote my mail, I figured it may be the case. > Problem is that my program is oriented to module. > It invokes forms when needed and shows with them what > happens inside of module.
Yes. Maybe that automatic main window feature should be optional... > > Project I'm working on is big, old and messy. It is ported from vb6. > Now I'm trying to make code more clear, but I'm getting signal 11. > I can't send this project to you, but I'm trying to isolate the problem. > Do gdb outputs help you without source code? > However, here: > > Program received signal SIGSEGV, Segmentation fault. > my_free (alloc=0x1e1d150a1e1d150a) at ../share/gb_alloc_temp.h:333 > 333 pool = (size / SIZE_INC) - 1; > (gdb) bt > #0 my_free (alloc=0x1e1d150a1e1d150a) at ../share/gb_alloc_temp.h:333 > #1 0x000000000042b6ef in EXTERN_exit () at gbx_extern.c:438 > #2 0x00000000004216ae in main_exit (silent=<value optimised out>) at > gbx.c:135 #3 0x0000000000421e0f in main (argc=1, argv=<value optimised > out>) at gbx.c:391 > > Jussi > Yes, but not necessarily. If a bug corrupts memory, then the crash can occurs later, and then the backtrace is meaningless. The better is using valgrind and reproducing the crash. To do that, run your project that way: $ cd /path/to/my/project $ valgrind --tool=memcheck --num-callers=50 --track-origins=yes gbx3 ... Do what is needed to get a crash, and then send me the valgrind output. Sometimes, the program won't crash, because valgrind always tries to continue even after a segmentation fault. Send me the valgrind output anyway! Regards, -- Benoît Minisini ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
