[Gambas-user] Debugging Gambas (again)

[KKing]

So I'm back to trying to establish why a large application ported from 
powerbasic is failing with a segmentation fault.

Please note I am not looking for anyone to tell me the problem with my 
code, I am looking for guidance on how to go about debugging a Gambas 
application.

I found this link 
https://www.domotiga.nl/projects/domotiga/wiki/Gambas_Debugging

And have been following the section titled Debug Signal #11

for reference when I do
$ gdb gbx3
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1

The program is an order entry system with multiple ordering lines to be 
entered, after a certain number of entries the program fails, under gdb 
it gives

Program received signal SIGSEGV, Segmentation fault.
0x0806d8d3 in STRING_new (src=0x0, len=2) at gbx_string.c:311elAddr
311        str = alloc_string(len);

I can follow the next commands all okay and one below does highlight the 
line I know it gets to via a manual trace log file I write to, in fact 
it is a call to the trace log that it fails on (and has been through 
this same routine a large number of times already)

(gdb) p DEBUG_get_position(EXEC_current.cp, EXEC_current.fp, 
EXEC_current.pc)
$1 = 0x80a0d00 <COMMON_buffer> "Module1.dBUse.142"

But I'm not sure about the line
(gdb) l gbx_watch.c:504

why? and is it likely to be still correct for my version of (compiled 
from source) Gambas (3.8.4)?

I'm not sure if the response below is what look for/expecting ?
<<
499                    (*(wcb.callback_read))(wcb.fd, GB_WATCH_READ, 
wcb.param_read);
500                }
501            }
502
503            if (FD_ISSET(wcb.fd, wfd))
504            {
505                FD_CLR(wcb.fd, wfd);
506                if (wcb.callback_write)
507                {
508                    #ifdef DEBUG_WATCH
 >>

and if I do the next two lines I get.

(gdb) print ret
No symbol "ret" in current context.

(gdb) info locals
No locals.

Any idea what I am doing wrong there?


Also when I try to save I get the following
(gdb) gcore
warning: Memory read failed for corefile section, 12288 bytes at 0xb7fda000.
Saved corefile core.7817


Then I tried with valgrind.

it starts with
<<
$ tail -f /tmp/valgring.log
==6154== Memcheck, a memory error detector
==6154== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==6154== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==6154== Command: gbx3
==6154== Parent PID: 6086
==6154==
==6154== Invalid read of size 4
==6154==    at 0x806D8D3: STRING_new (gbx_string.c:311)
==6154==    by 0x806DC05: STRING_new_temp_value (gbx_string.c:459)
==6154==    by 0x806D057: NUMBER_int_to_string (gbx_number.c:491)
==6154==    by 0x804DC91: VALUE_convert (gbx_value.c:576)
==6154==    by 0x8061271: SUBR_conv (gbx_subr_conv.c:108)
==6154==    by 0x807F281: EXEC_loop (gbx_exec_loop.c:510)
==6154==    by 0x80510E1: EXEC_function_loop (gbx_exec.c:931)
==6154==    by 0x8051764: EXEC_function_real (gbx_exec.c:895)
==6154==    by 0x804B4FB: main (gbx.c:416)
==6154==  Address 0x2867d400 is not stack'd, malloc'd or (recently) free'd
==6154==
==6154==
==6154== Process terminating with default action of signal 11 (SIGSEGV)
==6154==  Access not within mapped region at address 0x2867D400
==6154==    at 0x806D8D3: STRING_new (gbx_string.c:311)
==6154==    by 0x806DC05: STRING_new_temp_value (gbx_string.c:459)
==6154==    by 0x806D057: NUMBER_int_to_string (gbx_number.c:491)
==6154==    by 0x804DC91: VALUE_convert (gbx_value.c:576)
==6154==    by 0x8061271: SUBR_conv (gbx_subr_conv.c:108)
==6154==    by 0x807F281: EXEC_loop (gbx_exec_loop.c:510)
==6154==    by 0x80510E1: EXEC_function_loop (gbx_exec.c:931)
==6154==    by 0x8051764: EXEC_function_real (gbx_exec.c:895)
==6154==    by 0x804B4FB: main (gbx.c:416)
==6154==  If you believe this happened as a result of a stack
==6154==  overflow in your program's main thread (unlikely but
==6154==  possible), you can try to increase the size of the
==6154==  main thread stack using the --main-stacksize= flag.
==6154==  The main thread stack size used in this run was 8388608.
==6154==
==6154== HEAP SUMMARY:
==6154==     in use at exit: 210,929 bytes in 1,065 blocks
==6154==   total heap usage: 1,700 allocs, 635 frees, 865,849 bytes 
allocated
==6154==
 >>

then multiple repeating (with varying content) sections like below
<<
==6154== 16 bytes in 1 blocks are possibly lost in loss record 7 of 183
==6154==    at 0x402A1CC: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==6154==    by 0x804CA32: my_malloc (gb_alloc_temp.h:368)
==6154==    by 0x80553FC: CLASS_find (gbx_class.c:543)
==6154==    by 0x8054EC3: CLASS_init_native (gbx_class_init.c:145)
==6154==    by 0x806C663: init (gbx.c:87)
==6154==    by 0x804B33F: main (gbx.c:372)
 >>

and finally
<<
==6154== 45,920 bytes in 2 blocks are possibly lost in loss record 183 
of 183
==6154==    at 0x402A1CC: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==6154==    by 0x804CA32: my_malloc (gb_alloc_temp.h:368)
==6154==    by 0x805BBD4: STREAM_load (gbx_stream.c:1450)
==6154==    by 0x8056F6E: load_without_inits (gbx_class_load.c:1012)
==6154==    by 0x80585A1: CLASS_load_real (gbx_class_load.c:1311)
==6154==    by 0x806A2C9: ARCHIVE_load_exported_class (gbx_archive.c:196)
==6154==    by 0x806A416: ARCHIVE_load_main (gbx_archive.c:282)
==6154==    by 0x805D0DA: PROJECT_load_finish (gbx_project.c:489)
==6154==    by 0x806C6AF: init (gbx.c:103)
==6154==    by 0x804B33F: main (gbx.c:372)
==6154==
==6154== LEAK SUMMARY:
==6154==    definitely lost: 32 bytes in 1 blocks
==6154==    indirectly lost: 64 bytes in 2 blocks
==6154==      possibly lost: 133,072 bytes in 576 blocks
==6154==    still reachable: 77,761 bytes in 486 blocks
==6154==         suppressed: 0 bytes in 0 blocks
==6154== Reachable blocks (those to which a pointer was found) are not 
shown.
==6154== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6154==
==6154== For counts of detected and suppressed errors, rerun with: -v
==6154== ERROR SUMMARY: 117 errors from 117 contexts (suppressed: 0 from 0)
 >>

So have I misunderstood any of the instructions in
https://www.domotiga.nl/projects/domotiga/wiki/Gambas_Debugging
or do I need to do it slightly differently for some reason(s) ?

My next steps are likely to be to grab the latest version of Gambas 
source and compile that on a Debian 9 64bit unit, and assuming it still 
fails, repeat the above.

Does that sound reasonable, anything else I should do differently?

K.