[Gambas-user] Debugging Gambas (again)

[Tobias Boege]

On Fri, 26 Apr 2019, KKing wrote:
> 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);
> 

Here the output of the "bt" command would be interesting. Which path does
the interpreter take to the segfault?

Sadly, the alloc_string where the error happens is a macro, so we don't
know exactly where the error occurs. If you turn on the DEBUG_ME directive
as explained below, it will be demacroed, so we'll get a better look.

> 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)?
> 

The "l gbx_watch.c:504" in the tutorial was just an example that is not
relevant here. The "l" command lists source code, but gbx_watch.c doesn't
seem to be involved in this issue. We'll know more once you have a back-
trace from "bt".

If you compiled Gambas yourself with debugging symbols enabled (-O0 -g),
then yes, the filenames and lines will match what's inside the Gambas
sources on your system. They will not necessarily match what everybody
else has on their computers, or the current stable version.

> 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
> >>
> 
> 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?
> 

Compiling the latest Gambas is very reasonable (in this case). When you do,
you can also add "-DDEBUG_ME" to CFLAGS and CXXFLAGS when calling make,
like the debugging tutorial tells you to do with with "-O0 -g" already.
DEBUG_ME will enable lots of diagnostic messages from the interpreter and
cause some macros to be replaced by properly tracable functions.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk