> > I really do hope this helps in tracking the problem. > If not, please indicate the way I can send you the whole shiskebab. > For the database, that will not be possible since there is a lot of > confidential data in it. > But I could give you, personally, access to it if you want to. >
If you explain me how to reproduce the bug from the application, it may be the fastest solution, provided that you compile gambas2 from sources. But first, can you do that? 1) Get a core dump of the crash, and load it into gdb to get a backtrace. Send me that backtrace: $ ulimit -c 100000 $ cd /path/to/my/gambas/project $ gbx2 -p ... Segmentation fault (core dumped) $ gdb /usr/bin/gbx2 core ... (gdb) bt ... 2) Run your application into valgrind (if it is not too slow) to know where exactly the illegal memory access is done. Send me the valgrind output. $ cd /path/to/my/gambas/project $ valgrind --tool=memcheck --num-callers=50 gbx2 -p ... You will actually get useful information only if you compile gambas2 from sources, so maybe you should do that before. Thanks in advance, -- Benoît Minisini ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Gambas-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gambas-user
